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.