On 08/03/22 07:58, David Brown wrote:
> I know there/are/ languages without operator precedence, where "a + b *
> c" is "(a + b) * c". And I expect that people who use them get used to
> it. But I think it would take a fair amount of effort for most people
> to change their thinking when starting with such a language, and
> mistakes and misunderstandings would be common.

Calculators are too often like that. Too many people
are adamant that 1+2*3 is 9.

EricP <ThatWouldBeTelling@thevillage.com> wrote:
> Yes, that makes sense.
> Even for a mid-80's TTL DRAM controller I would be
> surprised if it didn't have same-row detection.
> Its a few latches and xors.
>
> So you are saying that because LDM/STM do a single instruction fetch,
> then a sequence of data addresses, it allows same-row detection
> and just a column address strobe CAS will do.
> For a sequence of individual LD or ST, the instruction addresses
> would most likely be to a different row than their data addresses
> so same-row detect doesn't kick in, and requires full RAS and CAS.

Yes. So a traditional LD/ST (even if to contiguous addresses) gives you:

row(instr. fetch); col(IF); row(data0); col(data0);
row(instr. fetch); col(IF); row(data1); col(data1);
....
row(instr. fetch); col(IF); row(data15); col(data15);

whereas STM/LDM has:

row(IF); col(IF); row(data0); col(data0);
col(data1);
....
col(data15);

I'm not very familiar with 1980s DRAMs but I don't think they had multiple
banks so you could have several rows open at once.

Theo

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> George Neuner <gneuner2@comcast.net> writes:
>
>> On Mon, 7 Mar 2022 07:02:23 -0800, Ivan Godard
>> <ivan@millcomputing.com> wrote:
>>
>>> Which is why having no precedence at all, just lexical order on the
>>> page, gets rid of all the problems.
>>
>> Lisp tried that
>
> And Forth and Postscript (without all these parentheses). And, for
> infix, APL, Smalltalk and, as I learned here), Mary.

Smalltalk has three levels of precedence. Only the middle level,
binary operators, is evaluated left-to-right (in the absence of
parentheses). Also Smalltalk has blocks, which tend to partition
expressions by virtue of blocks syntactically requiring square
brackets surrounding the expressions inside the block.

On 08/03/2022 10:49, Niklas Holsti wrote:
> On 2022-03-08 9:47, David Brown wrote:
>> On 07/03/2022 20:09, Niklas Holsti wrote:
>>>
>>> In some viruses (I believe) the genetic code can be read in both
>>> directions along the DNA or RNA strand, and each direction produces
>>> different useful proteins.
>>
>> I know this is getting /really/ off-topic, but do you have any
>> references for that?  I know that transcription from DNA to RNA can run
>> in both directions at once, but AFAIUI in eukaryotes there are
>> mechanisms in place to identify the wrong half and reject it.
>>
>>  From the way proteins are coded and the complexity of most of them, I
>> find it hard to imagine that you could get two useful proteins from the
>> same RNA in different directions - it's like trying to run a
>> byte-reversed program.  It is (to me) a lot more believable that there
>> are bits of virus DNA or RNA that are simply backwards.
>
>
> My recollection may be at fault, and I may have confused "direction"
> with "sense" (that is, strand complementarity). Or I may have
> mis-remembered the use of different coding-frame phases that Ivan
> described (which is already an amazing feat of biology).
>
> The section titled "Ambisense" in
> https://en.wikipedia.org/wiki/Sense_(molecular_biology) seems to come
> close, but perhaps it only means that the same RNA strand contains
> sections that are read in one direction, and sections that are read in
> the other direction, but no section is read in both directions. That
> resembles the alternation of reading direction line by line that Ivan
> also described. So, sorry, that is the closest I can come to a
> reference. I would not have made my comment in a serious discussion
> without checking it better.

Fair enough. (IMHO it's fine to make comments based on knowledge that
is only half-remembered, along with phrases like "I believe" - maybe
you'll get lucky and someone else will provide more information for or
against the idea.)

It seems logical and reasonable (based on my limited understanding - I
am an interested layman, not a real biologist) to find viruses that have
their RNA or DNA running in either direction (or "sense"), and it also
seems reasonable to find some where different genes are in different
directions. A direction swap could occur as variation during
reproduction. But a gene that worked in either direction would be, I
think, very unlikely.

On 08/03/2022 10:51, Tom Gardner wrote:
> On 08/03/22 07:58, David Brown wrote:
>> I know there/are/  languages without operator precedence, where "a + b *
>> c" is "(a + b) * c".  And I expect that people who use them get used to
>> it.  But I think it would take a fair amount of effort for most people
>> to change their thinking when starting with such a language, and
>> mistakes and misunderstandings would be common.
>
> Calculators are too often like that. Too many people
> are adamant that 1+2*3 is 9.

Yes, but people who think that are unlikely to become programmers!

On 3/8/2022 12:00 AM, Terje Mathisen wrote:
> Ivan Godard wrote:
>> On 3/7/2022 11:09 AM, Niklas Holsti wrote:
>>> On 2022-03-07 19:54, Ivan Godard wrote:
>>>> On 3/7/2022 9:36 AM, MitchAlsup wrote:
>>>>> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, EricP wrote:
>>>>>> Ivan Godard wrote:
>>>>>>> On 3/7/2022 12:34 AM, David Brown wrote:
>>>>>>>>
>>>>>>>> Extra parenthesis makes things abundantly clear at a glance -
>>>>>>>> the reader
>>>>>>>> can be in no doubt. They are useful for operators that are
>>>>>>>> relatively
>>>>>>>> rarely used or rarely used in particular combinations, but they
>>>>>>>> are also
>>>>>>>> useful to give the reader an idea of how you are building up the
>>>>>>>> expression logically. Maybe "(a + b) + (c + d)" gives the reader
>>>>>>>> more
>>>>>>>> information than just "a + b + c + d". Making code clear to read
>>>>>>>> - so
>>>>>>>> that the compiler and the reader are in sync - is vital.
>>>>>>>
>>>>>>> Which is why having no precedence at all, just lexical order on the
>>>>>>> page, gets rid of all the problems.
>>>>>> Ah but then we will have the left-endians and the right-endians,
>>>>>> and heretics will still abound!
>>>>> <
>>>>> Is there any room for a middle-endian ? That is start from the middle
>>>>> and progress outwards in both directions simultaneously.
>>>>
>>>> No languages that I know of are middle-endian in that sense. However
>>>> several switch directions at each line: l2r->r2l->l2r->etc, an
>>>> endless snake.
>>>
>>>
>>> In some viruses (I believe) the genetic code can be read in both
>>> directions along the DNA or RNA strand, and each direction produces
>>> different useful proteins. So a language without precedence could be
>>> both left-to-right and right-to-left, computing two different useful
>>> answers at the same time.
>>>
>>
>>
>> Clever! Some also get more than one protein from a xna strand by
>> starting the frame on a different one of the three coding phases.
>>
>> I did that last trick in a memory-dumping utility for the B6500 that
>> had to entirely fit on an 80-column card, but I've never written code
>> that read backwards. As it happens, one could do that on a Mill,
>> because the two decoders read away from each other. Sounds like a
>> challenge for Terje!
>
>
> This is of course quite easy on a RISC style fixed-length instruction
> set, you just need to write code that makes sense in both directions.
>
> It is a bit more complicated with varible-length instructions like x86,
> where you will very quickly run into issues like prefix bytes (like REP
> CMPS etc), in order to use those for a block move I would need something
> like MOVS REP MOVS, while all/most function calls require hiding the
> opposite endian code inside immediates.
>
> I.e. almost certainly doable, but very hard to make it space-saving.
>
> Terje
>

