>> 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.
