Another Phobos2 test

[bearophile]

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