But the RISC code, while it may make sense in both directions, there is
no CPU that will execute it in both directions. The B6500, with one,
two, and three-byte instruct-ions, had a choice of three reading frames,
all forward; when my dumper got to the end of the card it branched back
into the middle of one of the early instructions and executed the bits
again but in a different frame.

On a Mill not, the ebb entry is the head of two instructions sequences,
exu going toward higher addresses and flow toward lower addresses; the
interpretation of a given bit pattern depends on which sequence it is in
- perhaps a multiply in one and a load in the other. If you branch into
the point *between* two ebbs then your exu sequence will be the same
bits as the flow sequence of the ebb at next higher addresses, and your
flow sequence will be the same bits as the exu sequence of the ebb at
next lower addresses, whatever those bits mean in that context.

In the Mill this is more complicated because the instructions in a
sequence are bit-aligned and vary in width. However, one can imagine a
RISC fixed-length ISA that used a Mill-like dual-decode for its icache
advantages, so that the instructions would all align nicely although
varying in meaning depending on whether read forward or backward.

Truly a Terje-scale conundrum!

On 3/8/2022 5:29 AM, David Brown wrote:
> On 08/03/2022 10:49, Niklas Holsti wrote:
>> On 2022-03-08 9:47, David Brown wrote:
>>> On 07/03/2022 20:09, Niklas Holsti wrote:
>>>>
>>>> In some viruses (I believe) the genetic code can be read in both
>>>> directions along the DNA or RNA strand, and each direction produces
>>>> different useful proteins.
>>>
>>> I know this is getting /really/ off-topic, but do you have any
>>> references for that?  I know that transcription from DNA to RNA can run
>>> in both directions at once, but AFAIUI in eukaryotes there are
>>> mechanisms in place to identify the wrong half and reject it.
>>>
>>>  From the way proteins are coded and the complexity of most of them, I
>>> find it hard to imagine that you could get two useful proteins from the
>>> same RNA in different directions - it's like trying to run a
>>> byte-reversed program.  It is (to me) a lot more believable that there
>>> are bits of virus DNA or RNA that are simply backwards.
>>
>>
>> My recollection may be at fault, and I may have confused "direction"
>> with "sense" (that is, strand complementarity). Or I may have
>> mis-remembered the use of different coding-frame phases that Ivan
>> described (which is already an amazing feat of biology).
>>
>> The section titled "Ambisense" in
>> https://en.wikipedia.org/wiki/Sense_(molecular_biology) seems to come
>> close, but perhaps it only means that the same RNA strand contains
>> sections that are read in one direction, and sections that are read in
>> the other direction, but no section is read in both directions. That
>> resembles the alternation of reading direction line by line that Ivan
>> also described. So, sorry, that is the closest I can come to a
>> reference. I would not have made my comment in a serious discussion
>> without checking it better.
>
> Fair enough. (IMHO it's fine to make comments based on knowledge that
> is only half-remembered, along with phrases like "I believe" - maybe
> you'll get lucky and someone else will provide more information for or
> against the idea.)
>
> It seems logical and reasonable (based on my limited understanding - I
> am an interested layman, not a real biologist) to find viruses that have
> their RNA or DNA running in either direction (or "sense"), and it also
> seems reasonable to find some where different genes are in different
> directions. A direction swap could occur as variation during
> reproduction. But a gene that worked in either direction would be, I
> think, very unlikely.
>

Unlikely becomes trivial given enough time to work on it, and they have
had quite a while :-)

Niklas Holsti wrote:
> On 2022-03-08 9:47, David Brown wrote:
>> On 07/03/2022 20:09, Niklas Holsti wrote:
>>>
>>> In some viruses (I believe) the genetic code can be read in both
>>> directions along the DNA or RNA strand, and each direction produces
>>> different useful proteins.
>>
>> I know this is getting /really/ off-topic, but do you have any
>> references for that? I know that transcription from DNA to RNA can run
>> in both directions at once, but AFAIUI in eukaryotes there are
>> mechanisms in place to identify the wrong half and reject it.
>>
>> From the way proteins are coded and the complexity of most of them, I
>> find it hard to imagine that you could get two useful proteins from the
>> same RNA in different directions - it's like trying to run a
>> byte-reversed program. It is (to me) a lot more believable that there
>> are bits of virus DNA or RNA that are simply backwards.
>
>
> My recollection may be at fault, and I may have confused "direction"
> with "sense" (that is, strand complementarity). Or I may have
> mis-remembered the use of different coding-frame phases that Ivan
> described (which is already an amazing feat of biology).
>
> The section titled "Ambisense" in
> https://en.wikipedia.org/wiki/Sense_(molecular_biology) seems to come
> close, but perhaps it only means that the same RNA strand contains
> sections that are read in one direction, and sections that are read in
> the other direction, but no section is read in both directions. That
> resembles the alternation of reading direction line by line that Ivan
> also described. So, sorry, that is the closest I can come to a
> reference. I would not have made my comment in a serious discussion
> without checking it better.

https://en.wikipedia.org/wiki/Reading_frame

