February 07, 2008
bearophile wrote:
> I was talking about free functions. I think for methods/properties the syntax
> without () can be kept...

As I said in another post, that which applies to properties applies equally well to free functions, due to global variables.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
February 07, 2008
Robert Fraser wrote:
> Walter Bright wrote:
>> Sergey Gromov wrote:
>>> I wonder why .sizeof is implemented as a property while typeof() and
>>> typeid() are functions.  I can see no reasons for such inconsistency.
>>> It's not that obvious for typeof() because it yields a type instead
>>> of a value, but even then, why not ?
>>
>> Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.
> 
> typeid yeilds an expression...

The subject says typeid, the post says typeof !

typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.
February 07, 2008
Sergey Gromov wrote:
> Are you sure this is to the better ?  I'm not quite fond of D's freedom
> in syntax.  It already allows to write an unreadable code like this:
> 
> use(context) in (GL gl) {draw(gl);}

And when I actually asked for comments about that syntax, no one stated that it was unreadable ... thanks for the (mislocated) feedback.

As for the exact form of that use() in .. statement, I made it so with the sole purpose of it being *readable*. It may be new to you; it usually makes people think that the construct is built into D, resulting in some confusion ("did I miss anything in the spec?"). Yet ultimately using the language's features to write code which looks built-in makes code easier to read. If my statement is false, then using AST macros in lisp makes the code less readable as well.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 07, 2008
Walter Bright wrote:
> Robert Fraser wrote:
>> typeid yeilds an expression...
> 
> The subject says typeid, the post says typeof !
> 
> typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.

real.nan?
February 07, 2008
Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> Sergey Gromov wrote:
> > Are you sure this is to the better ?  I'm not quite fond of D's freedom in syntax.  It already allows to write an unreadable code like this:
> > 
> > use(context) in (GL gl) {draw(gl);}
> 
> And when I actually asked for comments about that syntax, no one stated that it was unreadable ... thanks for the (mislocated) feedback.

I don't know where or when you have asked for this.  It's not my job to read through years of discussions, and I'm not obligated to read every single post even though I do monitor the group.

Someone has cited this code in D.learn asking what it does.  That's exactly what I mean.

> As for the exact form of that use() in .. statement, I made it so with the sole purpose of it being *readable*. It may be new to you; it usually makes people think that the construct is built into D, resulting in some confusion ("did I miss anything in the spec?"). Yet ultimately using the language's features to write code which looks built-in makes code easier to read. If my statement is false, then using AST macros in lisp makes the code less readable as well.

I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening.  This class is having this method called with these arguments.  That template is instantiated with those types.  Basically, it should be enough to read language specification to understand the code.  In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion.

-- 
SnakE
February 07, 2008
Sergey Gromov wrote:
> I don't know where or when you have asked for this.  It's not my job to read through years of discussions, and I'm not obligated to read every single post even though I do monitor the group.
> 
> Someone has cited this code in D.learn asking what it does.  That's exactly what I mean.

Ah, fine then, I thought you saw me pasting a more complete example on IRC on #d :)
Anyway, here it is, so maybe it makes some more sense this time: http://paste.dprogramming.com/dpn66vhk

It's an example from an unreleased OpenGL wrapper. The ext/use(...) in {}; constructs actually play an important role in its functioning, restricting access to the resource to a controlled region, executing special code before and after it, and in the case of 'ext', allowing an extra parameter after a variadic one.


> I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening.  This class is having this method called with these arguments.  That template is instantiated with those types.  Basically, it should be enough to read language specification to understand the code.  In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion.

Doesn't fit into the specs? How so? It's not like I'm preprocessing D.
I've talked with a few folks who have been coding in D for a while, and they immediately recognized the constructs. The func call, proxy object, opIn and the inline delegate.
It's not a surprise that fancy D code may cause confusion in D.learn, since well, it's an NG for beginners...

Let's take another example. For someone coming from Java, operator overloads might be unreadable code because when they see a + b, they can't know what's happening. But it's normal for D code. Someone coming from C would see any OO stuff unreadable. D is a relatively new language and there really isn't a common understanding of how 'readable' D code should look like. It's got its very own feel and syntax, to which programmers must get used and perhaps notice that some things can be implemented in a much different way than in their old favorite language.



