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.
