On Wed, Jul 11, 2018 at 9:53 AM, Riccardo GUIDA
<riccardo.gu...@gmail.com> wrote:
> Hi, thanks for the feedback.

Actually, thank you 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 ...

OK, point taken.

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

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.

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

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

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

> 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


  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.

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 email 
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to