Re: [Bug-apl] A few problems

[Dr . Jürgen Sauermann]

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 <mail@jürgen-sauermann.de> 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.