"Any given sequence of DNA can therefore be read in six different ways:
Three reading frames in one direction (starting at different nucleotides)
and three in the opposite direction."

"A single strand of a nucleic acid molecule has a phosphoryl end, called
the 5′-end, and a hydroxyl or 3′-end. These define the 5′→3′ direction.
There are three reading frames that can be read in this 5′→3′ direction,
each beginning from a different nucleotide in a triplet.

In a double stranded nucleic acid, an additional three reading frames
may be read from the other, complementary strand in the 5′→3′ direction
along this strand. As the two strands of a double-stranded nucleic acid
molecule are antiparallel, the 5′→3′ direction on the second strand
corresponds to the 3′→5′ direction along the first strand."

On 3/7/2022 11:58 PM, David Brown wrote:
> On 07/03/2022 22:48, MitchAlsup wrote:
>> On Monday, March 7, 2022 at 2:24:27 PM UTC-6, David Brown wrote:
>>> On 07/03/2022 16:02, Ivan Godard wrote:
>>>> On 3/7/2022 12:34 AM, David Brown wrote:
>>>>>
>>>>> Extra parenthesis makes things abundantly clear at a glance - the reader
>>>>> can be in no doubt. They are useful for operators that are relatively
>>>>> rarely used or rarely used in particular combinations, but they are also
>>>>> useful to give the reader an idea of how you are building up the
>>>>> expression logically. Maybe "(a + b) + (c + d)" gives the reader more
>>>>> information than just "a + b + c + d". Making code clear to read - so
>>>>> that the compiler and the reader are in sync - is vital.
>>>>
>>>> Which is why having no precedence at all, just lexical order on the
>>>> page, gets rid of all the problems.
>>> That would get rid of such problems (though obviously it is not
>>> applicable to C or C-like languages). However, it would introduce new
>>> problems - people expect "a + b * c" to have the same precedence as in
>>> normal mathematics.
>> <
>> Only when you have never written in a precedence-free language.
>> <
>> a + b * c
>> <
>> Reads just like ASM:
>> <
>> ADD Rt,Ra,Rb
>> MUL Rt,Rt,Rc
>
>
> I've written plenty of assembly. But assembly is not a precedence-free
> language - it is a language using prefix functional notation. That is a
> very different thing.
>
> I know there /are/ languages without operator precedence, where "a + b *
> c" is "(a + b) * c". And I expect that people who use them get used to
> it. But I think it would take a fair amount of effort for most people
> to change their thinking when starting with such a language, and
> mistakes and misunderstandings would be common.

Data point: I have not written APL, but have read quite a bit of
commentary, and while there were complaints about the symbolic notation
and the need for quite a bit of math background to grasp the effect of
some of the operators, I do not recall any complaints about absence of
precedence.

Data point: there was an operating system and quite a bit of embedded
code written in Mary1, with no complaints about precedence. That may
have been because people were thinking of their problem in machine terms
before coding, instead of mathematical expression terms, so they
naturally wrote the instructions they wanted in the order they wanted
them to execute, which was textual order in Mary. Multiply is not a
common operation in OS code once address multiplies are pulled into
subscript notation, which Mary did.

Theo wrote:
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>> Yes, that makes sense.
>> Even for a mid-80's TTL DRAM controller I would be
>> surprised if it didn't have same-row detection.
>> Its a few latches and xors.
>>
>> So you are saying that because LDM/STM do a single instruction fetch,
>> then a sequence of data addresses, it allows same-row detection
>> and just a column address strobe CAS will do.
>> For a sequence of individual LD or ST, the instruction addresses
>> would most likely be to a different row than their data addresses
>> so same-row detect doesn't kick in, and requires full RAS and CAS.
>
> Yes. So a traditional LD/ST (even if to contiguous addresses) gives you:
>
> row(instr. fetch); col(IF); row(data0); col(data0);
> row(instr. fetch); col(IF); row(data1); col(data1);
> ....
> row(instr. fetch); col(IF); row(data15); col(data15);
>
> whereas STM/LDM has:
>
> row(IF); col(IF); row(data0); col(data0);
> col(data1);
> ....
> col(data15);
>
> I'm not very familiar with 1980s DRAMs but I don't think they had multiple
> banks so you could have several rows open at once.
>
> Theo

Its that a TTL DRAM controller took up a whole board itself.
So while the DRAMs could each have a different row open,
most couldn't afford the logic to make use of it.
Also almost all DRAMs then were *1, that is 1 data bit in-out as
that maximizes the storage while minimizing the package pin count.
So a 32-bit wide memory required multiples of 32 chips,
which also was a fair amount board space.

> Calculators are too often like that.
> Too many people are adamant that 1+2*3 is 9.

These calculators are the reason why HP's RPN was so popular:
It's like comparing an accumulator based ISA to
stack-based ISA.

Stefan

> This is of course quite easy on a RISC style fixed-length instruction set,
> you just need to write code that makes sense in both directions.

I think it depends how you do the direction reversal: are just 32bit
words reversed (so it's really the same instructions just executed in
the other order), or are bytes reversed? how 'bout bit-by-bit?

Stefan

Ivan Godard wrote:
> On 3/7/2022 11:10 AM, EricP wrote:
>> Ivan Godard wrote:
>>> On 3/7/2022 7:10 AM, EricP wrote:
>>> > - user mode exception/signal handler entry,exit
>>>
>>> Why are exceptions different from calls you didn't ask for?
>>
>> If I was doing it, the OS deposits (pushes) a packet of exception info
>> and the return PC onto the apps' user mode stack, and OS returns to
>> the exception routine. User mode exception handler saves the full integer
>> context on the stack, and calls the exception dispatcher routine
>> passing pointers to the exception info and saved context structs as args.
>> Exception handlers can edit saved context as they wish.
>> When handlers return, exception dispatcher reloads the now possibly
>> edited
>> interrupted context, restores stack, and returns to the possibly
>> edited PC.
>
> How do you do it if there are no modes?

The main problem is how does exception information get delivered
to the offending execution, since exceptions are non-maskable so
a single set of registers could be overwritten by multiple exceptions.

Pushing an exception descriptor on the stack is the usual way to handle
this but that has its own issues, like page faults pushing the packet,
stack overflow, variable exception packet size complicates interrupt return.
Also it assumes the ISA has a designated stack register, and may require
coordination of stack allocation with the OS like Linux "red zones".

