Walter Bright wrote:
> 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.
> 

Been there. Trivial, but really obnoxious for this and a few other points. My ll(k) lexer grammar is ugly and hackish, and probably still buggy.

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> On Tue, Jul 7, 2009 at 11:20 PM, Walter
>>> Translating C code to D.
>>
>> I don't see this as a reasonable justification.  Octal isn't used that
>> much in C either, and D is already so far from C that you need an
>> automated tool to do it, so you might as well just have the tool
>> translate them.  The compiler could even disallow leading zeroes,
>> giving you an error on any integer literals that weren't automatically
>> translated.
> 
> I've translated code, and a tool isn't really necessary. But translating octal constants to hex like 077733 is very error prone. And yes, I ran into a bunch of them just recently in the OSX system header files. So they exist. I don't see a good reason to make things difficult to translate.

Make a leading 0 illegal, and either:
(1) change the octal syntax into 0c77733,
or(better) (2) provide an octal conversion function in the standard library.

Because of CTFE, so we can actually do (2) very nicely. I don't see any need for it to be a language feature when a library can do a better job.

Walter Bright wrote:
> 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."

What I'd really like to see is a lexer that parses operators by rules rather than lists.  If '+' is a token and '++' is a single token, then '+++' and '++++++++++' should also be recognized as tokens (which aren't used by the language).

The only actual effect would be to would turn currently legal expressions like 'a+++++b' (and '5....a') into syntax errors.


-- 
Rainer Deyke - rainerd@eldwood.com

Don wrote:
> Make a leading 0 illegal,

I'm not sure what benefit that accomplishes.

> and either:
> (1) change the octal syntax into 0c77733,
> or(better) (2) provide an octal conversion function in the standard library.
> 
> Because of CTFE, so we can actually do (2) very nicely. I don't see any need for it to be a language feature when a library can do a better job.

Walter Bright wrote:
> Don wrote:
>> Make a leading 0 illegal,
> 
> I'm not sure what benefit that accomplishes.

It catches occasional mistakes such as:
int [] foo = [
  001
  010
  100
];

which are admittedly very rare, though it actually happened to me earlier this year. It's quite baffling when it happens -- took me ages to track down. It's pretty similar to the way you made 'l' illegal as a integer suffix.

int x = 0011l;

Looks like x==111, but in C, x is 9!

Jarrett Billingsley, el  7 de julio a las 22:28 me escribiste:
> On Tue, Jul 7, 2009 at 8:08 PM, bearophile<bearophileHUGS@lycos.com> wrote:
> > Nick Sabalausky:
> >> why in the world is anyone defending the continued existance of "5." and ".5"?<
> >
> > I'm for disallowing them; 5.0 ad 0.5 are better.
> > Anyone else pro/against this idea?
> 
> Totally agree.  They're cruft that just complicate lexical analysis.

Me Too! (TM)

> > Regarding number literals, I'm also for:
> > B) turning the current octal syntax into a syntax error and
> > introducing a safer octal syntax (see Python 3);
> 
> Or just drop octal altogether.  Outside of chmod, when is there any legitimate need for it these days?

I think being a system language, that alone is a good reason to keep some sort of octal notation. But well, maybe for these rare cases a nasty "compile-time string literal" can be used like chmod(path, oct!("664"));

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, standing in the aisles
With itchy feet and fading smiles
Can you feel me?

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

Eh. You know, we have something like... what was it called? Link compatibility to C!

Also, your paragraph about superdude shows that you just can't forgot about people who aren't as awesome as you and who attacked you in one way or another. Learn to be more like Walter, or you'll piss off even more people. I mean, you don't want that, and the community doesn't want that either.

Jarrett Billingsley, el  7 de julio a las 23:40 me escribiste:
> On Tue, Jul 7, 2009 at 11:20 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> > 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.
> 
> I'm not going to argue this anymore.

I will =)

That's not a good enough reason. Having *one* front-end (lexer/parser/semantic analizer) is not good enough. D was supposed to make this easy to encourage different implementations. If the D specs are twisted and making a new lexer is... confusing, I think that's a failure.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
FALTAN 325 DIAS PARA LA PRIMAVERA
	-- Crónica TV

grauzone wrote:
>>> 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.
> 
> Eh. You know, we have something like... what was it called? Link compatibility to C!
> 
> Also, your paragraph about superdude shows that you just can't forgot about people who aren't as awesome as you and who attacked you in one way or another. Learn to be more like Walter, or you'll piss off even more people. I mean, you don't want that, and the community doesn't want that either.

*cough* pot *cough* kettle *cough* black... :o)

Andrei

> *cough* pot *cough* kettle *cough* black... :o)

Are you alright?