rename Uint => UInt, etc. ?

[StefanKarpinski]

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]

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

[ivarne]

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]

I agree, UInt feels better.

[tonyhffong]

+1

[ntessore]

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

[quinnj]

+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]

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

[garborg]

Another +1

[Jutho]

+1, bitten by this one several times.

[johnmyleswhite]

+10000 for more consistent capitalization

[stevengj]

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]

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

[JeffBezanson]

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]

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

[JeffBezanson]

Yes that could probably be done.

[StefanKarpinski]

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]

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]

I'm fine with this.

[GunnarFarneback]

Related: Cint and other C types.

[ivarne]

Here we go again!

Luckily that rename isn't as big.

[johnmyleswhite]

Oh, the CInt fix will be beautiful. :)

[StefanKarpinski]

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]

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

[quinnj]

+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]

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

[kmsquire]

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]

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]

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

[nolta]

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

[ivarne]

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

[ViralBShah]

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

[tkelman]

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]

@tkelman c'est comme C, comme ça

[StefanKarpinski]

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]

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]

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]

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

[ivarne]

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

[timholy]

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]

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

[stevengj]

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]

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]

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]

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]

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.