[fricas-devel] Intepreter: type declaration ignored in == AND:

[Riccardo GUIDA]

Hi

Command line interpreter: I realize that type declaration is ignored in delayed assignment == even for variables (see [1] for a similar behavior for functions)

Same behavior from .input file.

AND

At the same occasion I get a weird system error in )display properties, which might interest Waldek...

cheers,
riccardo

(1) -> x:Integer := 1

(1) 1
Type: Integer
(2) -> y:Integer == 1
Type: Void
(3) -> z == 1
Type: Void
(4) -> [x,y,z]
Compiling body of rule z to compute value of type PositiveInteger

(4) [1, y, 1]
Type: List(Polynomial(Integer))
(5) -> )display properties x y z
Properties of x :
Declared type or mode: Integer
Value (has type Integer): 1
Properties of y :
none
Properties of z :
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.



(5) -> )read test.input
)clear completely

All user variables and function definitions have been cleared.
All )browse facility databases have been cleared.
Internally cached functions and constructors have been cleared.
)clear completely is finished.
x2:Integer := 1


(1) 1
Type: Integer
y2:Integer == 1

Type: Void
z2 == 1

Type: Void
[x2,y2,z2]

Compiling body of rule z2 to compute value of type PositiveInteger

(4) [1, y2, 1]
Type: List(Polynomial(Integer))
)display properties x2 y2 z2

Properties of x2 :
Declared type or mode: Integer
Value (has type Integer): 1
Properties of y2 :
none
Properties of z2 :
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.




[1]
https://www.mail-archive.com/fricas-***@googlegroups.com/msg12308.html

[Bill Page]

On Tue, Jul 10, 2018 at 11:51 AM, Riccardo GUIDA

Post by Riccardo GUIDA
Command line interpreter: I realize that type declaration is ignored
in delayed assignment == even for variables (see [1] for a similar
behavior for functions)
Same behavior from .input file.

Although this terminology is used in a few places, I do not think it
is correct to call == delayed assignment. Rather it only represents
kind of function definition via matching (which granted, does involve
some form of delayed assignment). More specifically in the interpreter
== defines a "rule". In the case of ==, : is an operator like any
other. E.g.

(1) -> (x+y) == 3
Type: Void
(2) -> (x:Integer) == 4
Type: Void
(3) -> )display value +
Definition: + (x, y) == 3
(3) -> )display value :
Definition: : (x, Integer) == 4
(3) -> x+y
Compiling function + with type (Variable(x), Variable(y)) ->
PositiveInteger

(3) 3
Type: PositiveInteger
(4) -> x:Integer
Type: Void

Only the last result is a bit anomalous. One might have expected the
value 4 but without the == the interpreter is treating this like a
declaration rather than an expression.

As illustrated in the users guide, this sort of matching in the
interpreter is useful for defining functions by cases etc. But I think
it can produce rather surprising and unexpected effects. E.g.

(4) -> 1+1 == 3
Type: Void
(5) -> 1+1
Compiling function + with type (PositiveInteger, PositiveInteger)
-> PositiveInteger

(5) 3
Type: PositiveInteger

(6) -> 1+2

The function + is not defined for the given argument(s).

This is very unlike the semantics implemented implemented in the
library compiler. In spite of this, the interpreter does otherwise
manage to interface with the FriCAS library quite well.

[oldk1331]

Post by Riccardo GUIDA
(2) -> y:Integer == 1
Type: Void

This is a strange way to input in FriCAS, it actually defined a rule for ':'

(1) -> y:Integer == 1
Type: Void
(2) -> y:Integer == 1
1 old definition(s) deleted for function or rule :
Type: Void
(3) -> :

(3) : (y, Integer) == 1
Type: FunctionCalled(:)


As for "BOOT::|sayFunctionDeps| is undefined" error, it can be fixed
by following patch,
after the patch, ")display properties" works:

(1) -> z == 2
Type: Void
(2) -> )display properties z
Properties of z :
This is an interpreter rule.
Definition: z () == 2


diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index 24bdc499..f25e88fb 100644
--- a/src/interp/i-syscmd.boot
+++ b/src/interp/i-syscmd.boot
@@ -913,26 +913,7 @@ displayProperties(option,l) ==
sayMSG '" This is recursive."
prop = 'isInterpreterFunction =>
sayMSG '" This is an interpreter function."
- sayFunctionDeps v where
- sayFunctionDeps x ==
- if dependents := GETALIST($dependentAlist,x) then
- null rest dependents =>
- sayMSG ['" The following function or rule ",
- '"depends on this:",:bright first dependents]
- sayMSG
- '" The following functions or rules depend on this:"
- msg := ["%b",'" "]
- for y in dependents repeat msg := ['" ",y,:msg]
- sayMSG [:nreverse msg,"%d"]
- if dependees := GETALIST($dependeeAlist,x) then
- null rest dependees =>
- sayMSG ['" This depends on the following function ",
- '"or rule:",:bright first dependees]
- sayMSG
- '" This depends on the following functions or rules:"
- msg := ["%b",'" "]
- for y in dependees repeat msg := ['" ",y,:msg]
- sayMSG [:nreverse msg,"%d"]
+ sayFunctionDeps v
prop = 'isInterpreterRule =>
sayMSG '" This is an interpreter rule."
sayFunctionDeps v
@@ -947,6 +928,26 @@ displayProperties(option,l) ==
sayKeyedMsg("S2IZ0068",[option])
terminateSystemCommand()

+sayFunctionDeps x ==
+ if dependents := GETALIST($dependentAlist,x) then
+ null rest dependents =>
+ sayMSG ['" The following function or rule ",
+ '"depends on this:",:bright first dependents]
+ sayMSG
+ '" The following functions or rules depend on this:"
+ msg := ["%b",'" "]
+ for y in dependents repeat msg := ['" ",y,:msg]
+ sayMSG [:nreverse msg,"%d"]
+ if dependees := GETALIST($dependeeAlist,x) then
+ null rest dependees =>
+ sayMSG ['" This depends on the following function ",
+ '"or rule:",:bright first dependees]
+ sayMSG
+ '" This depends on the following functions or rules:"
+ msg := ["%b",'" "]
+ for y in dependees repeat msg := ['" ",y,:msg]
+ sayMSG [:nreverse msg,"%d"]
+
displayModemap(v,val,giveVariableIfNil) ==
for mm in val repeat g(v,mm,giveVariableIfNil) where
g(v,mm,giveVariableIfNil) ==


On Tue, Jul 10, 2018 at 11:51 PM, Riccardo GUIDA

Post by Riccardo GUIDA
Hi
Command line interpreter: I realize that type declaration is ignored in
delayed assignment == even for variables (see [1] for a similar behavior for
functions)
Same behavior from .input file.
AND
At the same occasion I get a weird system error in )display properties,
which might interest Waldek...
cheers,
riccardo
(1) -> x:Integer := 1
(1) 1
Type: Integer
(2) -> y:Integer == 1
Type: Void
(3) -> z == 1
Type: Void
(4) -> [x,y,z]
Compiling body of rule z to compute value of type PositiveInteger
(4) [1, y, 1]
List(Polynomial(Integer))
(5) -> )display properties x y z
Declared type or mode: Integer
Value (has type Integer): 1
none
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.
(5) -> )read test.input
)clear completely
All user variables and function definitions have been cleared.
All )browse facility databases have been cleared.
Internally cached functions and constructors have been cleared.
)clear completely is finished.
x2:Integer := 1
(1) 1
Type: Integer
y2:Integer == 1
Type: Void
z2 == 1
Type: Void
[x2,y2,z2]
Compiling body of rule z2 to compute value of type PositiveInteger
(4) [1, y2, 1]
List(Polynomial(Integer))
)display properties x2 y2 z2
Declared type or mode: Integer
Value (has type Integer): 1
none
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.
[1]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[Riccardo GUIDA]

Hi, thanks for the feedback.


[Bill]> Although this terminology is used in a few places,


"... a few places"? Well, I would say "almost everywhere": Jenks Sutor vol 0, hyperdoc, fricasUG, mathaction ...


[Bill]>I do not think it
[Bill]> is correct to call == delayed assignment. Rather it only represents
[Bill]> kind of function definition via matching (which granted, does involve
[Bill]> some form of delayed assignment). More specifically in the interpreter
[Bill]> == defines a "rule". In the case of ==, : is an operator like any
[Bill]> other. E.g.


I see your point of view. This sheds more light also on T3(f(x)) == ... in [1]

A mystery is that according to the interpreter messages there are "interpreter functions" and "interpreter rules", so one might wonder if there are different, undocumented syntaxes and semantics:

(1) -> z == 1
Type: Void
(2) -> x + y == 5 -x + 10 *y
Type: Void
(3) -> )display properties + z
Properties of + :
This is an interpreter function.
Definition: + (x, y) == 5 - x + 10 y
Properties of z :
This is an interpreter rule.



... I'm starting to believe that the only way for a user to grasp how the interpreter works in many cases is to (learn boot & lisp and) read the source files ... quite time consuming task ... sigh ...



I'm also disturbed by the fact that a (fool) user can happily hide a library operation like +. I would have preferred to be obliged to write something like

IAmNotInsaneAndIReallyWantToRedefine(_+)

before being able to redefine.






[ric]> (2) -> y:Integer == 1

[Oldk1331]> This is a strange way to input in FriCAS, it actually defined a rule for ':'

Well, I had the (unwise) idea of approaching FriCAS by first reading the whole AldorUG, so my test was Aldor-inspired [1]



regards
riccardo

[1] https://www.mail-archive.com/fricas-***@googlegroups.com/msg12354.html
[2] http://www.aldor.org/docs/HTML/chap5.html#3

[Bill Page]

On Wed, Jul 11, 2018 at 9:53 AM, Riccardo GUIDA

Post by Riccardo GUIDA
Hi, thanks for the feedback.

Actually, thank you for the feedback.

Post by Riccardo GUIDA
[Bill]> Although this terminology is used in a few places,
Jenks Sutor vol 0, hyperdoc, fricasUG, mathaction ...

OK, point taken.

Post by Riccardo GUIDA
A mystery is that according to the interpreter messages there are
"interpreter functions" and "interpreter rules", so one might wonder if
...

Yes, probably. The FriCAS interpreter and the SPAD compiler, not to
mention the Aldor compiler, where all written by different people at
different times during the original Axiom research project at IBM.
There is a tendency to approach the interpreter as if it were just a
read-eval-print loop for the compiler but as you have seen this is not
the case. Rather, what happened is that these rather different systems
where "interfaced" in what the developers hoped was a more-or-less
seamless way.

Post by Riccardo GUIDA
... I'm starting to believe that the only way for a user to grasp how
the interpreter works in many cases is to (learn boot & lisp and)
read the source files ... quite time consuming task ... sigh ...

I think it is almost universally agreed among the FriCAS developers
and many users that the interpreter has many flaws and was written in
a manner that does not encourage incremental improvements. There has
been a long expressed desire to re-write the interpreter in SPAD (or
maybe Aldor) but there has also been a persistent lack of resources in
the open source project.

Post by Riccardo GUIDA
I'm also disturbed by the fact that a (fool) user can happily
hide a library operation like +. I would have preferred to be
obliged to write something like
IAmNotInsaneAndIReallyWantToRedefine(_+)
before being able to redefine.

Agreed. In fact the library operation is not hidden as such

(1) -> (1+1)==3
Type: Void
(2) -> (1+1)$Integer

(2) 2
Type: Integer

But the interpreter rule does take precedence over any library
function of the same name. I think it might be better if it was
necessary for the user to explicitly state a preference.

Post by Riccardo GUIDA
[ric]> (2) -> y:Integer == 1
[Oldk1331]> This is a strange way to input in FriCAS,
it actually defined a rule for ':'

This should be considered a bug in the interpreter.

Post by Riccardo GUIDA
Well, I had the (unwise) idea of approaching FriCAS by
first reading the whole AldorUG, so my test was Aldor-inspired [1]

I presume that you expected

y:Integer == 1

and

y:Integer
y == 1

to produce the same results. But the rule is that things on the left
hand side of == are not evaluated - not even the apparent declaration
: !! Probably this should not be the case for :. Instead it should at
least evaluate declarations on the left and return the symbol before
evaluating the rule.

To some extent Aldor was intended to fix what was wrong with the SPAD
compiler, but you should consider it even farther from the interpreter
than SPAD.

[Waldek Hebisch]

Post by oldk1331
As for "BOOT::|sayFunctionDeps| is undefined" error, it can be fixed
by following patch,
(1) -> z == 2
Type: Void
(2) -> )display properties z
This is an interpreter rule.
Definition: z () == 2

OK, please commit.

Post by oldk1331
diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index 24bdc499..f25e88fb 100644
--- a/src/interp/i-syscmd.boot
+++ b/src/interp/i-syscmd.boot
@@ -913,26 +913,7 @@ displayProperties(option,l) ==
sayMSG '" This is recursive."
prop = 'isInterpreterFunction =>
sayMSG '" This is an interpreter function."
- sayFunctionDeps v where
- sayFunctionDeps x ==
- if dependents := GETALIST($dependentAlist,x) then
- null rest dependents =>
- sayMSG ['" The following function or rule ",
- '"depends on this:",:bright first dependents]
- sayMSG
- '" The following functions or rules depend on this:"
- msg := ["%b",'" "]
- for y in dependents repeat msg := ['" ",y,:msg]
- sayMSG [:nreverse msg,"%d"]
- if dependees := GETALIST($dependeeAlist,x) then
- null rest dependees =>
- sayMSG ['" This depends on the following function ",
- '"or rule:",:bright first dependees]
- sayMSG
- '" This depends on the following functions or rules:"
- msg := ["%b",'" "]
- for y in dependees repeat msg := ['" ",y,:msg]
- sayMSG [:nreverse msg,"%d"]
+ sayFunctionDeps v
prop = 'isInterpreterRule =>
sayMSG '" This is an interpreter rule."
sayFunctionDeps v
@@ -947,6 +928,26 @@ displayProperties(option,l) ==
sayKeyedMsg("S2IZ0068",[option])
terminateSystemCommand()
+sayFunctionDeps x ==
+ if dependents := GETALIST($dependentAlist,x) then
+ null rest dependents =>
+ sayMSG ['" The following function or rule ",
+ '"depends on this:",:bright first dependents]
+ sayMSG
+ '" The following functions or rules depend on this:"
+ msg := ["%b",'" "]
+ for y in dependents repeat msg := ['" ",y,:msg]
+ sayMSG [:nreverse msg,"%d"]
+ if dependees := GETALIST($dependeeAlist,x) then
+ null rest dependees =>
+ sayMSG ['" This depends on the following function ",
+ '"or rule:",:bright first dependees]
+ sayMSG
+ '" This depends on the following functions or rules:"
+ msg := ["%b",'" "]
+ for y in dependees repeat msg := ['" ",y,:msg]
+ sayMSG [:nreverse msg,"%d"]
+
displayModemap(v,val,giveVariableIfNil) ==
for mm in val repeat g(v,mm,giveVariableIfNil) where
g(v,mm,giveVariableIfNil) ==
On Tue, Jul 10, 2018 at 11:51 PM, Riccardo GUIDA

Post by Riccardo GUIDA
Hi
Command line interpreter: I realize that type declaration is ignored in
delayed assignment == even for variables (see [1] for a similar behavior for
functions)
Same behavior from .input file.
AND
At the same occasion I get a weird system error in )display properties,
which might interest Waldek...
cheers,
riccardo
(1) -> x:Integer := 1
(1) 1
Integer
(2) -> y:Integer == 1
Void
(3) -> z == 1
Void
(4) -> [x,y,z]
Compiling body of rule z to compute value of type PositiveInteger
(4) [1, y, 1]
List(Polynomial(Integer))
(5) -> )display properties x y z
Declared type or mode: Integer
Value (has type Integer): 1
none
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.
(5) -> )read test.input
)clear completely
All user variables and function definitions have been cleared.
All )browse facility databases have been cleared.
Internally cached functions and constructors have been cleared.
)clear completely is finished.
x2:Integer := 1
(1) 1
Integer
y2:Integer == 1
Void
z2 == 1
Void
[x2,y2,z2]
Compiling body of rule z2 to compute value of type PositiveInteger
(4) [1, y2, 1]
List(Polynomial(Integer))
)display properties x2 y2 z2
Declared type or mode: Integer
Value (has type Integer): 1
none
This is an interpreter rule.
The function BOOT::|sayFunctionDeps| is undefined.
[1]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.