bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] A few problems


From: Dr . Jürgen Sauermann
Subject: Re: [Bug-apl] A few problems
Date: Sun, 3 Feb 2019 20:00:00 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Hi vvs,

see below...

/// Jürgen

On 02/03/2019 07:14 PM, vvs wrote:
On Sun, Feb 3, 2019 at 12:49 PM Dr. Jürgen Sauermann
<address@hidden> wrote:
thanks, hopefully fixed in SVN 1122. The gcc guys create new
warnings faster than I can fix them.
Thanks. It's compiled now without problems.

Regarding the other problem:

      ∇A
[1]  A←0
      ∇

when the Symbol A is resolved it immediately causes the
execution of A (iff A is a niladic function). That happens before
the assignment can take place. The consequence is an infinite
recursion of A (which can, BTW, be limited with ⎕SYL[1;2]).
That explains it, of course. But isn't it a dangerous behavior?
Almost every language has that sort of dangerous behaviour.
I would rather call it a programmer's fault instead of dangerous
behaviour because that better describes the true source of the
problem. There is a common term for it: garbage in - garbage
out.
Consider this example:

∇A
[1] B←0
∇

∇B
[1] A←0
∇

A←1
Same problem as before except that the infinite recursion
now spans 2 functions, which, in turn makes a correction
impossible for bit A and B to even detect the case. Not to
mention the case where ⍎ is used, which makes the whole
story a decidability issue because no one can predict the argument of ⍎.

This can easily happen if you copy functions from different
workplaces, especially not yours and where functions are much more
complex than in this artificial case. Certainly, it could be
restricted by ulimit (or ⎕SYL[1;2]), but this is only a palliative and
usually is common for servers, not for desktops used by developers.
I doubt so because ⎕SYL is a GNU APL feature and I haven't
from anybody using it for a server. Actually ⎕SYL was invented
exactly for this purpose: to prevent APL crashing or swapping.
Also, it still could lead to interpreter crash and possible loss of
data.
Like every other faulty program.

How other APL implementations deal with it? Isn't it specified by ISO
standard? I'd look at how Dyalog works in this case, but their Linux
version requires 64-bit OS which I'd like to avoid for several reasons
(one of them is that x86_64 doesn't have segments which are used on
IA32 architecture to validate fine-grained pointer access).
I am pretty sure that GNU APL behaves according to the ISO
standard up to the point where it crashes. The only wrong
behaviour that I currently see is that it should catch the bad
alloc exception and signal WS full instead of looping forever.
I will look into this.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]