On 11.12.2024 03:21, bart wrote:
On 09/12/2024 18:46, Janis Papanagnou wrote:
An unambiguous grammar is something quite essential; how would you
parse code if it were ambiguous?
You can easily parse a language in an ambiguous syntax. [...]
Sure; I recall Fortran had such an ambiguity, I think it was in
context of FOR loops (something with the assignment and commas,
IIRC). - Whether it's "easily [to] parse" is arguable, though,
and certainly depends. - But I don't recall to have seen scary
things like that in any other language I had to do with.
Experienced language developers wouldn't define an ambiguous
syntax in the first place. So what do you think your statement
contributes to desire to have an "unambiguous syntax"?
I mean, if you get confused by an unambiguous syntaxes already,
what do you think happens with people if they have to program
in or understand an ambiguous language!
You postulate it as if the grammar were convoluted;
My opinion is that it is. Especially its propensity for using
long-winded production terms that look confusingly similar. (Would it
have killed somebody to make the names more distinct?)
(I won't comment on your opinion.)
With respect to distinctness of names I thought we had already
exchanged some words - remember my 'while' and 'until' samples
from Pascal (that somehow offended you)?
Concerning "C"; I don't see why you shouldn't name a "positive"
conditioned control construct consistently(!) as 'while' whether
it controls a loop entry or a loop exit, and to name a "negative"
conditioned control construct consistently(!) as 'until'.
It's beyond me why one wants to replace a semantically consistent
set like
'while' positive-case 'do' ...
'until' negative-case 'do' ...
'do' ... 'while' positive-case
'do' ... 'until' negative-case
by, say,
'pre_while' positive-case 'do' ...
'pre_until' negative-case 'do' ...
'do' ... 'post_while' positive-case
'do' ... 'post_until' negative-case
(Feel free to find better names than 'pre_xxx' and 'post_xxx'; it
wouldn't change the "semantical consistency" argument.)
So you're a parser and you see this:
>
do ... while
>
How do you know whether that 'while' starts a new nested loop or
terminates this one?
>
Because there's the '...' in between that answers that question.
Oh, I see. That answers everything! Including having a '...' that
includes statements starting with 'while'.
Yes, the "syntax" is not only an isolated symbol. - Please keep my
suggestion in mind to consider learning about formal languages and
grammars. (I think for a compiler writer it should be a given.)
If you look at symbols like a tokenizer you won't understand what
any programmer needs to know to understand a language; (besides
other things) the structure!
[...]
My opinion about this feature remains the same, that it was a poor
design choice. One of dozens of such choices. An unambiguous grammar
does not by itself make for a good syntax.
No one said it would.
You however seem utterly incapable of criticising C.
I already said that 98% of your imputations are certainly wrong and
you should just stop that; even if you have no argument, better just
shut up instead. - In this case, though, there wouldn't even have
been the need for you to make imputations; my various criticisms on
the language "C" is quite good documented in this newsgroup.
I already said that I had a lot of criticism with various languages
that I'm programming with, but, as oppose to you, I don't complain
constantly and repeatedly about that. You could also have observed
that many folks here (also repeatedly) told you that they know about
the [real] deficiencies of the "C" language.
Could you write an
article all about its quirks and gotchas and flaws? I doubt it.
Of course I could. I could even write articles about pros and cons
of every language I've made experiences with; on a principal level
(for example design) and on a practical level. (But why should I?)
The problem(s) that you have is (are) far beyond what I'd consider
to be a sensible criticism. But I accept that you have own opinions
on what's a problem [to you].
Janis
[...]