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  > 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. -- 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 email@example.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.