Assert Dfn

[gil]

I love the simplicity of `assert`. Roger, I can't see any comment regarding the use of EN 8. Is Dyalog considering reserving it for `ASSERTION ERROR` ? ;)

[Roger|Dyalog]

Event number 8: There are no plans for the Dyalog interpreter that I know of regarding this event number. In fact, whatever I post in this forum is my own opinion without any official approval or disapproval or pre-knowledge, offered to y'all free of charge and worth every penny. :-)

Having said that, where does the 8 come from? I believe that it came from long ago from ancient versions of "assert". It was in the days of SHARP APL where event number 8 was (and still is) the first unassigned number. (In addition, 8 is a lucky number to the Chinese. My heritage is Chinese. :-) BTW, it should be "assertion failure" rather than "assertion error". When the event is signaled, the assertion is not in error (⍺=⍵, nothing wrong with that), but it has failed (⍺=⍵ when ⍺ is 3 and ⍵ is 4).

[kai]

I see. I overlooked Phil's comment on the fact that

Code: Select all

{shy←0}

is different from

Code: Select all

{
   shy←0
}

But I wonder why. If the reasoning really is that after shy←0} the interpreter knows that it is the end of the dfn then it could equally well be argued that the interpreter has exactly the same knowledge in the second case.

[Phil Last]

it could equally well be argued that the interpreter has exactly the same knowledge in the second case

I should probably have said "parser" rather than "interpreter". It doesn't need to look beyond the current line.

But to return to the topic of the trailing colon on a line.

I disagree with

(In particular, _←assert blah is undesired for aesthetic reasons.) In this case, the trailing colon when used in a dfn is the best that we (John Scholes and I) can do.

First to distinguish the two different uses of the trailing colon.

• a condition which, if true, terminates the function without a result
• a cludge to avoid an assignment without termination - requires a forced zero

Both have issues.

1. functions should return results
2. a misuse of a feature through an accidental loophole in the design that has a questionably convenient side effect

Other examples of the latter that haven't been fixed because of their convenience are

• the automatic fixing of the ⎕OR of a function when passed as a left operand
• the globalisation of an assignment through name∘←value
• the acceptance of an assignment followed immediately by a right brace as the result of a function - the secondary topic of this thread

[Morten|Dyalog]

If my memory is correct, SHARP APL took 8 into use as RESULT ERROR, issued when a function did not return a result but the context expected one, to distinguish that from 6 VALUE ERROR, which was ubsequently only issued if a name was referenced but had no value. The "real" VALUE ERROR 6 was the only number allowed with ⎕TRAP code I (Immediate), which gave applications a chance to resolve the VALUE ERROR (typically by paging code in from a component file). If the VALUE ERROR was resolved, execution of the line would resume (from "mid line").

Back in the days of limited and very fixed workspace size on the SHARP APL timesharing system.

[Morten|Dyalog]

P.S. And I notice that in Dyalog APL:

Code: Select all

AFFIRM ERROR
      ⎕SIGNAL 98
      ∧


[Roger|Dyalog]

First to distinguish the two different uses of the trailing colon.

• a condition which, if true, terminates the function without a result
• a cludge to avoid an assignment without termination - requires a forced zero

You can call it a kludge if you like. A trailing colon in a dfn line is within the dfn rules.

(Isn't it understood that in English jurisprudence, everything not explicitly forbidden is allowed? As opposed to x jurisprudence where everything is forbidden even if explicitly allowed. :-)

[Roger|Dyalog]

If my memory is correct, SHARP APL took 8 into use as RESULT ERROR, ...

You could well be correct WRT "result error".

In Paul Berry's SHARP APL Reference Manual, 8 is the first unused event number. This was so in the original 1979-03 edition (page 110) and in the Additions and Corrections, 1980-07. I believe my use of event 8 in "assert" predated both of these dates.

[Jay|Dyalog]

John explained (I think his word was "excused") the difference between shy1 and shy2 on the grounds that the interpreter knows that "s←⍵" in shy1 is the last expression because it's followed immediately by the brace "}".

      shy4←{s←⍵⋄}

behaves as shy2.

My opinion is that shy2 should return a shy result, just like shy1 does. I don't think the presence of any newlines between the s←⍵ and the } should make a difference. We do have an outstanding request-for-enhancement to this effect -- raised by me. John Scholes did not object to the enhancement, but he didn't seem to feel as strongly about it as I do. In his words "this fix would render the explicit shy-result-returning mechanism 1:shy←⍵ redundant but unaffected".

[Phil Last]

Can I infer that a dfn lacking an unassigned expression would terminate with that last assigned, if any, as a shy result? I can imagine this causing a few headaches in debugging. Especially if combined with techniques whose sole purpose is to avoid both assignment and termination.

Having written a fairly obscure algorithm some years back I was prompted on my next perusal of the function to comment:

⍝ OROK *

and at the end of the function

⍝ * obscurity rules, OK?

I now try to make them as explicit as the complexity will permit.

I should prefer that any change to the above would be opposite to that suggested; that

      shy1←{s←⍵}

should also fail to return a result.