That's fine. I'm comfortable with the Unix/ASCII conventions. I was
mainly wondering whether dependence on ⎕TC might break my program on a
different APL.
On Sun, 2014-06-01 at 12:02 +0200, Juergen Sauermann wrote:
> Hi David,
>
> I believe that the IBM specified behavior is only achievable (if at
Hi Jüergen,
Sorry for the miscommunication.
SVN 306 does fix 2⊃⎕ec. However, 3⊃⎕ec is still incorrect.
3⊃⎕ec should be the same as what ⎕em would have been without ⎕ec in the
case where ⎕ec traps an error.
Specifically: 3⊃⎕ec should be a three-row text array in which line 1 is
the error message
Just offering an opinion -
Since APL trace and stop are quite useful, and are part of the standard, my
opinion is that these should be top priority - second only to bug fixes.
These should come before work on enhancements or fixes to extensions.
Thanks.
Blake
Thanks Jürgen for correcting my comment.
You've prompted me to browse through my venerable copy of Josuttis' The C++
Standard Library.
respect…
Peter
On 2014-06-01, at 8:00 AM, Juergen Sauermann
wrote:
> Hi Peter,
>
> almost correct. The first comment should be "// may point to an optional
Hi David,
thanks, fixed in SVN 306.
/// Jürgen
On 05/31/2014 07:51 PM, David B. Lamkins wrote:
See the IBM Reference, page 280, paragraph 3.
When ⎕EC executes an expression that signals a user-defined error, the
second and third items of the result should be the same as the
expression's ⎕ET
Hi Peter,
almost correct. The first comment should be "// may point to an optional
string typically containing 6 spaces".
prompt can be 0 and then no prompt is printed. Otherwise the function
pushes the prompt (backwards)
back into stdin. Whether that works is a matter of the underlying
operat
Hi David,
I believe that the IBM specified behavior is only achievable (if at all)
with platform specific (actually terminal specific) APL variants. The header
on page 335 says:
*⎕TC Contains a three-item character vector of terminal control characters:
⎕TC[1]—backspace
⎕TC[2]—new line (return
