Assert Dfn

General APL language issues

Re: Assert Dfn

Postby gil on Tue May 14, 2019 9:11 am

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` ? ;)
gil
 
Posts: 61
Joined: Mon Feb 15, 2010 12:42 am

Re: Assert Dfn

Postby Roger|Dyalog on Tue May 14, 2019 3:16 pm

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).
Roger|Dyalog
 
Posts: 139
Joined: Thu Jul 28, 2011 10:53 am

Re: Assert Dfn

Postby kai on Tue May 14, 2019 3:39 pm

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.
User avatar
kai
 
Posts: 102
Joined: Thu Jun 18, 2009 5:10 pm
Location: Stevenage, UK

Re: Assert Dfn

Postby Phil Last on Tue May 14, 2019 9:56 pm

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
User avatar
Phil Last
 
Posts: 504
Joined: Thu Jun 18, 2009 6:29 pm

Re: Assert Dfn

Postby Morten|Dyalog on Wed May 15, 2019 8:45 pm

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.
User avatar
Morten|Dyalog
 
Posts: 343
Joined: Tue Sep 09, 2008 3:52 pm

Re: Assert Dfn

Postby Morten|Dyalog on Thu May 16, 2019 7:49 am

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

Code: Select all
AFFIRM ERROR
      ⎕SIGNAL 98
      ∧
User avatar
Morten|Dyalog
 
Posts: 343
Joined: Tue Sep 09, 2008 3:52 pm

Re: Assert Dfn

Postby Roger|Dyalog on Thu May 16, 2019 3:21 pm

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
 
Posts: 139
Joined: Thu Jul 28, 2011 10:53 am

Re: Assert Dfn

Postby Roger|Dyalog on Thu May 16, 2019 3:31 pm

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.
Roger|Dyalog
 
Posts: 139
Joined: Thu Jul 28, 2011 10:53 am

Re: Assert Dfn

Postby Jay|Dyalog on Fri May 17, 2019 3:18 pm

Phil Last wrote: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".
Jay|Dyalog
 

Re: Assert Dfn

Postby Phil Last on Sat May 18, 2019 12:10 pm

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.
User avatar
Phil Last
 
Posts: 504
Joined: Thu Jun 18, 2009 6:29 pm

PreviousNext

Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest