Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Some more in Apple UCSD Pascal (just for the record)
- A compilation can be a program, or one or more units separated
with semicolons and ending with a period.
Several units separated with semicolons? Strange. Kind of contradicts the meaning of "unit" (in the common meaning of the word) to me ...
There will have been pragmatic reasons for it, way back in 1980. With 64 or 128 Kbyte memory you need a lot of segmentation and chaining, therefore small units. There was no --automake feature.
But why couldn't they be in separate files (or at least in one file without special syntax, i.e. `unit Foo ... end. unti Bar ... end.', like GPC used to allow)? Without automake, this should have been better, since one would have been able to compile just some of the units, not everything if everything is in one file.
The basic idea in UCSD Pascal is that compilation is something that stops with a period. So, any units, comments or whatever may be after the period will not be compiled. This idea survived in traditional Macintosh Pascal compilers and in the GPC compiler argument --ignore-garbage-after-dot. Still, in UCSD Pascal you are free to put units in different files and compile them separately.
(Or, actually, I think they should have separated implementation details like segmentation from the logical unit structure, i.e. allow segmentation on a smaller than unit basis.)
I couldn't agree more, but look where we are twenty-four-years-later with a gcc back-end on platforms that do not support the section ("section-name") attribute ? A quarter century back in time !
- INTEGER type can be modified by a length attribute
Well, we have the `Size' attribute (probably different syntax, but the semantics might be the same?).
The 'Size' attribute denotes the number of decimal digits (BCD), not the number of bits.
<snip>
Again, if we have 128 bit integers someday, we could implement it (though binary, not BCD, but it shouldn't matter) -- though I don't like the syntax, of course ...
OK, if we have 128-bit integers someday, we can write ... attribute( decimals = 25) ?
- LONG INTEGER type, represented internally as a binary-coded
decimal (BCD) number (up to 36 digits)
Nice. :-( I guess when GCC will support 128 bit integers, we can declare it as such (or the exact subrange), since the internal representation shouldn't matter.
Because integer values are "discrete" numbers. In non-BCD floating point you have the problem that you cannot even represent something simple like 2 euro 13 exactly (which is a horror for accounting applications).
I know, but that's nothing to do with BCD, just integer (or fixed point) vs. floating point.
Well, in BCD floating-point 2 euro 13 can be represented exactly, in binary floating-point it can't.
I always use standard (binary) integers for monetary amounts (in cents).
GPC supports 64 bit integers. This suffices for 10^17 Euro (or $) -- probably enough for most country's debts for the next few years. ;-)
Yes, 64 bit integers are what I have missed in other compilers for that very reason.
SCAN( LIMIT, PEXPR, SOURCE)
You mean `Scan (42, <> 'A', Foo)'???
Quite amusing, isn't it ?
<rant subject="syntax" level="200%"> ...
Oh dear, I'm quite shocked. Why do people make up such strange things?
Well, it took evolution a million years (or so) to get from a dino to a Pascal programmer. In all those million years (or so) creativity has been a greater force than intelligence (otherwise no small dino's would have been born). That's the basic idea of evolution, unbound creativity limited by survival only, not by intelligence. You can't change the rules that easily, it has been with us for many million years. So, that's why it is so hard to be a real good programmer, it is against the unspelled creative forces of nature. You have to think with everything you do, think through the smallest detail and reject any bad idea. Besides, if you weren't very creative also, you wouldn't be a programmer.
What helps is a strong character - one that sternly says "you can't do that" - and a true sense of beauty - which makes you feel horrible if you do it anyway. Those who are not blessed with (besides their creativity) both a strong character and a real sense of beauty, need a "religion" that tells them from outside what to do and what not to do - look at all those C++ fanatics that truly believe the whole world changes as soon as they call a procedure a "method" and a parameter a "message" (or whatever). They *need* that believe.
(*) Just a thought.
Perhaps the syntax could be handled with more-advanced preprocessor features, in particular string handling. Something like:
{$define Scan(A, B, C) {$if MacroIsPrefix (<>, MacroTrim (B))} ScanNE (A, MacroRemovePrefix (<>, MacroTrim (B)), C) {$else} ScanEQ (A, MacroRemovePrefix (=, MacroTrim (B)), C) {$endif} }
But how do you propagate a "Scan" macro out of a UCSD compatibility unit ?
Such features are not present now, but it might be rather easy to add them to the new preprocessor. Of course, for this strange UCSD function, that's probably overkill, but that's not the only strange syntax we've seen recently. Perhaps we'd have to see how far we'd get (and which preprocessor features would be required), but if it helps to keep a substantial amount of those strange syntaxes out of the actual compiler, I'd be inclined to strengthen the preprocessor (though I haven't advocated the use of macros in general) ...
Certainly.
Regards,
Adriaan van Os