Ralf Hemmecke wrote:
> 
> I've seen things like
> 
>   sayTeX$Lisp mathML.u
> 
> but that's a funny construction and if this is handled as one things it
> is, namely as (sayTeX$Lisp)(mathML.u) then the either the interpreter or
> the spad compiler has a bug.

AFACIS specification changed in time and the code not always
followed.  There were more updates to Spad compiler than
to interpreter.  OTOH interpreter was written later and
some constructs are better handled in interpreter.  So
for some constructs Spad compiler is more up to date, for
some interpreter is more up to date.  In this case I think
handling in Spad compiler is better.
> 
> (1) -> sayTeX$Lisp "blah"
>    There are no library operations named Lisp
>       Use HyperDoc Browse or issue
>                                 )what op Lisp
>       to learn if there is any operation containing " Lisp " in its
>       name.
> 
>    Cannot find a definition or applicable library operation named Lisp
>       with argument type(s)
>                                    String
> 
>       Perhaps you should use "@" to indicate the required return type,
>       or "$" to specify which version of the function you need.
> 
> My understanding is that . binds strongest followed by function
> application and only then comes $.

Truth is more complicated.  As I wrote long ago Spad parser
is whitespace sensitive, so

foo(...)$List (Integer)

and

foo(...)$List(Integer)

are not the same.

> 
> There are lots of places where we have
> 
>    foo(...)$List Integer

Where?  AFAICS the above does not work in Spad.

> 
> In fact, I don't really know about what precedence $ has in contrast to
> juxtaposition, but if the code behaves different in SPAD or the
> interpreter, that is frustrating and I think it should be removed.

My plan is to remove large parts of current interpreter and
replace them by corresponding parts of Spad compiler.  But
this requires improving Spad compiler...

> But a difference in interpreter and compiler is confusing.

Agreed.  OTOH I consider the above to be rather obscure
syntax corner.  Write clear code and there will be
agreement.

-- 
                              Waldek Hebisch
[email protected] 

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

Reply via email to