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]<javascript:>> > 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. >
