I'd hope there is a pragma to permit old style constants or you
immediately orphan all pre-existing Modula 2 code by requiring rework
just to try it out with the new compiler.
Constant delimiters 123'456'789 is there any reason why it can't be , (granted some cultures use "," for "." in FP numbers but M2 doesn't)
I'd hope there is a pragma to permit old style constants or you
immediately orphan all pre-existing Modula 2 code by requiring rework
just to try it out with the new compiler.
I am assuming you mean "number literals" when you say "old style constants".
We decided to abandon suffixed literals because they violate the very
design philosophy Wirth has promoted in all of his compiler design texts, namely that design should follow (a) human readability and (b) single
input symbol lookahead.
We decided to abandon suffixed literals because they violate the very design philosophy Wirth has promoted in all of his compiler design texts, namely that design should follow (a) human readability and (b) single
input symbol lookahead.
All literals are one symbol (done by tokenizer/scanner, not parser),
And I don't think readability is better or worse.
namely that design should follow (a) human readability and (b) single
input symbol lookahead.
All literals are one symbol (done by tokenizer/scanner, not parser),
Scientifically speaking there is no difference between lexing and parsing. The distinction is entirely arbitrary. It is merely made for the
convenience of the implementor. Some parsing methods don't make the distinction. See Dick Grune's seminal work on parsing techniques for a
more detailed discussion.
And I don't think readability is better or worse.
Readability, or at least some effects of it (or lack thereof) can be measured.
Suffix notation causes more eye movement which increases mental load which
is an indicator for lesser readability. The effect is not noticeable with very short literals such as 040H, but it increases significantly with
literal length.
Scientifically speaking there is no difference between lexing and parsing. The distinction is entirely arbitrary. It is merely made for the convenience of the implementor. Some parsing methods don't make the distinction. See Dick Grune's seminal work on parsing techniques for a more detailed discussion.
Regardless of wordplay, was Wirth's remark actually in such wider context?
Suffix notation causes more eye movement which increases mental load which is an indicator for lesser readability. The effect is not noticeable with very short literals such as 040H, but it increases significantly with literal length.
Afaik that only counts for untrained people. In trained people the shift
from characterwise to more wordwise reading compensates.
This is why natural languages also have suffixes.
convenience of the implementor. Some parsing methods don't make the
distinction. See Dick Grune's seminal work on parsing techniques for a
more detailed discussion.
Regardless of wordplay, was Wirth's remark actually in such wider context?
I do not accept the premise that there is a fundamental difference between lexing and parsing. As Dick Grune's work will attest, I am in good company.
This is why natural languages also have suffixes.
And the vast majority of suffixed use cases in natural languages are short words. Aplty, briefly, candidly, distantly, easily, fairly, grizly,
highly, etc etc etc. Very long words are generally nouns and they are
used without suffixes. Fussbodenschleifmaschinenverleih, not fussbodenschleifmaschinenverleihlich.
Well, it does matter if it is one char or one symbol lookahead.
Those are aggregates, not single words.
Moreover -lich is a suffix. (-like)
Anyway, most constants remain short. A few rare times you define a mask
with all like $FFFF or $7FFF (and its 64-bit variants), and those are repeating.
Funny that you chose to use prefixed literals there apparently out
of preference while at the same time calling that very choice
"totally bogus".
He's a core FreePascal member, so it's not surprising that he mentions
(Turbo Pascal-ish) '$' (hex) prefixes. Heck, I almost mentioned it myself!
On Wednesday, 31 August 2016 17:29:56 UTC+9, Marco van de Voort wrote:
Anyway, most constants remain short. A few rare times you define
a mask with all like $FFFF or $7FFF (and its 64-bit variants),
and those are repeating.
Funny that you chose to use prefixed literals there apparently out
of preference while at the same time calling that very choice
"totally bogus".
In any event, the world has moved on to those totally bogus prefix
literals in just about every notation imaginable while accepting the arguments presented in their favour. By contrast, those who are attached
to not totally bogus or totally not bogus suffix literals are in a vanishingly tiny minority.
He's a core FreePascal member, so it's not surprising that he mentions
(Turbo Pascal-ish) '$' (hex) prefixes. Heck, I almost mentioned it myself!
Yes I am aware of that. I pointed this out because of the apparent
hypocrisy involved: If Borland or the FPC project make that choice, apparently that is alright. But if we make that choice then it is
"totally bogus". This ain't right.
Yes I am aware of that. I pointed this out because of the apparent hypocrisy involved: If Borland or the FPC project make that choice, apparently that is alright. But if we make that choice then it is
"totally bogus". This ain't right.
"Totally bogus" was a reference to the reasons to change it, not suffix syntax in general. To my best knowledge Borland (and related dialects)
never changed from suffix from prefix.
If tomorrow sb arrived on the FPC lists/forum with similar arguments to change the syntax to suffix, I'd react the same.
If tomorrow sb arrived on the FPC lists/forum with similar arguments to
change the syntax to suffix, I'd react the same.
That's a strawman.
"I don't subscribe to your linguistic analysis of MY answer."
I hope I have now put it in a format you can understand.
On 2016-09-02, trijezdci <trijezdci@spam.sux> wrote:
He's a core FreePascal member, so it's not surprising that he mentions
(Turbo Pascal-ish) '$' (hex) prefixes. Heck, I almost mentioned it myself!
Yes I am aware of that. I pointed this out because of the apparent hypocrisy involved: If Borland or the FPC project make that choice, apparently that is alright. But if we make that choice then it is
"totally bogus". This ain't right.
"Totally bogus" was a reference to the reasons to change it, not suffix syntax in general. To my best knowledge Borland (and related dialects)
never changed from suffix from prefix.
If tomorrow sb arrived on the FPC lists/forum with similar arguments to change the syntax to suffix, I'd react the same.
I hope I have now put it in a format you can understand.
I was trying to be polite but you just don't seem to get it.
YOU WERE BEING RUDE with your language.
I was trying to be polite but you just don't seem to get it.
YOU WERE BEING RUDE with your language.
Pot, meet kettle.
Just to refocus this thread on technical concerns ....
Overall, it doesn't really matter. Small changes like this are the least
of anyone's worries.
I still prefer 0--h for hex, but that's just me.
0x and $ in Intel assembly, but I always found it odd. The overwhelming majority seems to prefer 0--h there. Of course, I also shun AT&T syntax,
but some people still prefer that (even though GAS has supported both
since many years), so who knows.
How does Ada do it? A quick search shows 16#FF# for 255. Similar (but
not quite) to Extended Pascal (16#FF) and Modula-3 (16_FF).
On Saturday, 3 September 2016 06:27:39 UTC+9, rug...@gmail.com wrote:
Overall, it doesn't really matter. Small changes like this are
the least of anyone's worries.
It would seem totally whacko but this is the kind of thing you
will observe when taking quality to the extreme. There is nothing
that can be ruled out as "doesn't really matter". Everything has
a potential effect on the product. Everything matters, no matter
how tiny.
I mostly agree, though I'm sure someone somewhere can still make
a case for octal. But surely it shouldn't be preferred over hex.
On Sunday, 4 September 2016 08:47:59 UTC+9, rug...@gmail.com wrote:
But, in hindsight, I agree that these problems can occur
if you're not careful.
The point is that while insignificant looking items may have less
impact when they are seen in ISOLATION, they have a significantly
higher impact when PUT TOGETHER. The sheer number of little things
contribute significantly to the total. Therefore, it is worthwhile
also paying attention to minute details.
Let me just show a small example from one old assembler:
mov ax,111b ; binary
mov bx,0111b ; leading zero is hex (default, but +D uses binary)
Well, that's not even an argument about prefix or suffix because
it uses both prefix and suffix at the same time and they are in
conflict with each other.
That's just bad design. A design should stick to either prefix
or suffix.
So the problem is several-fold:
* trying to be (mostly) compatible
Indeed, backwards compatibility is more often a curse than it is
a blessing. And if you break it, better break it for good, don't
make it look like it is still is compatible when it actually isn't.
This comes down to the principle of least surprise again.
Our design principles expressly state that backwards compatibiity
must not interfere with any other design goals. It has the lowest
priority by definition.
* trying to be unambiguous
I disagree on that one. Ambiguity is a very significant contributor
to error.
The problem arises when you allow other less important
goals such as backwards compatibility to interfere and the only
way to reconcile conflicting design goals is to produce an
unnecessarily complex and confusing design.
* non-standard (thus unfamiliar) extensions
Standard does not always mean familiarity. De facto standard
perhaps.
But the de facto standard for number literals is the
0x, 0u, 0b prefix convention. Many more languages use that than
any other. And millions of practitioners across a large spectrum
of languages are familiar with it.
By contrast, there are only a few hundred people on the entire
planet who are familiar with the literals of classic Modula-2's.
Of course Wirth later omitted base-8 in Oberon. Thirty years on,
it is about time we removed base-8 from all languages. In our day
and age it has no practical use whatsoever. It has become a
ridiculous artefact.
mov ax,111b ; binary
mov bx,0111b ; leading zero is hex (default, but +D uses binary)
Well, that's not even an argument about prefix or suffix because
it uses both prefix and suffix at the same time and they are in
conflict with each other.
I wouldn't consider '0' a prefix for binary. Most assemblers treat
it as part of the number, not a special char. My point was that I
assume he thought extra 0000 (before any 1) was superfluous, thus
the (convenient? confusing!) adjustment for other bases (which
thankfully can be overriden).
That's just bad design. A design should stick to either prefix
or suffix.
Indeed, backwards compatibility is more often a curse than it is
a blessing. And if you break it, better break it for good, don't
make it look like it is still is compatible when it actually isn't.
This comes down to the principle of least surprise again.
I consider compatibility a noble virtue, but sometimes the burden
is too heavy. For small projects, it's probably easier to eschew
any formalities and just hack out whatever works.
But overall, I'd prefer (de facto or de jure) "standard". This
is why some compilers support various competing dialects. Sure,
it's harder to achieve good compatibility (accept good code,
reject bad code), but overall I think it's worth it.
(GPC and FPC are good exemplars of this virtue.)
Our design principles expressly state that backwards compatibiity
must not interfere with any other design goals. It has the lowest
priority by definition.
Yes and no. I understand sometimes it's a heavy burden to shoehorn
everything into a small compatible subset. But overall I'm tired of non-portable code.
Compiler-specific code isn't much better than assembly (regarding portability). Anything that's worth doing is probably worth doing
portably (to as many targets as possible).
* trying to be unambiguous
I disagree on that one. Ambiguity is a very significant contributor
to error.
I think you misunderstood (due to my poor wording). I'm in no way
advocating for ambiguity as a good thing.
But the de facto standard for number literals is the
0x, 0u, 0b prefix convention. Many more languages use that than
any other. And millions of practitioners across a large spectrum
of languages are familiar with it.
Let's not overstate the universality of it. Nothing is totally
widely accepted everywhere.
By contrast, there are only a few hundred people on the entire
planet who are familiar with the literals of classic Modula-2's.
Again, this might be a bit exaggerated (but the number has probably
decreased heavily since the '80s).
I mostly agree, though I'm sure someone somewhere can still make
a case for octal. But surely it shouldn't be preferred over hex.
I still don't think it's worthy of major attention or worry. Bugs
happen, but you're more likely to run into other issues (e.g.
mishandled dynamic memory) than this.
But, in hindsight, I agree that these problems can occur
if you're not careful.
Let me just show a small example from one old assembler:
mov ax,111b ; binary
mov bx,0111b ; leading zero is hex (default, but +D uses binary)
So the problem is several-fold:
* trying to be parsimonious (as dmr remarked about both himself and Wirth)
* trying to be (mostly) compatible
* trying to be unambiguous
* having defaults that can be (obscurely) changed
* non-standard (thus unfamiliar) extensions
Assemblers themselves are (mostly) case insensitive (like Pascal),
so it's not true that 'h' is always preferred (even if I partially
agree with you).
BTW, although it was supported, I never saw anybody use octal.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 468 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:34:30 |
| Calls: | 9,440 |
| Calls today: | 3 |
| Files: | 13,594 |
| Messages: | 6,109,829 |