On Tue, 07 Jul 2009 17:17:48 -0400, Ali Çehreli wrote:

> Leandro Lucarella Wrote:
> 
>> Can you at least use:
>> case X:
>> ..
>> case Y:
>> 
>> in the examples/documentation/specs? I think most case X: .. case Y: haters found that format pretty acceptable
> 
> I like that syntax too, but not a good idea to use in the Digital Mars code samples, because another one with an extra dot is already being used to mean "omitted lines of code":
> 
> case X:
> ...
> case Y:
> 
> Ali

:D That just gives reason not to use ... for a separator. I love it.

I can definitely see this as a misguided step for a new user.

"A case range can be used like:

switch (i)
{
    case 1:
    ..
    case 3:
        x = 4;
        break;
}"

And the resulting code by the new user:

switch (i)
{
    case 1:
    case 2:
    case 3:
        x = 4;
        break;
}

Andrei Alexandrescu wrote:
> Derek Parnell wrote:
>> I would not complain if trailing dot and leading dot were disallowed.
> 
> I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one.

It seems rather disingenuous to complain loudly about '...' used as a separator, but to accept leading/trailing dots without question.  I'm sure you remember this list:

> 0.....wyda
> 0....wyda
> 0... .wyda
> 0. .. .wyda
> 0.... wyda
> 0. ...wyda
> 0. ....wyda
> 0.. .wyda

I'm sure you agree that this is a mess.  Never mind if any of these token sequences are syntactically valid, this is a mess at the lexical level.  If '0.....wyda' is interpreted as the token sequence '0. ... . wyda', then you have bigger things to worry about than whether or not that token sequence is ever syntactically valid.


-- 
Rainer Deyke - rainerd@eldwood.com

Hello Walter,

> BCS wrote:
> 
>> Hello Walter,
>> 
>>> Jarrett Billingsley wrote:
>>> 
>>>> Totally agree.  They're cruft that just complicate lexical
>>>> analysis.
>>>> 
>>> Not a significant issue, as the code to lex it is done, works, and
>>> is readily available.
>>> 
>> But that assumes that just using the lexer is acceptable. What if
>> someone needs to generate there own lexer? Say in a different
>> language, like D?. Or they want to generate a token highlighter?
>> 
> Oh please, it's trivial to translate.
> 

Not to regex. 

>> Or what about if they need to make a tool in a shop that has a bad
>> case of NIH? Or where they must /own/ the code for legal reasons.
>> 
> For a fee that would be less than what it would cost them to develop a
> simpler integer lexer, I'd license it to them under whatever terms
> they want.
> 

What would you sell it outright for? As in I would own it and have every right I would have if I was the original author.

BCS wrote:
> What would you sell it outright for? As in I would own it and have every right I would have if I was the original author.

As a non-exclusive license, probably $500. If you can develop it for less than that, then it wasn't really that hard <g>. For less than $500, it isn't even worth spending the time writing a contract.

Rainer Deyke wrote:
> Never mind if any of these
> token sequences are syntactically valid, this is a mess at the lexical
> level.  If '0.....wyda' is interpreted as the token sequence '0. ... .
> wyda', then you have bigger things to worry about than whether or not
> that token sequence is ever syntactically valid.

Back in the 80's, there was some n.g. discussion about what x++++y meant and how it was lexed and parsed. The best answer was:

"Here a plus, there a plus, everywhere a plus plus."

Derek Parnell wrote:
> So ...
> Octal literals are so common that we need compiler/language support.
> Character ranges are so rare that we do not need compiler/language support.
> Compatibility with C is paramount, except when it's not.
> Technical merit trumps human interface.

If you're looking for absolutes in any useful engineering design, you won't find them.

You might be interested in this paper:

A. R. Koenig and B. Stroustrup: As Close as Possible to C - but no Closer. The C++ Report. Vol 1 No 7 July 1989. Also, AT&T C++ Translator Release Notes, February 1990.

> I think that I'm not ready for the D programming language after all. I'll
> drop by the sandbox from time to time out of curiosity, I suppose. Good
> luck and thanks for all the fish.

You'll be welcome back anytime you want!

Derek Parnell wrote:
> So ...

... just in case you look over your shoulder:

> Octal literals are so common that we need compiler/language support.

We don't need, we have it.

> Character ranges are so rare that we do not need compiler/language support.

This is just immature. It's not that character ranges are rare; it's
just that we can express them properly without some special mechanism.

> Compatibility with C is paramount, except when it's not.

