Assert Dfn
24 posts
• Page 2 of 3 • 1, 2, 3
Re: Assert Dfn
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: 71
- Joined: Mon Feb 15, 2010 12:42 am
Re: Assert Dfn
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).
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: 238
- Joined: Thu Jul 28, 2011 10:53 am
Re: Assert Dfn
I see. I overlooked Phil's comment on the fact that
is different from
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.
- 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.
-
kai - Posts: 137
- Joined: Thu Jun 18, 2009 5:10 pm
- Location: Hillesheim / Germany
Re: Assert Dfn
I should probably have said "parser" rather than "interpreter". It doesn't need to look beyond the current line.it could equally well be argued that the interpreter has exactly the same knowledge in the second case
But to return to the topic of the trailing colon on a line.
I disagree with
First to distinguish the two different uses of the trailing colon.(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.
- a condition which, if true, terminates the function without a result
- a cludge to avoid an assignment without termination - requires a forced zero
- functions should return results
- a misuse of a feature through an accidental loophole in the design that has a questionably convenient side effect
- 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
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: Assert Dfn
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.
Back in the days of limited and very fixed workspace size on the SHARP APL timesharing system.
-
Morten|Dyalog - Posts: 453
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Assert Dfn
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: 238
- Joined: Thu Jul 28, 2011 10:53 am
Re: Assert Dfn
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: 238
- Joined: Thu Jul 28, 2011 10:53 am
Re: Assert Dfn
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
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:
I should prefer that any change to the above would be opposite to that suggested; that
Having written a fairly obscure algorithm some years back I was prompted on my next perusal of the function to comment:
and at the end of the function⍝ OROK *
I now try to make them as explicit as the complexity will permit.⍝ * obscurity rules, OK?
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.
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
24 posts
• Page 2 of 3 • 1, 2, 3
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group