If its not hardware pushing the packet then the OS emulates this where
an exception halts the app thread, spilling its context to memory.
Then kernel thread edits the app stack and context to push the
exception packet on the app stack and the PC to a exception handler,
and then restarts the app thread. This is basically what WinNT does.

The main complaint that people seem to have is that exceptions are
too expensive, or that the trip through the operating system to
deliver them is too expensive.
Aside from page fault of valid addresses, which is handled by the OS anyway,
the only exception that is performance critical is the recent introduction
of hardware transaction memory HTM aborts delivered directly to the app.

On 08/03/2022 15:44, Ivan Godard wrote:
> On 3/8/2022 5:29 AM, David Brown wrote:

>> It seems logical and reasonable (based on my limited understanding - I
>> am an interested layman, not a real biologist) to find viruses that have
>> their RNA or DNA running in either direction (or "sense"), and it also
>> seems reasonable to find some where different genes are in different
>> directions.  A direction swap could occur as variation during
>> reproduction.  But a gene that worked in either direction would be, I
>> think, very unlikely.
>>
>
> Unlikely becomes trivial given enough time to work on it, and they have
> had quite a while :-)

Evolution doesn't work that way in general. /Some/ unlikely things turn
up - the most realistic plausible scenarios for abiogenesis all depend
on some "win the lottery" coincidences. But mostly evolution works from
large numbers of small steps - and small steps are not going to get you
from a recipe for a useful protein into a recipe for a useful protein
that can be read backwards to produce a different useful protein.

Anyway, you need to read "very unlikely" with a Scottish accent. Then
you'll appreciate that it means "very, very, very unlikely - of the
level that it will probably never happen anywhere in the multiverse even
if the string theorists are right". (That estimate is based on my
current understanding - if someone has references showing I'm wrong
here, I'd be happy to read them.)

On 08/03/2022 15:54, Ivan Godard wrote:
> On 3/7/2022 11:58 PM, David Brown wrote:
>> On 07/03/2022 22:48, MitchAlsup wrote:
>>> On Monday, March 7, 2022 at 2:24:27 PM UTC-6, David Brown wrote:
>>>> On 07/03/2022 16:02, Ivan Godard wrote:
>>>>> On 3/7/2022 12:34 AM, David Brown wrote:
>>>>>>
>>>>>> Extra parenthesis makes things abundantly clear at a glance - the
>>>>>> reader
>>>>>> can be in no doubt.  They are useful for operators that are
>>>>>> relatively
>>>>>> rarely used or rarely used in particular combinations, but they
>>>>>> are also
>>>>>> useful to give the reader an idea of how you are building up the
>>>>>> expression logically.  Maybe "(a + b) + (c + d)" gives the reader
>>>>>> more
>>>>>> information than just "a + b + c + d".  Making code clear to read
>>>>>> - so
>>>>>> that the compiler and the reader are in sync - is vital.
>>>>>
>>>>> Which is why having no precedence at all, just lexical order on the
>>>>> page, gets rid of all the problems.
>>>> That would get rid of such problems (though obviously it is not
>>>> applicable to C or C-like languages). However, it would introduce new
>>>> problems - people expect "a + b * c" to have the same precedence as in
>>>> normal mathematics.
>>> <
>>> Only when you have never written in a precedence-free language.
>>> <
>>> a + b * c
>>> <
>>> Reads just like ASM:
>>> <
>>>         ADD    Rt,Ra,Rb
>>>         MUL    Rt,Rt,Rc
>>
>>
>> I've written plenty of assembly.  But assembly is not a precedence-free
>> language - it is a language using prefix functional notation.  That is a
>> very different thing.
>>
>> I know there /are/ languages without operator precedence, where "a + b *
>> c" is "(a + b) * c".  And I expect that people who use them get used to
>> it.  But I think it would take a fair amount of effort for most people
>> to change their thinking when starting with such a language, and
>> mistakes and misunderstandings would be common.
>
> Data point: I have not written APL, but have read quite a bit of
> commentary, and while there were complaints about the symbolic notation
> and the need for quite a bit of math background to grasp the effect of
> some of the operators, I do not recall any complaints about absence of
> precedence.

I think APL is so special that anyone writing code in it will not be
surprised by such minor differences from other languages - a lack of
operator precedence would be lost in the noise. And anyway, there are
so many operators in APL that assigning precedence levels would be
nearly impossible, and learning them would be worse. (Disclaimer - I
haven't written APL since trying it one weekend three decades ago.)

>
> Data point: there was an operating system and quite a bit of embedded
> code written in Mary1, with no complaints about precedence. That may
> have been because people were thinking of their problem in machine terms
> before coding, instead of mathematical expression terms, so they
> naturally wrote the instructions they wanted in the order they wanted
> them to execute, which was textual order in Mary. Multiply is not a
> common operation in OS code once address multiplies are pulled into
> subscript notation, which Mary did.
>
>

On 3/8/2022 7:59 AM, David Brown wrote:
> On 08/03/2022 15:44, Ivan Godard wrote:
>> On 3/8/2022 5:29 AM, David Brown wrote:
>
>>> It seems logical and reasonable (based on my limited understanding - I
>>> am an interested layman, not a real biologist) to find viruses that have
>>> their RNA or DNA running in either direction (or "sense"), and it also
>>> seems reasonable to find some where different genes are in different
>>> directions.  A direction swap could occur as variation during
>>> reproduction.  But a gene that worked in either direction would be, I
>>> think, very unlikely.
>>>
>>
>> Unlikely becomes trivial given enough time to work on it, and they have
>> had quite a while :-)
>
> Evolution doesn't work that way in general. /Some/ unlikely things turn
> up - the most realistic plausible scenarios for abiogenesis all depend
> on some "win the lottery" coincidences. But mostly evolution works from
> large numbers of small steps - and small steps are not going to get you
> from a recipe for a useful protein into a recipe for a useful protein
> that can be read backwards to produce a different useful protein.
>
> Anyway, you need to read "very unlikely" with a Scottish accent. Then
> you'll appreciate that it means "very, very, very unlikely - of the
> level that it will probably never happen anywhere in the multiverse even
> if the string theorists are right". (That estimate is based on my
> current understanding - if someone has references showing I'm wrong
> here, I'd be happy to read them.)

If an xna string can be read to a protein in either direction, and
apparently some viruses do, then it will be read in both directions
accidentally. If one direction gives something useful then evolution
will optimize that direction, and that optimization will randomly
pessimize the junk that arises from the other direction.