-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 07, 2008
Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> Sergey Gromov wrote:
> > I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening.  This class is having this method called with these arguments.  That template is instantiated with those types.  Basically, it should be enough to read language specification to understand the code.  In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion.
> 
> Doesn't fit into the specs? How so? It's not like I'm preprocessing D.
> I've talked with a few folks who have been coding in D for a while, and
> they immediately recognized the constructs. The func call, proxy object,
> opIn and the inline delegate.
> It's not a surprise that fancy D code may cause confusion in D.learn,
> since well, it's an NG for beginners...

OK so I'm new to D, too.  It's a part of a problem.  I have quite strong C/C++/Java background, and I do like the strictness of Java.  But anyway.  opIn has a distinct default semantics in the language.  It's "check if," not an "apply to."  The ability to overload is here to mimic the default semantics for non-ordinary types.  It's a bad practice IMO to completely change operator semantics.  That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually.

That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code:

    module(L)
    [
        def("greet", &greet)
    ];

What it does, God knows.

-- 
SnakE
February 08, 2008
Sergey Gromov wrote:
> opIn has a distinct default semantics in the language.  It's "check if," not an "apply to."  The ability to overload is here to mimic the default semantics for non-ordinary types.  It's a bad practice IMO to completely change operator semantics.

Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams. Following semantics is one thing - sure. It's crucial when you're making your own Map container to support it in exactly the same way as the built-in AAs do. But if you can make your code more natural to write by abusing the operators a little - opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, anyone defining opMul for their matrix class/struct is breaking semantics. The spec states that opMul is commutative.


> That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually.

Wrong. As far as I know, it was added because D was supposed to have array operations, so you could say [1, 2] + [10, 10] and have [11, 12], not the concatenation.


> That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code:
> 
>     module(L)
>     [
>         def("greet", &greet)
>     ];
> 
> What it does, God knows.

It doesn't really matter. Would you actually know without looking at the implementation? It's easy to read, the language features used can be figured out rather easily.
What matters is that it's really easy to use. It's actually a very nice example of a DSL (Domain Specific Language) within C++. Would you rather write 4 times this much, in order just to have it look like the rest of C++ code? Because then, there's the low level C API...


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 08, 2008
What can I say.  I do not agree.  C++ committee is not the best exemplar.  Looking into implementation should be required to learn the details, not to understand what the hell is going on.  Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all.

Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> Sergey Gromov wrote:
> > opIn has a distinct default semantics in the language.  It's "check if," not an "apply to."  The ability to overload is here to mimic the default semantics for non-ordinary types.  It's a bad practice IMO to completely change operator semantics.
> 
> Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams. Following semantics is one thing - sure. It's crucial when you're making your own Map container to support it in exactly the same way as the built-in AAs do. But if you can make your code more natural to write by abusing the operators a little - opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, anyone defining opMul for their matrix class/struct is breaking semantics. The spec states that opMul is commutative.
> 
> 
> > That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually.
> 
> Wrong. As far as I know, it was added because D was supposed to have array operations, so you could say [1, 2] + [10, 10] and have [11, 12], not the concatenation.
> 
> 
> > That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code:
> > 
> >     module(L)
> >     [
> >         def("greet", &greet)
> >     ];
> > 
> > What it does, God knows.
> 
> It doesn't really matter. Would you actually know without looking at the
> implementation? It's easy to read, the language features used can be
> figured out rather easily.
> What matters is that it's really easy to use. It's actually a very nice
> example of a DSL (Domain Specific Language) within C++. Would you rather
> write 4 times this much, in order just to have it look like the rest of
> C++ code? Because then, there's the low level C API...

-- 
SnakE
February 08, 2008
On Feb 8, 2008 3:20 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> What can I say.  I do not agree.  C++ committee is not the best exemplar.  Looking into implementation should be required to learn the details, not to understand what the hell is going on.  Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all.

How is this different from other code? You have to look in any implementation code to figure out what's going on internally, be it with syntax sugar or not.

Anders