On 12/22/25 02:14, Waldek Hebisch wrote:
On Mon, Dec 22, 2025 at 12:38:08AM +0100, 'Ralf Hemmecke' via FriCAS - computer
algebra system wrote:
IIRC this sometimes works, but not always.
Oh... good to know. Up to now I haven't run into trouble.
I actually want even something like
mac(A,B)(x,y) ==> ...
First step, very important for such things, is to define what it
should do, what is considered correct and what should signal
error.
Well, I basically (and maybe naively) think that it should behave like a
function that returns a function that is then applied to (x,y), only
that it is not a SPAD function, but a macro function.
When evaluating an expression first step should be to check
if it is an application of macro function to arguments. This
may require evaluating first part of an expression to get possible
value from nested macro expansions. If given expression is
an application of macro function to arguments, and number of
arguments matches we should apply macro, that is substitute
arguments into right hand side of macro definition. I assume
here that
mac(A,B)(x,y) ==>
really define macro function named 'mac' which after substituting
arguments for A and B gives new anonymous macro function which
can be applied to two arguments.
Exactly. That would be in line with the notations of functions returning
function in SPAD. I would **not** want that mac(A,B) is first expanded
and then the result is applied to (x,y). If I wanted that, I can simply
write
foo(x,y) ==...
mac2(A,B) ==> foo
where foo is a function (or a macro). But in the situation I want it,
I seem to need to consider mac as a function returning a function.
mac(A,x)(B,y) ==> fun(x,y) $ Foo(A,B)
Now, what shall we do if number of arguments do not match.
Well, abort with an error. The problem is that in the example I sent,
the number of arguments was correct, but I still got an error.
AFAICS currently we signal error so we probably should do
so. Related thing is what to do when we want to evaluate
something, but we get just a macro function, it seems that
we should also signal error in such a case. Do this match
what you would like to use?
Probably. I was actually only "complaining" about a situation where the
number of arguments was correct, but I still got an error. I did not
thing too much about what the consequences for the macro expansion
mechanisms were. An error in problematic cases is fine for me, but not
in cases where there is none.
Now, considering possible uses, current Spad compiler assumes
that it can use almost as-is types appearing in 'with' part,
which means that we need to expand types. This is not a
trouble for regular compilation, but needs changes to
algebra bootstrap. This does not look very hard, but
I need to think how to do this without future maintanence
troubles.
Hmmmm... up to now I was thinking that macro expansions happens before
the actual compiler sees the (expanded) source code. I expect the macro
expansion producing proper SPAD code. Otherwise it should be counted as
an error. And I would also count it as an error if an exansion has left
an anonymous macro function that was not applied to something. That
means, if I define
mygcd(D)(x,y) ==> gcd(x,y) $ D
and I use it in code as
foo(mygcd(D), x,y)
where the function foo is defined as
foo(f, x, y) == f(x,y)
I would perfectly be fine if these cases lead to an error, since
I should rather have defined the macro in a simpler form like
mygcd(D) ==> gcd $ D
I hope that makes somehow sense.
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 view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/751274b8-ebde-479f-9511-2ccf76ddf1fd%40hemmecke.org.