You didn't understand. Compatibility with C is important in the sense
that we want to have a clean-cut answer to a function rsa_encrypt()
taken from C and pasted into D: either it compiles and runs with the
same result, or it doesn't compile. That's the scenario. I don't
understand how you make a case of duplicity out of this one.

> Technical merit trumps human interface.

Humans define technicality. To your question "Would any answer make a
difference?" I retorted "Of course, as long as it has technical merit."
Maybe that answer was misunderstood - I mean technical as opposed to the
nontechnical arguments that had been put forth.

> I think that I'm not ready for the D programming language after all. I'll
> drop by the sandbox from time to time out of curiosity, I suppose. Good
> luck and thanks for all the fish.

Out of curiosity, which superior language are you careening towards?

(I'd also be curious what "superdude" would answer to that. I recall he
managed in the *same post* to state some utterly conflicting
requirements for his would-be language, sort of like a woman who wants a
guy who's "strong, you know, but also totally sensitive." Then superdude
kind of implicitly concluded he has no idea where to go but left
nonetheless with the tail up. How competent does one have to be to make
even the last proud shot a misfire?)

Anyhow... it would be a bummer if the negative atmosphere as of late in the group would cause people like you just lose interest. I can't understand what's going on. It starts looking like a disfunctional relationship: the more Walter and others do, the less content people on the group are. I don't care much for being pat on the back, but it's extremely disheartening to see that the more we do the more we're getting yelled at. What I guess I'll do is just lay low and wait for the negative ions to go away.


Andrei

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> Derek Parnell wrote:
>>> I would not complain if trailing dot and leading dot were disallowed.
>> I think the question that should be asked is: would anyone complain if
>> they were kept? We have bigger rocks to move than that one.
> 
> It seems rather disingenuous to complain loudly about '...' used as a
> separator, but to accept leading/trailing dots without question.

Well it's rather congruent. The leading and trailing dots have been in the language for a good while and haven't caused major problems. So I am not bent on eliminating them. On the other hand, I don't feel like throwing ellipses in the mix just to make things more confusing.

> I'm
> sure you remember this list:
> 
>> 0.....wyda
>> 0....wyda
>> 0... .wyda
>> 0. .. .wyda
>> 0.... wyda
>> 0. ...wyda
>> 0. ....wyda
>> 0.. .wyda
> 
> I'm sure you agree that this is a mess.

I do.

> Never mind if any of these
> token sequences are syntactically valid, this is a mess at the lexical
> level.

They all are parsable if ellipsis is to be allowed as separator. Not at all. They are very easy to parse lexically. It's the humans who have problems.

> If '0.....wyda' is interpreted as the token sequence '0. ... .
> wyda', then you have bigger things to worry about than whether or not
> that token sequence is ever syntactically valid.

What you describe is standard lexing. The sequence 0.....wyda is lexed using maximum munch (the longest thing that looks like a token is chosen left to right). First we have a 0 and so the longest token is 0. Then follow four dots, but a maximum of three form a token. Finally, we have .wyda which is a token. And that's about it. The rule is not complicated, but of course having to count the dots and exacerbating the importance of whitespace placement is undesirable.


Andrei

Hello Walter,

> BCS wrote:
> 
>> What would you sell it outright for? As in I would own it and have
>> every right I would have if I was the original author.
>> 
> As a non-exclusive license, probably $500.

Not a license, *own*. As in I *own* my hat. (ignoring the question of would you still own your copy)

But that's really beside the point. I could come up with several somewhat reasonable reasons why "just use my code" isn't a good answer to having gotcha in the lexical spec. If you really want to go that way, then the lexical spec should officially BE the lexer source code.

BCS wrote:
>> BCS wrote:
>>
>>> What would you sell it outright for? As in I would own it and have
>>> every right I would have if I was the original author.
>>>
>> As a non-exclusive license, probably $500.
> 
> Not a license, *own*. As in I *own* my hat. (ignoring the question of would you still own your copy)

You can't have two people own the same copyright. One owns the copyright, and the other has a non-exclusive license to do whatever he wants with it. The other has effective ownership, but it's done as a license.

I'm not going to transfer the copyright, because then what am I going to put in the D compiler?


> But that's really beside the point. I could come up with several somewhat reasonable reasons why "just use my code" isn't a good answer to having gotcha in the lexical spec. If you really want to go that way, then the lexical spec should officially BE the lexer source code.

I don't see where the "gotcha" is. It's not trivial, but it's specifiable, and the code implementing it is there and is correct.