On Thu, Feb 7, 2019 at 3:08 PM Dr. Jürgen Sauermann
wrote:
> In that respect NARS is not ISO compliant, but nobody else is because ISO
> contains a number
> of failures which makes it impossible to be 100% compliant.
Thanks for expressing your opinion. That situation is very
unfortunate, though.
On 02/06/2019 05:11 PM, vvs wrote:
On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann
wrote:
Certainly not:
∇Z←A
Z←42
∇
At this point A has token class Niladic-Defined-Function-Name (page 25), An attempt to
change that by:
A←5
is therefore expl
On 02/06/2019 05:24 PM, vvs wrote:
On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann
wrote:
At this point A has token class Niladic-Defined-Function-Name (page 25), An attempt to
change that by:
A←5
is therefore explicitly forbidden by the statem
On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann
wrote:
> At this point A has token class Niladic-Defined-Function-Name (page 25), An
> attempt to
> change that by:
>
> A←5
>
> is therefore explicitly forbidden by the statement on page 67. It has always
> bin that way since
And BTW in any fu
On Wed, Feb 6, 2019 at 4:10 PM Dr. Jürgen Sauermann
wrote:
> Certainly not:
>
> ∇Z←A
> Z←42
> ∇
>
> At this point A has token class Niladic-Defined-Function-Name (page 25), An
> attempt to
> change that by:
>
> A←5
>
> is therefore explicitly forbidden by the statement on page 67. It has always
On 02/05/2019 11:37 PM, vvs wrote:
On Tue, Feb 5, 2019 at 7:08 PM Dr. Jürgen Sauermann
wrote:
It also raises the following question:
∇Z←A
Z←42
∇
A←5
A
What is A and why so? And its is definitely not ISO which says (page 67):
...
If V is a variable-name,
I
On Tue, Feb 5, 2019 at 7:08 PM Dr. Jürgen Sauermann
wrote:
> It also raises the following question:
>
> ∇Z←A
> Z←42
> ∇
>
> A←5
>
> A
>
> What is A and why so? And its is definitely not ISO which says (page 67):
> ...
> If V is a variable-name,
> If the current-class of V is nil or variable,
> Se
On 02/04/2019 09:13 PM, vvs wrote:
On Mon, Feb 4, 2019 at 2:04 PM Dr. Jürgen Sauermann
wrote:
Attempting to solve a not decidable problem at runtime is nothing
that I would dare to try.
Well, it seems that it all depends on implem
On Mon, Feb 4, 2019 at 2:04 PM Dr. Jürgen Sauermann
wrote:
> Attempting to solve a not decidable problem at runtime is nothing
> that I would dare to try.
Well, it seems that it all depends on implementation. While Dyalog
implemented assignment the same way as GNU APL, in NARS2000 it's very
diffe
Hi Bill,
thanks, fixed in SVN
1124.
Best Regards,
/// Jürgen
On 02/04/2019 06:47 PM, Bill Heagy
wrote:
Minor
note: )load appears to be giving a diagnostic:
)load p010
fi
Minor note: )load appears to be giving a diagnostic:
)load p010
filename:'/home/wheagy/workspaces/p010.xml' at Workspace.cc:977
(debian system)
On 2019-02-04 12:22 p.m., vvs wrote:
Hello
On Mon, Feb 4, 2019 at 3:41 PM Dr. Jürgen Sauermann
wrote:
infinite recursion should
Hello
On Mon, Feb 4, 2019 at 3:41 PM Dr. Jürgen Sauermann
wrote:
> infinite recursion should now give WS FULL. SVN 1123.
Thanks, it works now.
Out of curiosity I've installed Dyalog 14.0 32-bit Windows
unregistered version and it behaves the same way, i.e. WS FULL. I
think it'd worth mentioning
Hi,
infinite recursion should now give WS FULL. SVN 1123.
/// Jürgen
On 02/03/2019 09:04 PM, vvs wrote:
On Sun, Feb 3, 2019 at 9:00 PM Dr. Jürgen Sauermann
wrote:
Almost every language has that sort of dangerous behavio
Hi,
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
On Sun, Feb 3, 2019 at 9:00 PM Dr. Jürgen Sauermann
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: gar
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
wrote:
thanks, hopefully fixed in SVN 1122. The gcc guys create new
warnings faster than I can fix them.
On Sun, Feb 3, 2019 at 12:49 PM Dr. Jürgen Sauermann
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
Hi vvs,
thanks, hopefully fixed in SVN 1122. The gcc guys create new
warnings faster than I can fix them.
Regarding the other problem:
∇A
[1] A←0
∇
when the Symbol A is resolved it immediately causes the
execution of
On Sat, Feb 2, 2019 at 9:08 PM Dr. Jürgen Sauermann
wrote:
> thanks for reporting this. Could you please give an example for the gcc
> warnings> I am using
> g++ 4 .8.4 and I am not getting the warnings.
Of course. Here:
g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Wold-style-cast -Werror
-I/
Hi,
thanks for reporting this. Could you please give an example for
the gcc warnings> I am using
g++ 4 .8.4 and I am not getting the warnings.
Thanks,
/// Jürgen
On 02/02/2019 06:38 PM, vvs wrote:
Hi all!
There
Hi all!
There are some (possibly minor) problems with current version of the
interpreter. This is all on Linux with gcc 8.2.1. The first problem
was introduced in latest SVN 1121: compilation now fails without
CXX_WERR=no, because of -Wclass-memaccess. Apparently gcc isn't happy
about using POSIX
21 matches
Mail list logo
