rename Uint => UInt, etc. ? #8905

Closed
StefanKarpinski opened this Issue Nov 5, 2014 · 45 comments

Projects

None yet
@StefanKarpinski
Member

I was watching a presentation on Swift, which has eerily similar names for basic numeric types – except that unsigned integer types are capitalized as UInt rather than Uint, UInt64 rather than Uint64, etc., which strikes me as possibly a more pleasant and consistent capitalization on the theory that UInt is short for U(nsigned )Int(eger). It also has the virtue that changing a type from Int and UInt is just a matter of adding a letter instead of replacing a letter and adding a letter.

To be filed under things I should have brought up five years ago.

@nalimilan
Contributor

FWIW, I remember that when I discovered Julia I found Uint a bit weird, UInt would have looked more logical to me.

@ivarne
Contributor
ivarne commented Nov 5, 2014

It's kind of the thing you just take for granted, but I have often seen ERROR: UInt8 not defined, so I guess it would be easy bring back my bad habit. Now that we have Int(x) and Uint8(x) instead of int() and uint8() this makes even more sense.

if can_deprecate_types_with_proper_warning()
   return +1
else
   return -10
end

A nice way to do deprecation with warnings would also greatly benefit the String -> AbstractString rename.

@toivoh
Member
toivoh commented Nov 5, 2014

I agree, UInt feels better.

@tonyhffong
Member

+1

@ntessore
Contributor
ntessore commented Nov 5, 2014

In the same vein: Regex vs RegEx, if the same logic as for module names applies.

@quinnj
Member
quinnj commented Nov 5, 2014

+1 for changing Uint to UInt.

On Wed, Nov 5, 2014 at 7:15 AM, Nicolas Tessore notifications@github.com
wrote:

In the same vein: Regex vs RegEx, if the same logic as for module names
https://groups.google.com/d/msg/julia-users/Yw5pB4voy1s/DiSPQQgQGB8J
applies.


Reply to this email directly or view it on GitHub
#8905 (comment).

@StefanKarpinski
Member

Although Regex is technically an abbreviation its quite standard to capitalize it this way in a variety of languages.

@garborg
Member
garborg commented Nov 5, 2014

Another +1

@Jutho
Contributor
Jutho commented Nov 5, 2014

+1, bitten by this one several times.

@johnmyleswhite
Member

+10000 for more consistent capitalization

@stevengj
Member
stevengj commented Nov 5, 2014

Julia 0.4: the spelling release.

It would be good to have more useful error messages in 0.4 for people who use the old names. ERROR: String not defined is unhelpful.

@ivarne
Contributor
ivarne commented Nov 5, 2014

@stevengj That was a mistake, and is fixed now.

@JeffBezanson
Member

We could have a Dict of deprecated names, and use it in the showerror method for UndefVarError. Of course, that only works for fully removed names.

@StefanKarpinski
Member

Is there any way deprecations could be hooked into the lazy resolution of names from using?

@JeffBezanson
Member

Yes that could probably be done.

@StefanKarpinski
Member

Having the ability to deprecate bindings would be a huge deal. With that we can basically do almost any kind of deprecation pretty painlessly.

@StefanKarpinski
Member

In any case, this rename at least seems popular. @JeffBezanson, @ViralBShah – do you guys have opinions? You guys have been living with these spellings for the longest. I didn't really notice how much better UInt64 looked until I was presented with it on a slide.

@JeffBezanson
Member

I'm fine with this.

@stevengj stevengj referenced this issue in JuliaLang/Compat.jl Nov 6, 2014
Closed

UInt aliases #16

@GunnarFarneback
Contributor

Related: Cint and other C types.

@ivarne
Contributor
ivarne commented Nov 6, 2014

Here we go again!

Luckily that rename isn't as big.

@johnmyleswhite
Member

Oh, the CInt fix will be beautiful. :)

@StefanKarpinski
Member

The thing about the C* types is that they are C followed by exactly the C name of the type, which is all lowercase. What might be reasonable is to prefix these types with C_ instead of just C so it would be C_int, etc. Alternatively, we could have Base.C module and have all these C-compatibility bindings in there so this would become C.NULL, C.int, C.size_t, etc.

@johnmyleswhite
Member

Both of those seem much more readable to me. I kind of like the Base.C idea.

@quinnj
Member
quinnj commented Nov 6, 2014

+1 to C.int

On Thu, Nov 6, 2014 at 9:55 AM, John Myles White notifications@github.com
wrote:

Both of those seem much more readable to me. I kind of like the Base.C
idea.


Reply to this email directly or view it on GitHub
#8905 (comment).

@ivarne
Contributor
ivarne commented Nov 6, 2014

I don't like the C module and the C.int idea.

@kmsquire
Member
kmsquire commented Nov 6, 2014

Hi Ivar, any particular reason you don't like that idea?

