Re: [Bug-apl] A few problems

[vvs]

On Sun, Feb 3, 2019 at 9:00 PM Dr. Jürgen Sauermann
<address@hidden> wrote:
> 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.

While this is certainly true, I wouldn't buy that argument. For
example C/C++ allows anyone to shoot themselves in their foot using
pointers, but despite being not safe those programming languages
developed vast arsenal of tools to mitigate that deficiency. And even
using non-safe memset caused warnings in recent versions of compiler.

> 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 ⍎.

Even if the problem doesn't have general solution, that solution is
possible in particular cases like this. Of course, that depends on
available programming resources. In this particular case it can be
determined that assignment is performed to a function, so it can be
detected early.

> 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.

I meant that tightening execution environment by implementing
restrictions is a feature expected from servers. Anybody could use the
same set of features on his personal desktop but it's rarely happen in
practice because it's mighty inconvenient for software development and
debugging.

> Also, it still could lead to interpreter crash and possible loss of
> data.
>
> Like every other faulty program.

Of course. But could this be an excuse to not take preventive measures
where we can?

> 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.

Thanks. Every design decision depends on local constraints. Though,
why not to use look-ahead and detect that as incorrect assignment to a
function? I see it as a more direct and clean approach. Would it be
too difficult to implement?

With best regards.