However, xna is not an entropy-optimizing encoding, or at least not
much; there is a great deal of wasted entropy: multiple triplets that
code for the same acid, quite different sequences that fold to the same
functional shape, and so on. These will get randomly reshuffled while
maintaining the function of the primary read direction, while giving a
palette for evolution in the other read direction.

The result should be, eventually, dual use xna strings. However, those
strings are likely to be shorter than single-use strings. That's because
a single-point mutation is likely to be optimal only in one reading,
with the other reading either silent or pessimal. as a result, the
optimal-optimal mutations that are of benefit to the organism will be
less common than the optimal-don't care mutations of single-read xna. As
a result, the dual-read strand has less evolutionary responsiveness to
changing conditions, and should be suppressed. The suppression will be
length-sensitive.

Hence I expect that dual-read will not be found in full-protien
encodings, which are lengthy. However they are likely in short-strand
encodings of peptides. More: https://en.wikipedia.org/wiki/Peptide

On 08/03/22 13:30, David Brown wrote:
> On 08/03/2022 10:51, Tom Gardner wrote:
>> On 08/03/22 07:58, David Brown wrote:
>>> I know there/are/  languages without operator precedence, where "a + b *
>>> c" is "(a + b) * c".  And I expect that people who use them get used to
>>> it.  But I think it would take a fair amount of effort for most people
>>> to change their thinking when starting with such a language, and
>>> mistakes and misunderstandings would be common.
>>
>> Calculators are too often like that. Too many people
>> are adamant that 1+2*3 is 9.
>
> Yes, but people who think that are unlikely to become programmers!

Based on my experience, don't bet on it :(

Far too many people with computing degrees don't recognise an FSM,
even when they are coding one. Typical comment@ "FSMs? Aren't they
something to do with compilers?"

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> George Neuner <gneuner2@comcast.net> writes:
>>On Mon, 7 Mar 2022 07:02:23 -0800, Ivan Godard
>><ivan@millcomputing.com> wrote:
>>
>>>Which is why having no precedence at all, just lexical order on the
>>>page, gets rid of all the problems.
>>
>>Lisp tried that
>
> And Forth and Postscript (without all these parentheses). And, for
> infix, APL, Smalltalk and, as I learned here), Mary.
>
>>... how many people today use SExpr languages?
>
> Or any of the others.

I write PostScript now and then. Once I had occasion to translate
a few fairly complex equations to PostScript. The fastest way I
could find was to write a quick yacc, or rather bision, grammar.

For simpler formulas (which came before) I put the current state
of the stack into comments. Debugging consisted mostly of putting
a "debug" command, which wasn't defined, into the program and
examining the log file.

Other than that, the only relevant PostScript I ever wrote was some
additions to the gnuplot symbol table. It has far more symbols
than all the other terminals. For example, you get 16 differently
filled circle symbols, plus squares and diamonds. (You can test
it out by writing

gnuplot> set terminal postscript
....
gnuplot> set output "test.ps"
gnuplot> test
gnuplot> set output

which will at least display the first 33 symbols, including 17
of the ones I contributed).

I wrote this to help a friend who was doing his PhD thesis at
the time. His advisor insisted on a certain look of the graph
symbols, which meant that the institute's technical draftsman had
to do the drawings, but my friend wanted to use computer-generated
graphs (small wonder). So I had gnuplot generate these symbols
according to the institute's designs, and the patch was included
in the official distribution later.

On Tuesday, March 8, 2022 at 9:58:52 AM UTC-6, EricP wrote:
> Ivan Godard wrote:
> > On 3/7/2022 11:10 AM, EricP wrote:
> >> Ivan Godard wrote:
> >>> On 3/7/2022 7:10 AM, EricP wrote:
> >>> > - user mode exception/signal handler entry,exit
> >>>
> >>> Why are exceptions different from calls you didn't ask for?
> >>
> >> If I was doing it, the OS deposits (pushes) a packet of exception info
> >> and the return PC onto the apps' user mode stack, and OS returns to
> >> the exception routine. User mode exception handler saves the full integer
> >> context on the stack, and calls the exception dispatcher routine
> >> passing pointers to the exception info and saved context structs as args.
> >> Exception handlers can edit saved context as they wish.
> >> When handlers return, exception dispatcher reloads the now possibly
> >> edited
> >> interrupted context, restores stack, and returns to the possibly
> >> edited PC.
> >
> > How do you do it if there are no modes?
>
> The main problem is how does exception information get delivered
> to the offending execution, since exceptions are non-maskable so
<
FP-imprecise is maskable on essentially every machine.
<
You just have to have a good plan as to what happens when a masked
exception transpires. Many of them disappear silently (integer overflow
wraps), many of them get different results (FP overflows to infinity) and
some of them result in termination (page fault).
<
> a single set of registers could be overwritten by multiple exceptions.
>
> Pushing an exception descriptor on the stack is the usual way to handle
> this but that has its own issues, like page faults pushing the packet,
> stack overflow, variable exception packet size complicates interrupt return.
> Also it assumes the ISA has a designated stack register, and may require
> coordination of stack allocation with the OS like Linux "red zones".
>
> If its not hardware pushing the packet then the OS emulates this where
> an exception halts the app thread, spilling its context to memory.
> Then kernel thread edits the app stack and context to push the
> exception packet on the app stack and the PC to a exception handler,
> and then restarts the app thread. This is basically what WinNT does.
>
> The main complaint that people seem to have is that exceptions are
> too expensive, or that the trip through the operating system to
s/trip/excursion/
> deliver them is too expensive.
<
A lot of this is that: it takes hundreds of cycles to get from user mode code
exception to handler mode code, and hundreds of cycles to get back, then
another hundred cycles to get the caches warmed up again.
<
If only there were a way to make those "hundreds" into <say> 10-cycles.
<
> Aside from page fault of valid addresses, which is handled by the OS anyway,
> the only exception that is performance critical is the recent introduction
> of hardware transaction memory HTM aborts delivered directly to the app.
<
This is why I banned exceptions from ESM ATOMIC events. Exceptions inside
an ATOMIC event cause control transfer to failure location BEFORE raising
the exception.

MitchAlsup <MitchAlsup@aol.com> writes:

