== Quote from Adam Ruppe (destructionator@gmail.com)'s article
> My implementation
> http://arsdnet.net/tictactoe.d
after your permtion i post your code in http://rosettacode.org/wiki/Tic-tac-toe

Hamad:

> == Quote from Adam Ruppe (destructionator@gmail.com)'s article
> > My implementation
> > http://arsdnet.net/tictactoe.d
> after your permtion i post your code in http://rosettacode.org/wiki/Tic-tac-toe

On Rosettacode they don't want too much long lines, so I suggest you to reduce indents to just 4 spaces, keeping lines under 75 chars.

Bye,
bearophile

Hamad wrote:
> after your permtion i post your code in http://rosettacode.org/wiki/Tic-tac-toe

Cool.

bearophile:
> This kind of indentations is interesting:

I'm still trying to find something I like for this. Currently,
I see the contracts as part of the public interface, just like
the name, so I'm indenting them like I would if the argument list
ran too long.

void doSomethingBig(
      int arg1,
      int arg2)
{

}

(Sometimes I put the { on the same line as the ) but then I often
find it hard to see the difference between the arguments and local
variables.)

So, similarly, the in and out get indented. It would be messy to shove them all on one line, but without the indent, it'd look like it's all part of the body.

>  In such Python/D scripts I don't write stuff like this:
> [snip toString ]

One practical reason for such separation is this (seen in Python
but D does it too):

  >>> s = [1,2,3]
  >>> print s[34], s[44]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  IndexError: list index out of range


Error messages give a line number... but if there's still several points of similar failure on that one line, it doesn't help as much as it could.

This leads me to write things like this sometimes too:

    auto author =
      stuff["data"]
      [0]
      ["from"]
      ["name"];


So if the data isn't what I expected, the line number in the error message tells exactly what was missing. (This is also a good example of why semicolons are a gift from God)

>>> s = ((1,2), (3,4), (5,6))
>>> print s[1]
(3, 4)


Ahhh, I wanted a child of it!

Now, I'm forced to do it on one monster line...

