Adam D. Ruppe: > I like it being thin so for me, it's a win/win. > I use small and split windows as well as > 8 character tab stops. (4 characters just blend into the background..)
I see. I prefer to see a chunk of code that does something, on the screen, and to not scroll too much. For lot of time the common indent for Delphi code was of 2 spaces :-) > That wouldn't help with runtime errors... and I don't think > it would help much for compile either, as a general rule. > Something like "cannot call function foo() with args abc" puts > you in the right place anyway, even on a pretty complex line. The column number of errors helps a little when you have lines of code like (and in other situations): void main() { int[2] f; auto r = f[1] + f[2]; } > > Currently the JSON data is not computed at compile-time, and it's > > written as file text on the disk, while a library is meant to not > > touch the disk. So the situation isn't good enough yet. > > dmd -X -Xf- file.d > > That dumps it to stdout, which you can pipe out to where it needs > to be. I meant something different. I don't want to convert JSON tree from-to text, I'd like to bypass the text representation fully. So the compile-time JSON Phobos library returns a data structure that represents the JSON tree (created by the compiler) in memory. There are zero files, stdout, pipes and text streams. > Though, getting it into the program being compiled might > be a little tricky without touching the disk. But then again, > does it really matter? The compile process writes files as > part of its normal operation anyway. It matters if you want to use the JSON data in a larghish program as a static reflection mean to implement good user defined attributes. The less you convert and parse data, the faster and more usable the whole game is. > > An ubyte[] is a workaround for a type system not good enough yet. > > I wouldn't say that it isn't good enough. It's just that you > and Andrei have a different philosophy about this. I don't remember Andrei's opinion about that idea. > > Reducing syntax noise in functional-style code is something that > > a lot of people wants (me too). > > Remember, one man's noise is another's parsing anchors. For example, > I find an if without parens to just look... naked. Removing some syntax noise is not a so optional thing in functional languages. In Haskell you often have code like: vmoot xs = (xs++).map (zipWith (+) lxs). flip matmul r_90. map (flip (zipWith (-)) lxs) .reverse . init $ xs where lxs = last xs If you start putting parentheses everywhere, you produce something less readable than Lisp. I have never suggested to introduce optional parenthesis in D (the opposite: I'd like function calls to always require them in D), I have just suggested to replace two functions like array(map()) with amap(). Bye, bearophile