> On Sunday, March 6, 2022 at 5:20:10 PM UTC-6, Tim Rentsch wrote:
>
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>
>>> On 2022-03-06 16:31, Tim Rentsch wrote:
>>>
>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>
>>>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>>>
>>>>>> Declarable (!) precedence was a disaster
>>>>>> in A68 - what's the precedence of left circular shift?
>>>>
>>>> (For the record, I agree that declarable precedence is a bad
>>>> idea.)
>>>>
>>>>> IMO the general concept of precedence is a disaster. You can
>>>>> do implicit parenthesizing between well-established pairs of
>>>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>>>> establish a transitive relation (don't accept a+b and c).
>>>>>
>>>>> My take would be to always require parenthesis when dealing
>>>>> with a pair of operators that are not among the few exceptions
>>>>> for which a binding relation is defined (when in doubt, don't
>>>>> add an exception, e.g., for the pair of "and" and "or").
>>>>
>>>> In my view this conclusion is exactly backwards. Taking C as a
>>>> canonical example, given that C does have precisely defined
>>>> precedence rules, it would be better if any redundant parentheses
>>>> were disallowed and flagged as errors by the compiler. In a very
>>>> short time there would be no confusion about what various
>>>> combinations of operators meant, and no worry about developers
>>>> misunderstanding them.
>>>
>>> I don't believe that for a second! Many programmers switch
>>> between languages, more or less frequently, and different
>>> languages have different operator symbols and sometimes different
>>> precedence systems. People forget fiddly things like precedences,
>>> especially when they are sure that they remember...
>>
>> That's why it's important to include the second part of my
>> proposal, where expected precedence relationships can be
>> indicated with whitespace, and have those be checked during
>> compilation. Doing that will also reinforce the learning
>> process, because reading code supplies an ongoing stream of
>> information about what the precedence relationships are in each
>> of the various languages.
>
> This sounds like a job for the text editor, coloring variables and
> operators differently based on precedence. Text editors already do
> this for key words in languages. They also match up ( with ) and [
> with ] and { with }. Seems like a natural extension.

It might be helpful for some people to use such a feature as a
transition tool, but the goal of the proposal would make such
tools unnecessary: to make realizing precedence relationships
completely autonomic, for both reading and writing, to the point
where any "help" from an editor tool would be at best a useless
distraction.

MitchAlsup wrote:
> On Tuesday, March 8, 2022 at 9:58:52 AM UTC-6, EricP wrote:
>> Ivan Godard wrote:
>>> On 3/7/2022 11:10 AM, EricP wrote:
>>>> Ivan Godard wrote:
>>>>> On 3/7/2022 7:10 AM, EricP wrote:
>>>>>> - user mode exception/signal handler entry,exit
>>>>> Why are exceptions different from calls you didn't ask for?
>>>> If I was doing it, the OS deposits (pushes) a packet of exception info
>>>> and the return PC onto the apps' user mode stack, and OS returns to
>>>> the exception routine. User mode exception handler saves the full integer
>>>> context on the stack, and calls the exception dispatcher routine
>>>> passing pointers to the exception info and saved context structs as args.
>>>> Exception handlers can edit saved context as they wish.
>>>> When handlers return, exception dispatcher reloads the now possibly
>>>> edited
>>>> interrupted context, restores stack, and returns to the possibly
>>>> edited PC.
>>> How do you do it if there are no modes?
>> The main problem is how does exception information get delivered
>> to the offending execution, since exceptions are non-maskable so
> <
> FP-imprecise is maskable on essentially every machine.
> <
> You just have to have a good plan as to what happens when a masked
> exception transpires. Many of them disappear silently (integer overflow
> wraps), many of them get different results (FP overflows to infinity) and
> some of them result in termination (page fault).

Yes. But float exception masking different from interrupt masking.
Since it is enabled under user control, the OS has to be prepared
to deal with their possibile arrival in any case.

The problem for exceptions, and why they are different from maskable
interrupts, is reentrancy - exception are potentially infinitly reentrant.
Since exceptions are defined by the ISA, not triggering one is
often just a matter of not doing anything that could cause one.

Avoiding reentrancy in the float exception handler is as easy as
just not using any float instructions in the non-reentrant portion
of the OS handler until the HW exception info block has been saved
in a reentrant place, i.e. copy it to the threads' kernel stack.

Reentrancy is why I put Errors in a different category from Interrupts
and Exceptions. Like exceptions, errors are usually nonmaskable and
potentially infinitely reentrant. Like exceptions, some errors cause
instruction abort, others are delivered after instruction finishes.
Like interrupts, errors can be synchronous or asynchronous.
Unlike exceptions, some errors cannot be avoided by simply not doing
certain things, so you have to deal with the possible reentrancy
(e.g. memory errors in the memory error handler routine).
Unlike exceptions and interrupts, after errors instructions may
or may not be restartable, and this may be model specfic.
While exceptions are defined by the ISA, delivery of exception,
interrupt and error information is HW model specific.

> <
>> a single set of registers could be overwritten by multiple exceptions.
>>
>> Pushing an exception descriptor on the stack is the usual way to handle
>> this but that has its own issues, like page faults pushing the packet,
>> stack overflow, variable exception packet size complicates interrupt return.
>> Also it assumes the ISA has a designated stack register, and may require
>> coordination of stack allocation with the OS like Linux "red zones".
>>
>> If its not hardware pushing the packet then the OS emulates this where
>> an exception halts the app thread, spilling its context to memory.
>> Then kernel thread edits the app stack and context to push the
>> exception packet on the app stack and the PC to a exception handler,
>> and then restarts the app thread. This is basically what WinNT does.
>>
>> The main complaint that people seem to have is that exceptions are
>> too expensive, or that the trip through the operating system to
> s/trip/excursion/
>> deliver them is too expensive.
> <
> A lot of this is that: it takes hundreds of cycles to get from user mode code
> exception to handler mode code, and hundreds of cycles to get back, then
> another hundred cycles to get the caches warmed up again.
> <
> If only there were a way to make those "hundreds" into <say> 10-cycles.

I think everyone agrees that x86 has 40 years of barnacles attached
to its interrupts and exceptions.
And there are multiple ways to not step in the same cow pies.

Since I have super and user mode, I would start by pipelining the mode
change wherever possible, by attaching the Super/User flag to each uOp.
That gets rid of the pipeline drain and bubble for SysCall,
Return from Exception or Interrupt REI, and device interrupts.
It remains for exceptions as for me they are only recognized at retire.

A small hardware stack eliminates memory accesses to save the
nested interrupted PC and context.
Having exception and interrupt handler addresses calculated eliminates
the memory table lookup, allowing direct immediate handler dispatch.

An MMU with block address translate eliminates TLB misses for most OS
code and data.

A small special 4kB block of per-cpu SRAM can store the interrupt
and exception handler prologues and epilogues. Combined with the
MMU block translate allows the fetch buffers to be loaded immediately.

> <
>> Aside from page fault of valid addresses, which is handled by the OS anyway,
>> the only exception that is performance critical is the recent introduction
>> of hardware transaction memory HTM aborts delivered directly to the app.
> <
> This is why I banned exceptions from ESM ATOMIC events. Exceptions inside
> an ATOMIC event cause control transfer to failure location BEFORE raising
> the exception.

Yes, I don't want this as an exception either as I don't want to
roll back the register set to the start of the transaction.

Firstly because from a user point of view they will want to
pass information from inside a failed transaction to outside.

Secondly, from a hardware point of view, the current mechanism for
rolling back register changes is a checkpoint. However a checkpoint
retires when its associated instruction retires. The means that
the a transaction ATXSTART instruction could not retire until
it processed and was ready to retire the ATXCOMMIT instruction.
By not defining a transaction as a register checkpoint, it goes away.
Or I'd have to figure out a whole different way to manage
checkpoint, rollback, register rename and free lists.

So transaction abort is just a jump that can trigger asychronously,
tossing certain memory updates and writing a status register.

Ivan Godard <ivan@millcomputing.com> writes:
>On 3/7/2022 12:19 AM, Anton Ertl wrote:
>> I think that type systems are an area where formal descriptions are
>> relatively close to being good enough to being used. The main problem
>> is that every programming language has its own type system with its
>> own twists, that results in its own notation. There is no unifying
>> notation like (E)BNF or stack effect notation that is usable for
>> describing many languages.
>>
>> - anton
>
>There is such: VWG, perhaps others.

What formal notations I have seen in this area are not close to VWG.

>There are two problems: VWG itself
>is a mouthful, and to formalize a type system by any complete and
>correct means you have to have defined the system, and no new language
>has gotten all the arm-waving out.

If we had a successful formal notation, that would be no problem. The
way that the language designer wrote down the formal notation would
settle it; and if there were any problems with the result, they would
be attacked in later revisions; or in prose (like the dangling else is
dealt with in the Pascal Report).

But we have no successful formal notation for type systems.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Wednesday, March 9, 2022 at 11:38:27 AM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Tuesday, March 8, 2022 at 9:58:52 AM UTC-6, EricP wrote:
> >> Ivan Godard wrote:
> >>> On 3/7/2022 11:10 AM, EricP wrote:
> >>>> Ivan Godard wrote:
> >>>>> On 3/7/2022 7:10 AM, EricP wrote:
> >>>>>> - user mode exception/signal handler entry,exit
> >>>>> Why are exceptions different from calls you didn't ask for?
<
Note the word exception here
<
> >>>> If I was doing it, the OS deposits (pushes) a packet of exception info
> >>>> and the return PC onto the apps' user mode stack, and OS returns to
> >>>> the exception routine. User mode exception handler saves the full integer
> >>>> context on the stack, and calls the exception dispatcher routine
> >>>> passing pointers to the exception info and saved context structs as args.
> >>>> Exception handlers can edit saved context as they wish.
> >>>> When handlers return, exception dispatcher reloads the now possibly
> >>>> edited
> >>>> interrupted context, restores stack, and returns to the possibly
> >>>> edited PC.
> >>> How do you do it if there are no modes?
> >> The main problem is how does exception information get delivered
> >> to the offending execution, since exceptions are non-maskable so
<
Note the word exception here
<
> > <
> > FP-imprecise is maskable on essentially every machine.
> > <
> > You just have to have a good plan as to what happens when a masked
> > exception transpires. Many of them disappear silently (integer overflow
> > wraps), many of them get different results (FP overflows to infinity) and
> > some of them result in termination (page fault).
<
> Yes. But float exception masking different from interrupt masking.
> Since it is enabled under user control, the OS has to be prepared
> to deal with their possibile arrival in any case.
<
I was answering the posed point. Interrupts are different from exceptions
and you specifically used the word exceptions. BTW in my design
interrupts are not masked, and certainly not masked by a CPU.
>
> The problem for exceptions, and why they are different from maskable
> interrupts, is reentrancy - exception are potentially infinitly reentrant.
> Since exceptions are defined by the ISA, not triggering one is
> often just a matter of not doing anything that could cause one.
>
> Avoiding reentrancy in the float exception handler is as easy as
> just not using any float instructions in the non-reentrant portion
> of the OS handler until the HW exception info block has been saved
> in a reentrant place, i.e. copy it to the threads' kernel stack.
>
> Reentrancy is why I put Errors in a different category from Interrupts
<
Can you define the term Error ? Error = "Machine Check" ?
<
> and Exceptions. Like exceptions, errors are usually nonmaskable and
> potentially infinitely reentrant. Like exceptions, some errors cause
> instruction abort, others are delivered after instruction finishes.
> Like interrupts, errors can be synchronous or asynchronous.
<
Interrupts are, by definition, asynchronous.
<
> Unlike exceptions, some errors cannot be avoided by simply not doing
> certain things, so you have to deal with the possible reentrancy
> (e.g. memory errors in the memory error handler routine).
<
How is this different from a page fault in the page fault handler ?
<
> Unlike exceptions and interrupts, after errors instructions may
> or may not be restartable, and this may be model specfic.
> While exceptions are defined by the ISA, delivery of exception,
> interrupt and error information is HW model specific.
> > <
> >> a single set of registers could be overwritten by multiple exceptions.
> >>
> >> Pushing an exception descriptor on the stack is the usual way to handle
> >> this but that has its own issues, like page faults pushing the packet,
> >> stack overflow, variable exception packet size complicates interrupt return.
> >> Also it assumes the ISA has a designated stack register, and may require
> >> coordination of stack allocation with the OS like Linux "red zones".
> >>
> >> If its not hardware pushing the packet then the OS emulates this where
> >> an exception halts the app thread, spilling its context to memory.
> >> Then kernel thread edits the app stack and context to push the
> >> exception packet on the app stack and the PC to a exception handler,
> >> and then restarts the app thread. This is basically what WinNT does.
> >>
> >> The main complaint that people seem to have is that exceptions are
> >> too expensive, or that the trip through the operating system to
> > s/trip/excursion/
> >> deliver them is too expensive.
> > <
> > A lot of this is that: it takes hundreds of cycles to get from user mode code
> > exception to handler mode code, and hundreds of cycles to get back, then
> > another hundred cycles to get the caches warmed up again.
> > <
> > If only there were a way to make those "hundreds" into <say> 10-cycles.
> I think everyone agrees that x86 has 40 years of barnacles attached
> to its interrupts and exceptions.
> And there are multiple ways to not step in the same cow pies.
>
> Since I have super and user mode, I would start by pipelining the mode
> change wherever possible, by attaching the Super/User flag to each uOp.
> That gets rid of the pipeline drain and bubble for SysCall,
> Return from Exception or Interrupt REI, and device interrupts.
> It remains for exceptions as for me they are only recognized at retire.
<
Lipstick on a pig......much of the need to drain the pipeline at Syscall is
because you need pending but unrecognized exceptions to be raised
in the thread before Syscall transfers control. Blame vonNeumann (i.e.,
precise exceptions); not me.
>
> A small hardware stack eliminates memory accesses to save the
> nested interrupted PC and context.
> Having exception and interrupt handler addresses calculated eliminates
> the memory table lookup, allowing direct immediate handler dispatch.
<
It is still likely missing its code cache footprint.
>
> An MMU with block address translate eliminates TLB misses for most OS
> code and data.
>
> A small special 4kB block of per-cpu SRAM can store the interrupt
> and exception handler prologues and epilogues. Combined with the
> MMU block translate allows the fetch buffers to be loaded immediately.
<
You could always to the PDP-11 trick: if control arrives; the core gets to
completely execute 1 instruction before relinquishing. This instruction
could be ENTER. Afterwards, you can take another interrupt/exception
to the same handler/thread.
<
> > <
> >> Aside from page fault of valid addresses, which is handled by the OS anyway,
> >> the only exception that is performance critical is the recent introduction
> >> of hardware transaction memory HTM aborts delivered directly to the app.
> > <
> > This is why I banned exceptions from ESM ATOMIC events. Exceptions inside
> > an ATOMIC event cause control transfer to failure location BEFORE raising
> > the exception.
<
> Yes, I don't want this as an exception either as I don't want to
> roll back the register set to the start of the transaction.
>
> Firstly because from a user point of view they will want to
> pass information from inside a failed transaction to outside.
<
how much more than "it failed" is wanted outside ? everything dealing
with intermediate state has become stale.
>
> Secondly, from a hardware point of view, the current mechanism for
> rolling back register changes is a checkpoint. However a checkpoint
> retires when its associated instruction retires. The means that
> the a transaction ATXSTART instruction could not retire until
> it processed and was ready to retire the ATXCOMMIT instruction.
> By not defining a transaction as a register checkpoint, it goes away.
<
I specifically left a means for code to leave a trail of data that can be
<say> printf()ed if the event fails. You can't to this with checkpoint
recovery. I agree.
<
> Or I'd have to figure out a whole different way to manage
> checkpoint, rollback, register rename and free lists.
<
Importantly, in my definition space: ATOMIC stuff is outside of
vonNeumann precision. Due to data dependencies, if an event fails
an instruction leaving a trail that is programmatically later than
another instruction also leaving a trail, the later can have executed
while the former did not. When the event fails, control transfers
as fast as possible with latent instructions being cancelled.
>
> So transaction abort is just a jump that can trigger asychronously,
> tossing certain memory updates and writing a status register.

On 3/9/2022 10:00 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 3/7/2022 12:19 AM, Anton Ertl wrote:
>>> I think that type systems are an area where formal descriptions are
>>> relatively close to being good enough to being used. The main problem
>>> is that every programming language has its own type system with its
>>> own twists, that results in its own notation. There is no unifying
>>> notation like (E)BNF or stack effect notation that is usable for
>>> describing many languages.
>>>
>>> - anton
>>
>> There is such: VWG, perhaps others.
>
> What formal notations I have seen in this area are not close to VWG.
>
>> There are two problems: VWG itself
>> is a mouthful, and to formalize a type system by any complete and
>> correct means you have to have defined the system, and no new language
>> has gotten all the arm-waving out.
>
> If we had a successful formal notation, that would be no problem. The
> way that the language designer wrote down the formal notation would
> settle it; and if there were any problems with the result, they would
> be attacked in later revisions; or in prose (like the dangling else is
> dealt with in the Pascal Report).
>
> But we have no successful formal notation for type systems.

Depends on what "successful" means :-) If "does the job" then we have
some. If "is intellectually tractable in the face of politics" then we
don't.

