On 13/10/2021 00:19, Andy Walker wrote:
> On 12/10/2021 17:41, Bart wrote:

>> No need. For turning text into binary, the necessary checks can be
>> done on the string.
>
>     In which case the trap won't be sprung.  It costs you nothing,
> so you don't need even to think about it.

You do need to think about it. My apps used to consist of a compiled
main application, with hot-loaded bytecode modules to execute user-commands.

If a module went wrong (say, the interpeter detected out-of-bounds array
accesses), it would then terminate that module and return to normal
input, requesting the next command (actually, another intepreted module
with an input loop, this in a GUI app).

What you don't want is some silly overflow in a module (which may be
written in this scripting language by a third party), from bringing down
the entire application, and losing the user's work for that day.

Modern apps aren't just doing one big calculation, like feeding a list
of cards into Multivac (Asimov's giant computer), and some time later,
spitting out a card with the answer.

>> And unless there's some way of selectively disabling it, it means
>> programs at risk of crashing, and losing customer's work and data,
>> for something that might be harmless.
>
>     It /might/ be harmless.  How would anyone know?  You asked
> the computer to work out, in your example, "a*10+c", and it failed
> to do so.  If you don't care what "a*10+c" is, why is that code in
> there in the first place?

So we're back to this. a*10+c isn't some theoretical mathematical term
which is always going to have some exact numeric result, so long as you
don't actually have to evaluate it.

It's doing the calculation within the limitations of, say, the 64-bit
ALU of a processor which represents integers using two's complement.

Then how it behaves near the boundaries of those limitations, how much
it insulates those realities from the user, is a choice involving both
the language and application.

(Most people have little control over the former; only over the latter.
Unusually I'm in charge of both.)

My approach is lax, but that's OK because I'm not writing programs to
send rockets into space (and back).

There so many other of things of greater impact on my programs.

If people complain that 'print 2**3**4' displays 0 instead of
2417851639229258349412352, then I just play the UB card like C does.
Users of the language need to take care around those limits.

If they really need that result, I would suggest using the bignum
feature of my other language.

I understand that if /you/ were implement a language, it would do things
perfectly. It would display 2**3**4**5 exactly (even if it takes a
while, or exhausts your machine's memory). I tend to cut a few corners.

On 13/10/2021 12:01, Bart wrote:

> If people complain that 'print 2**3**4' displays 0 instead of
> 2417851639229258349412352, then I just play the UB card like C does.
> Users of the language need to take care around those limits.

BTW, A68G displays 4096 for the result of 2**3**4. Now /that/ is
unexpected! It uses the wrong precedence for **. With parentheses added,
it does report an overflow.

On 13/10/2021 12:13, Bart wrote:
> BTW, A68G displays 4096 for the result of 2**3**4. Now /that/ is
> unexpected!

To you, perhaps. But it's in accord with the Report, and
with the precedents of Algol 60 and IAL, so it's been "expected"
for over 60 years. Traditional mathematics has no equivalent, as
exponentiation is normally indicated by indexes, not by operators,
and many languages don't implement exponentiation operators either
[preferring to use functions instead] so there is no solid general
prior expectation to guide us.

> It uses the wrong precedence for **.

If you meant that it associates the same way around as
other operators, that may not be your expectation but Algol took
the view that consistency was more important. Operators of equal
precedence always associate such that "a op b op c" means
"(a op b) op c". You could make a case for it always to mean
"a op (b op c)" [tho' then (eg) "a-b-c" would surprise most of
us], but you would be hard pushed to make a coherent case for
mixing them. You would have to add new syntax, and it would be
quite hard to read/express.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Valentine

On 13/10/2021 23:12, Andy Walker wrote:
> On 13/10/2021 12:13, Bart wrote:
>> BTW, A68G displays 4096 for the result of 2**3**4. Now /that/ is
>> unexpected!
>
>     To you, perhaps.  But it's in accord with the Report, and
> with the precedents of Algol 60 and IAL, so it's been "expected"
> for over 60 years.  Traditional mathematics has no equivalent, as
> exponentiation is normally indicated by indexes, not by operators,
> and many languages don't implement exponentiation operators either
> [preferring to use functions instead] so there is no solid general
> prior expectation to guide us.

I think it has. The operators are implicit: 3x² has always been 3*(x**2)
or 3*(x^2).

>
>>           It uses the wrong precedence for **.
>
>     If you meant that it associates the same way around as
> other operators, that may not be your expectation but Algol took
> the view that consistency was more important.  Operators of equal
> precedence always associate such that "a op b op c" means
> "(a op b) op c".  You could make a case for it always to mean
> "a op (b op c)" [tho' then (eg) "a-b-c" would surprise most of
> us], but you would be hard pushed to make a coherent case for
> mixing them.  You would have to add new syntax, and it would be
> quite hard to read/express.

If I type 2**3**4 or 2^3^4 into Google, it gives me the larger value (so
using using right-to-left precedence) rather than the smaller.

So that appears to be the expectation these days.

Also, if I do:

print *, 2**3**4

in Fortran (via rextester.com) it appears to parse as 2**(3**4) too.
Fortran is even older than Algol (I don't know if at some point it did
something different; but it's unlikely they would have changed it).

BTW that Fortran displays 0; another language, and a very famous one,
that treats overflow lightly.

With Ada, it says it needs parentheses for Ada. With those in place, it
reports a range error. It does it both for compile-time, runtime
(constraint error) and can warn

So I guess if you're worried about this stuff, then use Ada. My language
isn't Ada.

On 2021-10-14 00:12, Andy Walker wrote:

>     If you meant that it associates the same way around as
> other operators, that may not be your expectation but Algol took
> the view that consistency was more important.  Operators of equal
> precedence always associate such that "a op b op c" means
> "(a op b) op c".  You could make a case for it always to mean
> "a op (b op c)" [tho' then (eg) "a-b-c" would surprise most of
> us], but you would be hard pushed to make a coherent case for
> mixing them.

In Ada a**b**c is syntax error as well as -a**b. You must disambiguate
such stuff.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 13/10/2021 12:01, Bart wrote:
>>> No need. For turning text into binary, the necessary checks can be
>>> done on the string.
>>      In which case the trap won't be sprung.  It costs you nothing,
>> so you don't need even to think about it.
> You do need to think about it. My apps used to consist of a compiled
> main application, with hot-loaded bytecode modules to execute
> user-commands.
> If a module went wrong [...].
> What you don't want is some silly overflow in a module (which may be
> written in this scripting language by a third party), from bringing
> down the entire application, and losing the user's work for that
> day.

Repeat -- /if/ you have done the checks, /then/ the trap
won't be sprung [and it has cost you nothing and it doesn't matter
what would have happened if the trap had been sprung]. If your
users care what their work actually does, then an overflow is not
"silly", it means they are getting the wrong answers. It must be
a bizarre application if getting wrong answers doesn't matter.
Otherwise, you either [again] build in the checks, and the trap
won't be sprung, /or/ you spend a few moments /once/ writing a
trap handler [which in this case would presumably be "print an
error message and go to the end of this module"]. It's easier
to write one simple trap handler than to add checks to all the
modules as and when you import them. Shell scripts [eg] can use
the "trap" command; C programs can use the stuff defined [eg]
in N1570 section 7.14 and/or Annex H [on "language independent
arithmetic", which might interest James].

[...]
>>      It /might/ be harmless.  How would anyone know?  You asked
>> the computer to work out, in your example, "a*10+c", and it failed
>> to do so.  If you don't care what "a*10+c" is, why is that code in
>> there in the first place?
> So we're back to this. a*10+c isn't some theoretical mathematical
> term which is always going to have some exact numeric result, so long
> as you don't actually have to evaluate it.
> It's doing the calculation within the limitations of, say, the 64-bit
> ALU of a processor which represents integers using two's complement.> Then how it behaves near the boundaries of those limitations, how
> much it insulates those realities from the user, is a choice
> involving both the language and application.

Yes, but when "a*10+c" overflows, you [apparently] aren't
checking, nor are you trapping the operations, so your users have
no idea that their answers are completely bogus. Yes, it's your
choice; I hope your users know what your decision was, and know
not to use your code to work out their payroll ....

> If people complain that 'print 2**3**4' displays 0 instead of
> 2417851639229258349412352, then I just play the UB card like C does.

C doesn't. Some implementations of C do. Guess what,
those are the implementations that David and I complain about.
C can be made to behave properly [see the above-mentioned parts
of N1570, for example]; but it's harder than it should be.

> I understand that if /you/ were implement a language, it would do
> things perfectly.

Thanks for your confidence.

> It would display 2**3**4**5 exactly (even if it
> takes a while, or exhausts your machine's memory).

Doesn't need me to implement anything:

$ a68g -p 2**3**4**5
a68g: runtime error: 1: INT math error [...]
$ a68g -p "LONG 2**3**4**5"
+1152921504606846976

> I tend to cut a
> few corners.

Yes, we'd noticed. Nothing wrong with cutting corners
as long as everyone concerned knows that's how you operate and
is happy that the computing work they are paying for is of that
standard.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Forbes

On 14/10/2021 00:33, Bart wrote:
[I wrote:]
>> [...] Traditional mathematics has no equivalent, as
>> exponentiation is normally indicated by indexes, not by operators,
>> and many languages don't implement exponentiation operators either
>> [preferring to use functions instead] so there is no solid general
>> prior expectation to guide us.
> I think it has. The operators are implicit: 3x² has always been
> 3*(x**2) or 3*(x^2).

That doesn't help to determine what "a**b**c" ought to
mean, as that expression is not traditional mathematics and has
no equivalent therein. Maths instead uses a hierarchy of super-
and sub-scripts using smaller or larger type, which supplies the
disambiguation.

> If I type 2**3**4 or 2^3^4 into Google, it gives me the larger value
> (so using using right-to-left precedence) rather than the smaller.
> So that appears to be the expectation these days.
> Also, if I do:
> print *, 2**3**4
> in Fortran (via rextester.com) it appears to parse as 2**(3**4) too.
> Fortran is even older than Algol (I don't know if at some point it
> did something different; but it's unlikely they would have changed
> it).

Very possibly, but irrelevant. In the early days of
computing, there were no accepted standards, and language
designers made their own decisions, so there are examples
of L->R associativity and of R->L associativity. There are
payoffs either way. Early Algols and derivatives chose to
go for the simpler syntax. By Algol 68 it would have been
very difficult [and error prone] to define operators with
variable associativity, so "a**b**c" virtually has to
associate the same say as "a-b-c" [which /does/ have a long-
established traditional meaning], bearing in mind that all
A68 operators are defined via a simple uniform syntax.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Forbes

On 14/10/2021 21:31, Andy Walker wrote:
> On 13/10/2021 12:01, Bart wrote:
>>>> No need. For turning text into binary, the necessary checks can be
>>>> done on the string.
>>>      In which case the trap won't be sprung.  It costs you nothing,
>>> so you don't need even to think about it.
>> You do need to think about it. My apps used to consist of a compiled
>> main application, with hot-loaded bytecode modules to execute
>> user-commands.
>> If a module went wrong [...].
>> What you don't want is some silly overflow in a module (which may be
>> written in this scripting language by a third party), from bringing
>> down the entire application, and losing the user's work for that
>> day.
>
>     Repeat -- /if/ you have done the checks, /then/ the trap
> won't be sprung [and it has cost you nothing and it doesn't matter
> what would have happened if the trap had been sprung].  If your
> users care what their work actually does, then an overflow is not
> "silly", it means they are getting the wrong answers.  It must be
> a bizarre application if getting wrong answers doesn't matter.
> Otherwise, you either [again] build in the checks, and the trap
> won't be sprung, /or/ you spend a few moments /once/ writing a
> trap handler [which in this case would presumably be "print an
> error message and go to the end of this module"].  It's easier
> to write one simple trap handler than to add checks to all the
> modules as and when you import them.  Shell scripts [eg] can use
> the "trap" command;  C programs can use the stuff defined [eg]
> in N1570 section 7.14 and/or Annex H [on "language independent
> arithmetic", which might interest James].
>
> [...]
>>>      It /might/ be harmless.  How would anyone know?  You asked
>>> the computer to work out, in your example, "a*10+c", and it failed
>>> to do so.  If you don't care what "a*10+c" is, why is that code in
>>> there in the first place?
>> So we're back to this. a*10+c isn't some theoretical mathematical
>> term which is always going to have some exact numeric result, so long
>> as you don't actually have to evaluate it.
>> It's doing the calculation within the limitations of, say, the 64-bit
>> ALU of a processor which represents integers using two's complement.>
>> Then how it behaves near the boundaries of those limitations, how
>> much it insulates those realities from the user, is a choice
>> involving both the language and application.
>
>     Yes, but when "a*10+c" overflows, you [apparently] aren't
> checking, nor are you trapping the operations, so your users have
> no idea that their answers are completely bogus.  Yes, it's your
> choice;  I hope your users know what your decision was, and know
> not to use your code to work out their payroll ....
>
>> If people complain that 'print 2**3**4' displays 0 instead of
>> 2417851639229258349412352, then I just play the UB card like C does.
>
>     C doesn't.  Some implementations of C do.  Guess what,
> those are the implementations that David and I complain about.
> C can be made to behave properly [see the above-mentioned parts
> of N1570, for example];  but it's harder than it should be.
>
>> I understand that if /you/ were implement a language, it would do
>> things perfectly.
>
>     Thanks for your confidence.
>
>>             It would display 2**3**4**5 exactly (even if it
>> takes a while, or exhausts your machine's memory).
>
>     Doesn't need me to implement anything:
>
>   $ a68g -p 2**3**4**5
>   a68g: runtime error: 1: INT math error [...]
>   $ a68g -p "LONG 2**3**4**5"
>                   +1152921504606846976
>
>>                              I tend to cut a
>> few corners.
>
>     Yes, we'd noticed.  Nothing wrong with cutting corners
> as long as everyone concerned knows that's how you operate and
> is happy that the computing work they are paying for is of that
> standard.

Actually I mostly used floats in my main application (2D and 3D drafting
and modelling). (That is, float64.)

Those have a different set of characteristics, and are known to be
generally approximations. So overflow might yield Infinity, that can be
tested for.

One of my programs was used for payroll too, where I used floats as
well, although now I'd use my decimal float type. (Which doesn't have
any limits to range or precision that would apply to a real-world
calculation.)

When it comes to integers, both languages offer int64 as minimum (many
languages are still stuck on int32). The next step after that is int128
on one, or the aforementioned big-decimal on the other. So plenty of
capacity for real-world calculations without running into overflow, eg.
counting the number of views of a youtube video...

On 14/10/2021 21:31, Andy Walker wrote:
> On 13/10/2021 12:01, Bart wrote:

>> I understand that if /you/ were implement a language, it would do
>> things perfectly.
>
>     Thanks for your confidence.
>
>>             It would display 2**3**4**5 exactly (even if it
>> takes a while, or exhausts your machine's memory).
>
>     Doesn't need me to implement anything:
>
>   $ a68g -p 2**3**4**5
>   a68g: runtime error: 1: INT math error [...]
>   $ a68g -p "LONG 2**3**4**5"
>                   +1152921504606846976

With the correct grouping, I get an overflow error:

a68 -p "LONG 2**(3**(4**5))"

.... (result too large) ....

If I try to work that out on Python, eventually it says:

MemoryError

This calculation is equivalent to:

2**37339184874102004353295975418486658822540977678373400775063693172207904
06172652512299936889388039772204687650654314751581087270545921608585813513
36982809187314191748594262580938807019951956404285571818041046681288797402
92551766801234061729839657473161915238672304623512593489605859058828465479
35405059362023765478074427305821445270589887562514528177934133521419207446
23027518729185432862375737063985485319476416926263819972887006907013899256
524297198527698749274196276811060702333710356481

I believe this needs 3.7e488 bits to represent; my machine contains only
7e10 bits of memory.

But assuming a calculation which is large, but fits into memory. If
these are compile-time expressions in a language with the requisite
types, how much time should a compiler spend evaluating them; how big
should a binary be allowed to get to represent these reduced/expanded
calculations?

This is why I don't do bignum reduction in a compiler. At runtime, it
will only spend time on the values it will actually encounter. Also why
I don't evaluate things like "A"*1 billion at compile-time; each
expression would take 6 seconds to work out; 1GB of memory; and would
add 1GB to the binary. And there might be hundreds.

Yet at runtime, it might not even be used.

On 14/10/2021 21:31, Andy Walker wrote:

....

> C programs can use the stuff defined [eg]
> in N1570 section 7.14 and/or Annex H [on "language independent
> arithmetic", which might interest James].

Yes, interesting stuff which I didn't know about. The wording is largely
for 'language lawyers', though. I'd rather specify such operations in a
more user-friendly way that would work for everyone including
non-mathematician newbie programmers.

--
James Harris

On 09/09/2021 13:43, Bart wrote:
> On 09/09/2021 11:57, James Harris wrote:

....

>> 1. create a .c file with the required #includes
>> 2. run it through the target's preprocessor
>> 3. parse the output to extract the data I needed
>> 4. store the extracted data in a configuration file for the target
>> 5. use the configuration file to set up my own types and structures
>> for the target environment.
>>
>> Further, since I may not even have access to a given target
>> environment, if the above process was unable to parse anything it
>> needed to I'd have the parser produce a report of what it could not
>> handle for sending back to me so I could update the parser or take
>> remedial steps.
>>
>> As the end of the day, I thought you were lamenting that there's no
>> master config file and all info is in C headers. The above steps are
>> intended to remedy that and create the master config file I thought
>> you wanted.
>
> In general, the process is non-trivial, even if you have a C compiler
> that can successfully process the headers (which itself can be
> problematical as it can have extra dependencies).
>
> For example, at some point, something is defined in terms of C
> executable code, and not declarations. Now you are having to translate
> chunks of program code.

The goal, AISI, is not to translate everything but to /extract/ info you
need for your 'master config file' such as the stat table layout.

>
> It is also an unreasonable degree of effort. I think most people would
> rather buy fish in a supermarket than having to lease a North Sea
> trawler to find it themselves!

That hardly applies. The reality is that you have systems for which
there is no master config file. None. Nada. It does not exist.

Yet if someone has created a C implementation for that environment then
there is hope that with a bit of work you could use C to extract the
info you need. Blaming C is like blaming the messenger.

--
James Harris

On 22/08/2021 14:50, David Brown wrote:
> On 21/08/2021 21:31, James Harris wrote:

....

>> Isn't it odd to have the maximum size of a file decided by a language's
>> implementation (or an OS's implementation)?
>
> It is the OS's choice, not the language.

What I am saying is that it should be neither. The max file size is
nothing to do with either language or OS but a property of a filesystem.

What you are thinking of is an OS /imposing/ a limit. That's fine;
that's what OSes tend to do. And their ABIs expose that OS-decided limit
to programs by including it in their API calls.

But OSes do not need to do that. In fact, it's a bad design to do so.

....

> If an OS does not support file systems that can handle files bigger than
> 4 GB, why should it make every file operation bigger and slower with a
> pointlessly large "off_t" size?

It shouldn't. Making off_t larger and larger just makes the problem
worse - like getting the largest and heaviest hammer possible and using
that one hammer to knock in every nail.

....

>> Put another way, the C/Posix or whatever concept of off_t seems to me to
>> be broken.
>>
>
> It only seems that way because you don't understand it.
>

That's rich coming from you.

--
James Harris

On 29/08/2021 22:24, David Brown wrote:
> On 29/08/2021 19:21, James Harris wrote:
>> On 29/08/2021 15:50, David Brown wrote:
>>> On 29/08/2021 13:47, James Harris wrote:

....

>>>> The limit of a file's size would naturally be defined by the filesystem
>>>> on which it was stored or on which it was being written. Such a value
>>>> would be known by, and a property of, the FS driver.
>>>>
>>>
>>> "Proof by repetitive assertion" is not convincing.
>>
>> There's nothing to prove. It is simply factual (and well known) that
>> different filesystems have different maximum file sizes. FAT12 has
>> different limits from FAT32, for example. Ergo, the maximum permitted
>> file size /is/ a natural property of the formatted filesystem. I guess
>> that's repetitive again but I cannot imagine what you think would need
>> to be added to that to establish the point.
>
> Of course different filesystems have different maximum file sizes - no
> one has disputed that! All that is in dispute is your silly idea that
> the /OS/ does not have limits here.

I never said that many current OSes do not have limits. It might help if
you understood a proposal before disagreeing with it!

Many or most OSes may impose limits but they don't have to: such a
design is not mandatory.

Many of those OSes need to be shut down and restarted in order to apply
updates. That may be what most people are familiar with but, again, OSes
do not have to work that way. I would pejoratively call them toy OSes
because they are not well designed. Toys can be commercially successful
but that does not make them machines.

To be clear about where I am coming from, AISI one should be able to
start an OS today and leave it running for years, including adding
future filesystems to it without shutting it down.

More important, here, an /application/ which uses file offsets should
not have to be recompiled - or even restarted - when new filesystems
(which have larger max file sizes) are released.

....

>>> What systems use file sizes that are smaller than "types smaller that
>>> 32-bit" ?
>>
>> I thought you were the microcontroller man!
>
> I am. What type would you use for file sizes here?

I'd point at them. For example,

file_seek(file, &offsetp, whence)

....

>> Something Dmitry said makes, I think, this easier to explain. In an OO
>> language you could think of the returns from your functions as objects.
>> The objects would be correctly sized for the filesystems to which they
>> related. They could have different classes but they would all respond
>> polymorphically to the same methods. The class of each would know the
>> maximum permitted offset.
>>
>
> Right. Arbitrary precision integers. They are written in a nice OO
> language so that the language hides the ugly mechanics of allocations,
> deallocations, memory management, etc., and gives you operator overloads
> instead of ugly prefix function calls or macros for everything.
>
> But they are still arbitrary precision integers if you refuse to allow
> limits. And they are still massively less efficient than a simple large
> integer of fixed size.

To be clear, AISI offsets would not be bignums where the size of each
varies dynamically. Instead, each would have a fixed width and that
width would not change.

....

>>>> Again, I have to disagree. The question is: What defines how large a
>>>> file's offset can be?
>>>>
>>>> The answer is just as simple: Each filesystem has its own range of max
>>>> sizes.
>>>>
>>>
>>> Your concept of "basic engineering" is severely lacking here.
>>
>> Oh? What, specifically, is lacking?
>>
>
> Supposing someone asked you to build a bridge for a two-lane road
> passing over a river. Basic engineering is to look at the traffic on
> the road, the size of the crossing, and figure out a reasonable maximum
> load weight that could realistically be on the bridge at any given time.
> Then you extrapolate for future growth based on the best available data
> and predictions. Then you multiply and add in safety factors. You tell
> the town planners that the bridge should have a total weight limit of,
> say, 100 tons and you tell them the price.
>
> That is basic engineering.

:-)

Your analogy is inapt. A closer fit to what we have been talking about
is you building a 4-lane highway to every island regardless of how large
or small the island is. Your bridges would be too small for some islands
and too big for others.

I am suggesting each bridge should suit the use case.

--
James Harris

On 23/10/2021 11:18, James Harris wrote:
[I wrote, a propos traps:]
>> C programs can use the stuff defined [eg]
>> in N1570 section 7.14 and/or Annex H [on "language independent
>> arithmetic", which might interest James].
> Yes, interesting stuff which I didn't know about. The wording is
> largely for 'language lawyers', though. I'd rather specify such
> operations in a more user-friendly way that would work for everyone
> including non-mathematician newbie programmers.

You seem to be confusing a language specification with a
language primer or even advanced text. The specification must be
sufficiently precise that no two civilised readers can disagree
about what it means; ordinary programmers who find that hard to
understand can look instead at books that explain what is going
on. You don't learn C from N1570; but you might write compilers
from it.

That's the mistake people made with Algol 68; they took
one look at the Report, and instead of looking at the examples
in Chapter 11 [which were largely the same as the examples in
the Algol 60 Reports, but looked nicer and more straightforward]
they dived straight in to hypernotions and paranotions and such-
like. Those are completely impenetrable to almost everyone, and
it was assumed that the impenetrability was part of the language.

Sadly, since then, few people have even tried to define
languages formally. The result is all too predictable. C is
defined better than most, and has gone through several revisions;
but still there are debates in "c.s.c" about what various things
mean, the most recent being what N2596 means for initialising
anonymous structures and unions. Most languages are defined
largely by "this is what loops [or whatever] look like, and
use your common sense to work out what it all means".

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Boccherini

On 23/10/2021 14:20, Andy Walker wrote:
> On 23/10/2021 11:18, James Harris wrote:
> [I wrote, a propos traps:]

>>> C programs can use the stuff defined [eg]
>>> in N1570 section 7.14 and/or Annex H [on "language independent
>>> arithmetic", which might interest James].

>> Yes, interesting stuff which I didn't know about. The wording is
>> largely for 'language lawyers', though. I'd rather specify such
>> operations in a more user-friendly way that would work for everyone
>> including non-mathematician newbie programmers.
>
>     You seem to be confusing a language specification with a
> language primer or even advanced text.  The specification must be
> sufficiently precise that no two civilised readers can disagree
> about what it means;  ordinary programmers who find that hard to
> understand can look instead at books that explain what is going
> on.  You don't learn C from N1570;  but you might write compilers
> from it.

Don't get me wrong. I'm a fan of what is probably now an old-fashioned
idea of there being an instruction manual and a reference manual. It's
just that IMO the reference manual should be for programmers rather than
for compiler writers.

Whether a reference manual could be good enough for compiler writers as
well as programmers is, for me, an open question.

....

>     Sadly, since then, few people have even tried to define
> languages formally.

That's surprising. I would have thought that all languages needed a
formal definition.

--
James Harris

On 23/10/2021 16:06, James Harris wrote:
[I wrote:]
>>      You seem to be confusing a language specification with a
>> language primer or even advanced text.  The specification must be
>> sufficiently precise that no two civilised readers can disagree
>> about what it means;  ordinary programmers who find that hard to
>> understand can look instead at books that explain what is going
>> on.  You don't learn C from N1570;  but you might write compilers
>> from it.
> Don't get me wrong. I'm a fan of what is probably now an
> old-fashioned idea of there being an instruction manual and a
> reference manual. It's just that IMO the reference manual should be
> for programmers rather than for compiler writers.

I didn't say "reference manual", but "specification". If a
language is not precisely defined, then different compilers will
either disagree despite conforming to the spec, or else [and just
as bad] there will be a consensus among compilers that is merely
"folklore" about what the language means and that cannot be found
out by programmers who want/need to know. It's that definition
that compiler writers need to have access to.

> Whether a reference manual could be good enough for compiler writers
> as well as programmers is, for me, an open question.

If the reference manual is /not/ good enough, then a better
one is needed, otherwise what are compiler writers supposed to use?
I don't see why that's "open", other than for toy/private languages.
IOW, you can do what you like with your own language, but languages
like C, Fortran, Algol, ... that aspire to a degree of universality
need a reliable definition. [To some extent, "C is what runs on
DMR's computer" is such a definition, but it leaves ambiguous
whether some features are as they are because DMR made arbitrary
choices for his own compiler or because they are the essence of C.]

>>      Sadly, since then, few people have even tried to define
>> languages formally.
> That's surprising. I would have thought that all languages needed a
> formal definition.

Well, as above, toy/private languages don't; but yes, it
should be a "sine qua non" of serious languages that there be a
formal definition. Up to 1968, that was the way we were headed;
but reaction to Algol 68 was sufficiently negative in this area
[unfairly] that no major language since has [AFAIK] gone down a
similar route. The C and C++ standards are about as close as we
have come. VDL was touted for this purpose at one stage, but it
never really caught on, and in any case it's nowhere near as
precise as a two-level grammar*. Perhaps worth noting that a
formal definition need not imply that everything is tied down
with all the t's and i's crossed and dotted; rather, that the
definition is clear about what is left to the implementation
[eg, the order of evaluation of operands].

____
* Other formal techniques are available.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Boccherini

On 23/10/2021 22:18, Andy Walker wrote:
> On 23/10/2021 16:06, James Harris wrote:
> [I wrote:]
>>>      You seem to be confusing a language specification with a
>>> language primer or even advanced text.  The specification must be
>>> sufficiently precise that no two civilised readers can disagree
>>> about what it means;  ordinary programmers who find that hard to
>>> understand can look instead at books that explain what is going
>>> on.  You don't learn C from N1570;  but you might write compilers
>>> from it.
>> Don't get me wrong. I'm a fan of what is probably now an
>> old-fashioned idea of there being an instruction manual and a
>> reference manual. It's just that IMO the reference manual should be
>> for programmers rather than for compiler writers.
>
>     I didn't say "reference manual", but "specification".

I know. I brought up the topic of a reference manual.

> If a
> language is not precisely defined, then different compilers will
> either disagree despite conforming to the spec, or else [and just
> as bad] there will be a consensus among compilers that is merely
> "folklore" about what the language means and that cannot be found
> out by programmers who want/need to know.  It's that definition
> that compiler writers need to have access to.
>
>> Whether a reference manual could be good enough for compiler writers
>> as well as programmers is, for me, an open question.
>
>     If the reference manual is /not/ good enough, then a better
> one is needed, otherwise what are compiler writers supposed to use?

Are you arguing for there being a reference manual and a specification,
or just one text which is good enough for both purposes (programmer's
reference and compiler-writer's specification)? By 'one text' I don't
mean one book with both sections but a single exposition which serves
both purposes.

One thing I am convinced of is that it helps a human if a text follows
the pattern: principle, examples and maybe rationale.

> I don't see why that's "open", other than for toy/private languages.
> IOW, you can do what you like with your own language, but languages
> like C, Fortran, Algol, ... that aspire to a degree of universality
> need a reliable definition.  [To some extent, "C is what runs on
> DMR's computer" is such a definition, but it leaves ambiguous
> whether some features are as they are because DMR made arbitrary
> choices for his own compiler or because they are the essence of C.]

Have to say the language specifications I've seen are not easy to read.
I do wonder if the same information could be written in an easier form.
AISI a compiler writer wants to know what's required at each point in
his code but I am not sure that specifications are written that way.
I've never tried to write a compiler from a spec but I get the
impression that to write any piece of compiler code one would have to
take into account points from across the specification rather than those
in the one relevant place. That's not much help to a compiler writer.

--
James Harris

On 25/10/2021 14:22, James Harris wrote:
>>> [...] It's just that IMO the reference manual should be
>>> for programmers rather than for compiler writers.
>>      I didn't say "reference manual", but "specification".
> I know. I brought up the topic of a reference manual.

Yes, but the point is that [for a professional/portable
language] there absolutely needs to be a specification. If that
can also serve as a reference manual [it often can], so much the
better. But, eg, a reference manual might describe only some
particular implementation, which might be enough for users of
that implementation but not for compiler writers for different
implementations.

[...]
>>> Whether a reference manual could be good enough for compiler writers
>>> as well as programmers is, for me, an open question.
>>      If the reference manual is /not/ good enough, then a better
>> one is needed, otherwise what are compiler writers supposed to use?
> Are you arguing for there being a reference manual and a
> specification, or just one text which is good enough for both
> purposes (programmer's reference and compiler-writer's
> specification)? By 'one text' I don't mean one book with both
> sections but a single exposition which serves both purposes.

Well, there is in general no compelling reason why a
specification should not also be a reference manual. Perhaps
worth noting, though, that if I want to know what some code
does, and don't understand what the reference manual says, I
can run the code and find out; the compiler writer has no
such recourse.

> One thing I am convinced of is that it helps a human if a text
> follows the pattern: principle, examples and maybe rationale.

Sure. You're simply saying that some textbooks are
not very good; about which there is no dispute.

> Have to say the language specifications I've seen are not easy to
> read. I do wonder if the same information could be written in an
> easier form.

Very possibly. But a compiler writer has to put some
effort in. If you want to write [eg] C, you only need to know
how to write the bits you actually want to use; if you want to
write a C compiler, you need to understand the whole language.
[As per my PP, if you want to write your own language, all bets
are off; I'm talking about manuals and compilers for languages
intended for widespread use.]

> AISI a compiler writer wants to know what's required at
> each point in his code but I am not sure that specifications are
> written that way. I've never tried to write a compiler from a spec
> but I get the impression that to write any piece of compiler code one
> would have to take into account points from across the specification
> rather than those in the one relevant place. That's not much help to
> a compiler writer.

If you want to write a C compiler, then you ultimately
need to understand the whole of the C standard. The C standard
is not particularly hard to read. OTOH, it is also not as good
as a definition of C as it really ought to be -- witness the
discussions in "c.s.c". For C, substitute any major language
of your choice.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Soler