In theory, LLVM supports integer types of an arbitrary number of bits. But in our experience oddball integer sizes that C doesn't use typically don't work very well. This may improve over time and make it more reasonable to have a user-defined 23-bit integer type. In principle, we could certainly allow arbitrarily sized bits types, but you couldn't really do anything with them without a significant amount of work. Since it's rather poor form to leave unfinished features around that people can try that simply crash the system, we don't allow a number of bytes that's not a multiple of 8. Bits types that aren't a multiple of 8 just aren't a very high priority.
On Sat, Jan 25, 2014 at 12:58 PM, Ivar Nesje <[email protected]> wrote: > References for splicing vs splatting in the latest manual: > > > http://docs.julialang.org/en/latest/manual/style-guide/?highlight=splicing#don-t-overuse > > http://docs.julialang.org/en/latest/stdlib/base/?highlight=splicing#Base.apply > > Also, if Julia were to support 23 bits types, what would it mean? Should > the implementation just silently round up to 32 and make it behave as if it > was declared 32, or should it implement some special overflow rules that > would make things slower, because a programmer tried to save some bits? > > kl. 18:47:42 UTC+1 lørdag 25. januar 2014 skrev Jameson følgende: >> >> >> Some of these, such as the arrow key thing, sound like they might be >> better as a github issue. I don't know what the expected behavior on >> windows is. >> >> >The issue is process termination, but don't Shift+Arrow and Ctrl+Arrow >> work the same way on Windows and Linux nowadays? Not sure about the Mac... >> in any case I'm not surprised if the keys simply don't work in a terminal >> (Windows terminals suck). >> >> Leah meant that you should file an issue on GitHub. It may not be able >> to do anything useful, but it shouldn't crash. (alternatively, >> @lolodiro, when's REPL.jl getting merged?) >> >> > I think you misunderstand. Rounding up to 8 bits makes sense; not >> allowing the user to define, say, a 23-bit type is what I question. >> >> If it is rounding anyways, it is probably better to force the user to >> acknowledge that it is rounding. I'm not aware of any demand for a >> 23-bits type, so adding support for it would be tricky, without any >> useful benefit. Perhaps this section should just mention that the >> ability to define custom bitstypes has been (almost) entirely >> superseded by the ability to make immutable types. >> >> On Sat, Jan 25, 2014 at 12:36 PM, David Piepgrass <[email protected]> >> wrote: >> > You're right, I'm sorry for not numbering my thoughts or anything. >> > >> > >> >> Some of these, such as the arrow key thing, sound like they might be >> >> better as a github issue. I don't know what the expected behavior on >> windows >> >> is. >> > >> > >> > The issue is process termination, but don't Shift+Arrow and Ctrl+Arrow >> work >> > the same way on Windows and Linux nowadays? Not sure about the Mac... >> in any >> > case I'm not surprised if the keys simply don't work in a terminal >> (Windows >> > terminals suck). >> > >> >> For issues with the writing/content of the manual, the most effective >> >> thing is to make a pull-request to make the changes. The source of the >> >> manual is here: https://github.com/JuliaLang/ >> julia/tree/master/doc/manual >> >> It's convenient to edit them on github, especially if you're less >> >> comfortable with git. (The workflow on github is remarkably smooth; >> all you >> >> need it a github account.) I'm skipping things that sound like you >> just want >> >> a specific change to the manual, since you can go make those. :) >> > >> > >> > I'll keep that in mind, thanks. >> > >> >> 1. I'm not especially experienced with intellisense (I don't use IDEs >> >> generally), but Julia does know what methods are in scope at any given >> >> point. If you're in the REPL or IJulia, you can type something like >> >> `istext(` and then press Tab. It will show you a list of the methods >> of >> >> `istext`. >> >> >> >> 2. As far as the undefined reference error, what needed to be changed >> >> about the manual? It looks like it continues to behave as advertised. >> I >> >> haven't dug into what the default printing function's implementation >> looks >> >> like, but that would be where I'd look for how it gets around the >> undefined >> >> problem. >> > >> > >> > Accessing uninitialized Some{Int}().value doesn't throw an error >> either. >> > >> >> >> >> 3. Julia has first class types, so types are values in the language. >> Tuple >> >> types are written as a tuple of the types, which seems fairly >> >> straight-forward. Your version, Tuple{Int,Int}, would require a new >> type for >> >> each size of tuple (or would have a different representation than you >> >> suggested). I don't understand what you would gain by having a >> separate type >> >> that basically reimplements the same functionality as a tuple. Could >> you >> >> offer a concrete example of a problem this could cause? >> > >> > >> > The point is that a tuple is sometimes a type-of-type and other times >> it is >> > just an ordinary value. So if there were a superclass of all types of >> types >> > (as is the case in most languages with reflection), some tuples would >> be >> > subclasses of it and others would not be. It's just ... so ... weird. >> I'm >> > not claiming it's problematic, I'm asking if it is ever problematic. >> > >> >> >> >> 4. "..." is called "splat" in Julia. >> > >> > >> > The manual (0.2 at least) calls it "splicing" and I don't think it uses >> that >> > word. >> > >> >> 5. `x::Int = 5` evaluates both sides - `x::Int` and `5`. `x::Int` >> throws >> >> that error because x is not defined yet -- it's definitely not an Int. >> If >> >> you make it `5::Int`, you'll probably get closer to what you expected. >> > >> > >> > The manual specifically mentions this syntax as a special case. See >> > Spencer's reply. >> > >> >> >> >> 6. There is only one implementation of Julia, so I'm not sure why you >> >> wouldn't want "sizes are rounded up to multiples of 8 bits" in the >> manual. >> >> It's useful if you care about the representation of your types in >> memory. >> >> Since the manual can be updated at any time (such as to reflect a >> change in >> >> implementation details), there isn't some lock in to the specification >> by >> >> doing so. >> >> >> > I think you misunderstand. Rounding up to 8 bits makes sense; not >> allowing >> > the user to define, say, a 23-bit type is what I question. >> >