I feel that separating such things out into their own namespace removes
clutter from the main namespace (but I'm fine with whatever is decided).

Cheers, Kevin

On Thu, Nov 6, 2014 at 1:53 PM, Ivar Nesje notifications@github.com wrote:

I don't like the C module and the C.int idea.


Reply to this email directly or view it on GitHub
#8905 (comment).

@ivarne
Contributor
ivarne commented Nov 6, 2014

I'm not really sure, and it I'll be fine whatever. It is a breaking change and we should be careful with those. The names isn't hugely valuable for other usages. It also feels weird to put part of the C-API in a module. I might like it better if the plan was to also move ccall, cconvert, pointer...

@Jutho
Contributor
Jutho commented Nov 6, 2014

Would you then name it C.call, C.convert, ... ? That's probably too confusing :-)

@nolta
Member
nolta commented Nov 6, 2014

I'm also -1 on this. No name is perfect. Better to just leave pandora's box closed.

@ivarne
Contributor
ivarne commented Nov 6, 2014

@Jutho Yes, for example, but I still think the current names are good enough. Calling C feels more native that way.

@ViralBShah
Member

I like the proposed new spellings. Like you said, we should have thought of this 5 years ago! Better late than never.

@tkelman
Member
tkelman commented Nov 7, 2014

Wouldn't having an exported module called C interfere, or at least lead to some possible confusion, if I wanted to name a variable C?

@jiahao
Member
jiahao commented Nov 7, 2014

@tkelman c'est comme C, comme ça

@StefanKarpinski
Member

c'est comme C, comme ça

That definitely got a chuckle out of me. The nice thing about C.int, etc. is that it avoids littering the top-level Base namespace with a bunch of names that you don't always need. It also makes it easier to isolate which exact names exist for C compatibility – as it stands, although things are easy enough to disambiguate with some common sense, you could, in principle be confused about whether a name that begins with C is for interfacing with C types or just happens to begin with "C".

@ivarne
Contributor
ivarne commented Nov 7, 2014

C seems much more valuable namespace wise than all our current C* types and functions, so I don't really see namespace pollution as an argument. C is my third most favorite name of a type when testing things in the REPL (after A and B).

When thinking about breaking changes to the C-API we should also look at the bug in 4b4565f. Can we have something like a C.string, that ensures '\0' termination, and C.Ptr{Uint8} as just a raw pointer?

Can we also get rid of the ugly mix of normal types and special C types in ccall. Almost all types match directly, so you don't need to care about Cint16 vs Int16, but suddenly a pesky Int bites one of your users.

@nalimilan
Contributor

Using a namespace would allow for interfaces with other languages to follow the same pattern, which is nice. But would C.call instead of ccall be possible? AFAICT calling using Base.C would create conflicts with call. But maybe C.ccall is good enough.

@StefanKarpinski
Member

Since ccall is a special language primitive, I don't think it needs to or should be namespaced.

@ivarne
Contributor
ivarne commented Nov 7, 2014

Don't we really want as few "special" things as possible in the language?

@timholy
Member
timholy commented Nov 7, 2014

I kind of like it, but on the other hand variable-name conflicts are likely to be common. All my covariance matrices are named C. Do we have any other single-letter modules?

@nalimilan
Contributor

It could remain unexported, so that you'd have to run using Base.C.

@stevengj
Member
stevengj commented Nov 7, 2014

The current C* names seem good enough to me.

@StefanKarpinski, "littering the namespace" is only really a problem if there is likely to be a conflict, but there is much more likely to be a conflict with C than with Cint etc. Let's not solve an abstract problem by introducing a concrete problem.

@StefanKarpinski
Member

There's not really any way to avoid having ccall be special.

On Nov 7, 2014, at 4:09 PM, Ivar Nesje notifications@github.com wrote:

Don't we really want as few "special" things as possible in the language?


Reply to this email directly or view it on GitHub.

@JeffBezanson
Member

There's not really any way to avoid having ccall be special.

That's correct. The specialness let us add some very nice functionality like & and safer GC rooting. Of course ccall could also be a macro that expands into some special AST node but we don't want to add the @ at this point.

I'm slightly against a C module, on grounds that it steals a single letter, and that it's not clear which things are for C compatibility (except the C* types). For example pointer and unsafe_load are not necessarily C-related.

However having c_malloc and c_free in Base is undeniably ugly. Maybe these (and dlsym and a few others) should go in a Libc module or the Sys module or something like that.

@ivarne
Contributor
ivarne commented Nov 7, 2014

What is special with ccall?

It does some lookup compile time as a performance optimization, but in all other cases where we need compile time specialization we use macros or a stagedfunction and maybe a custom Expr type.

@JeffBezanson
Member

See lower-ccall in julia-syntax.scm. As I said, yes this transformation could be done in a macro instead but we're used to writing ccall instead of @ccall.

I suppose ccall could be written as a macro that expands to an llvmcall, but at the end of the day something like that has to be built in. The ability to call an address is fundamental, and can't be emulated with higher-level constructs.

@waTeim waTeim added a commit to waTeim/julia that referenced this issue Nov 23, 2014
@StefanKarpinski @waTeim StefanKarpinski + waTeim rename Uint => UInt (closes #8905) ff6e5eb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment