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.
(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 $.
There are lots of places where we have
foo(...)$List Integer
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.
Making it necessary to write
foo(..)$List(Integer)
or
(foo$List(Integer))(...)
(i.e. to require parentheses) would be OK for me, since
foo$Foo(x)(y)
could mean the function foo from Domain Foo(x)(y) (and I think it should
mean that).
It's also OK if
foo$Foo(x) y
means (foo$Foo(x))(y), i.e. $ binds stronger than juxtaposition but less
strong than (). In fact, that seems even reasonable.
But a difference in interpreter and compiler is confusing.
Ralf
--
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.