>>> print s[1][3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: tuple index out of range

Gah, which one? I guess I'll use a temp variable...



Anyway, sometimes this can be fixed in the runtime by including the data and the index as part of the exception, but not always (what if you did [0][0]?). Putting them on separate lines is an easy, reliably way to get more information out of the error.


> I know, but I was suggesting something different, to turn the JSON creation into some kind of Phobos library that you may call at compile-time from normal D code. Then a compile-time JSON reader in Phobos will allow to perform certain kinds of static introspection, that later will be quite useful to create user-defined @annotations.

We could do that today with a combination of -X, -J, and a CTFE JSON parser (it's possible that std.json would work today. I haven't tried it specifically, but ctfe tends to surprise me with its capabilities).

Of course, you'd have to run the compiler twice, but there's other advantages to that too (like getting dependencies - my build tool does this - and the first run is fast anyway.


I'm tempted to do it now just to prove we can... but I'm already a bit loaded with stuff to do.


> With "new Tuple!()()" you need to manually specify the types of all
> the fields, while "tuple()" spares this need, but allocates on the
> stack. A newTuple() function allows to do both, but I don't know
> how much often it is needed.

Maybe a generic toHeap!(T) function would be good for this. It takes an existing object and copies it to the heap if necessary.

return toHeap!(tuple(1, 2, 3));


However, it seems to me that most tuples are likely to be small value types anyway. You had an int, char[]. When I use tuples, they are usually small collections of ints and strings too.

Value types don't really need to be on the heap. You can just return them and pass them to functions normally and it works fine.


> What I'd like is a way to tell the type system that I am creating a sequence of 8-bit chars, and not a string of chars.

Maybe try ubyte[]?

> I know, but programming life is not orthogonal :-)

That's part of the reason I said it... I'm only half serious.

Though, on the other hand, I've used the ncurses library which does this kind of thing. The number of function names is obscene, and the benefit is quite small. I'm not convinced the parentheses are a big deal. (Hell, I've done lisp before... and kinda liked it. :P)


> I think to!int('1') == 1 is useful, but I am not sure if C-derived
> programmers accept/like to!int to work differtly from cast(int) in
> this case.

The way I see it is if you are working with single chars, it is probably because you want to do some work with the char itself - it's numeric value. Thus it fits the same general area as int.

Perhaps you want to just work with one length strings? str[0..1] instead of str[0].

On 02/08/2011 04:11 PM, Adam Ruppe wrote:
>> I know, but I was suggesting something different, to turn the JSON
>> >  creation into some kind of Phobos library that you may call at
>> >  compile-time from normal D code. Then a compile-time JSON reader in
>> >  Phobos will allow to perform certain kinds of static introspection,
>> >  that later will be quite useful to create user-defined @annotations.
> We could do that today with a combination of -X, -J, and a CTFE
> JSON parser (it's possible that std.json would work today. I haven't
> tried it specifically, but ctfe tends to surprise me with its
> capabilities).
>
> Of course, you'd have to run the compiler twice, but there's other
> advantages to that too (like getting dependencies - my build tool
> does this - and the first run is fast anyway.
>
>
> I'm tempted to do it now just to prove we can... but I'm already
> a bit loaded with stuff to do.

What I dream of is something a bit different: a D "decoder" (lexical, syntactic, semantic(*) analyser) that constructs an AST as a plain D data structure --without any fancy stuff. And writes it out on demand as a D module (in static this(), since for a reason I haven't yet caught data description can only go there).
I can't even start to imagine all what we could then do /easily/. (we would even have type defs in D... would change from obscure RTTI)

=================================
import std.stdio;
a = 1;
void main () {
    writeln(a);
}
=================================
==>
=================================
import AST;	// Node types, mainly
Module module;

static this () {
    module = Module ([
        Import("std.stdio"),
        Assignment("a", Integer(1)),
        FunctionDef(
            /* name */      "main",
            /* params */    [],
            /* block */     [
                FunctionCall(
                    /* name */   "writeln",
                    /* args */   [Symbol(a)]
                )
            ]
        )
    ]);
}
=================================

Too bad we're missing named args, would be highly helpful here; but we can probably survive that...
(Yes, Bearophile, there's certainly a bug report for this ;-)

I would enjoy writing a prototype when I have some time (not tomorrow), for a tiny subset of D (kind of proof of concept).

Denis

(*) As far as possible.
-- 
_________________
vita es estrany
spir.wikidot.com

Adam Ruppe:

> I'm still trying to find something I like for this.

Me too.


> Error messages give a line number... but if there's still several points of similar failure on that one line, it doesn't help as much as it could.

I understand. But splitting lines too much make the code a bit too much thin. I think a better solution is this request (from Lewis):
http://d.puremagic.com/issues/show_bug.cgi?id=5521


> We could do that today with a combination of -X, -J, and a CTFE JSON parser



> (it's possible that std.json would work today. I haven't tried it specifically, but ctfe tends to surprise me with its capabilities).

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.


> Maybe try ubyte[]?

There are moments when I want an array of ubytes, other moments when I want an array of 8 bit chars, and other situations where I want a string of chars. An ubyte[] is a workaround for a type system not good enough yet.


> Though, on the other hand, I've used the ncurses library which does this kind of thing. The number of function names is obscene, and the benefit is quite small.

I agree that too many functions are going to give problems. But an "a" suffix is burden smaller than two names fully new.


> I'm not convinced the parentheses are
> a big deal. (Hell, I've done lisp before... and kinda liked it. :P)

Scala, Ruby, ML-class languages like Haskell, etc have means to reduce parentheses count. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). I have used Scheme, but parentheses tire me after a while.


> Perhaps you want to just work with one length strings? str[0..1] instead of str[0].

I have done this some times. I presume I will need to use this more.

Bye and thank you,
bearophile

bearophile:
> I understand. But splitting lines too much make the code a bit too much thin.

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 think a better solution is this request (from Lewis): http://d.puremagic.com/issues/show_bug.cgi?id=5521

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.

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

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

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

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

On 02/08/2011 10:11 PM, bearophile wrote:
> Adam Ruppe:
>
>> I'm still trying to find something I like for this.
>
> Me too.

I like Adam's solution as well, but it's not perfect. The only other solution (like for constraints) would be a syntactic difference, but since we're limited by keyboard keys, this would instead certainly augment visual noise.

>> Error messages give a line number... but if there's still several
>> points of similar failure on that one line, it doesn't help as much
>> as it could.
>
> I understand. But splitting lines too much make the code a bit too much thin. I think a better solution is this request (from Lewis):
> http://d.puremagic.com/issues/show_bug.cgi?id=5521

Just done it for my parser. Once you get the line nr...

>> Maybe try ubyte[]?
>
> There are moments when I want an array of ubytes, other moments when I want an array of 8 bit chars, and other situations where I want a string of chars. An ubyte[] is a workaround for a type system not good enough yet.

After some more interrogations on the topic, I think there should be 4 somewhat related types.
* Bytes --> processing of data at plain binary/numeric level, no link to text (eg pixmap)
* ByteString --> single-byte charset text (ascii, latin-X,...)
On the implementation side, there no difference in data structure (not even code check like for D chars). But conceptually and semantically, these types are unrelated. (It would be a bit strange for me to process a pixmap using a type that exposes tons of text-processing functionality.)
ByteString is, I guess, more or less what Steven proposed.
* D' utf-8 string for i/O of unicode text without any manipulation (except concat).
* A Text like what I proposed for unicode text manipulation, conceptually an array of univoque text-characters (an array of no-copy-slices into a normalised utf-8 string).

>> Though, on the other hand, I've used the ncurses library which does
>> this kind of thing. The number of function names is obscene, and
>> the benefit is quite small.
>
> I agree that too many functions are going to give problems. But an "a" suffix is burden smaller than two names fully new.

I like your proposal. But -a suffixes are no good, use -Array or array- prefix instead.

>> I'm not convinced the parentheses are
>> a big deal. (Hell, I've done lisp before... and kinda liked it. :P)
>
> Scala, Ruby, ML-class languages like Haskell, etc have means to reduce parentheses count. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). I have used Scheme, but parentheses tire me after a while.

Editors do that for you, don't they? Even for languages they don't know... (never been annoyed by paren counts, not even in Lisp-like slangs)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/09/2011 01:35 AM, bearophile wrote:
> 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.

Just what I would like to rip from a D parser in D (which doesn't prevent to write it into a D source module if useful).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com