Better yet, since we already have both AbstractVector, AbstractMatrix, AbstractArray, AbstractString, AbstractFloat and a couple of others (try typing Abstract<tab> in the REPL…) it might be time to rename Integer to AbstractInteger. I have a hard time thinking the confusion between Int and Integer would be reduced just because we also had Arr and Array et al - rather, we’d have *several* pairs of types where it isn’t entirely obvious that one is abstract and one is concrete.
Renaming Integer to AbstractInteger would probably cause massive breakage, though, so it’d have to be done with care. The difference between Int, Int32 /Int64 and Integer is well documented (see e.g. here <http://docs.julialang.org/en/release-0.4/manual/integers-and-floating-point-numbers/#integers> and here <http://docs.julialang.org/en/release-0.4/manual/types/#abstract-types>), but it seems to me that people stumble on this often enough that a naming change might be well motivated anyway. // T On Monday, October 26, 2015 at 8:26:08 PM UTC+1, Scott Jones wrote: >One possible naming scheme could be to follow the example of Int and > Integer and have Vec, Mat, Arr be the concrete types and Vector, Matrix and > Array be the abstract types. I'm really not sure this would be worth the > trouble at this point or if we really want the AbstractArray names to be > any shorter. > > That sounds like a quite good idea, which, if carried out completely, > could eliminate some inconsistencies in the naming of abstract vs. concrete > types, that have been causing people grief. > > So: > >> Abstract Concrete >> Signed (Integer) Int* >> Unsigned (Integer) UInt* >> Float Flt* >> Decimal Dec* >> Array Arr >> Vector Vec >> Matrix Mat >> String Str (maybe Str{Binary}, Str{ASCII}, Str{UTF8}, Str{UTF16}, >> Str{UTF32}) > > >