On Wednesday, March 9, 2022 at 1:50:30 PM UTC-6, Ivan Godard wrote:
> On 3/9/2022 10:00 AM, Anton Ertl wrote:
> > Ivan Godard <iv...@millcomputing.com> writes:
> >> On 3/7/2022 12:19 AM, Anton Ertl wrote:
> >>> I think that type systems are an area where formal descriptions are
> >>> relatively close to being good enough to being used. The main problem
> >>> is that every programming language has its own type system with its
> >>> own twists, that results in its own notation. There is no unifying
> >>> notation like (E)BNF or stack effect notation that is usable for
> >>> describing many languages.
> >>>
> >>> - anton
> >>
> >> There is such: VWG, perhaps others.
> >
> > What formal notations I have seen in this area are not close to VWG.
> >
> >> There are two problems: VWG itself
> >> is a mouthful, and to formalize a type system by any complete and
> >> correct means you have to have defined the system, and no new language
> >> has gotten all the arm-waving out.
> >
> > If we had a successful formal notation, that would be no problem. The
> > way that the language designer wrote down the formal notation would
> > settle it; and if there were any problems with the result, they would
> > be attacked in later revisions; or in prose (like the dangling else is
> > dealt with in the Pascal Report).
> >
> > But we have no successful formal notation for type systems.
> Depends on what "successful" means :-) If "does the job" then we have
> some. If "is intellectually tractable in the face of politics" then we
> don't.
<
I, personally, have never seen a type system that can even annotate all of the
exceptions that can be raised on calculations of type, or explain why ADD can
overflow but AND cannot; or that ADD can overflow by 1-bit and multiply can
overflow by n-1-bits.