Bill Page wrote:
>
> I have a similar "lack of respect" for macro usage. SPAD should
> consistently be a high level language. Macros belong (perhaps) at a
> lower level in Boot and in Lisp. If there is something that you think
> requires a macro in SPAD I would take that as a criticism of the
> language. It seems to me that even the use of the ... where clause
> should not encourage us to think in terms of macros but rather as a
> way of locally defining a context.
Look at DoubleFloatEllipticIntegrals and FloatEllipticFunctions,
both in special2.spad.pamphlet. The real and complex versions
are very similar. In DoubleFloat case we want to use fast
version of square root for real version (it leads to much faster
code) but regular square root for complex version. In Float
case we need to raise errors in real version for arguments that
are legal in complex version, OTOH complex version needs more
tricky handling of periods. So I have parts which are exactly
the same and parts that differ. I use macros to use single
definition for common part of code. In principle I could
create a common generic package for shared parts, but:
- code is not generic, there are just two versions (real and
complex)
- I prefer to keep code together (shared parts are strongly
related to no-shared ones)
- there is little gain in efficiency from using non-generic code.
Or look at 'addm!' in poly.spad.pamphlet. This routine is
performance critical -- speed of polynomial multiplication
(and conseqently of most our symbolic operations) depend on
it. There are two versions of code, one that uses machine
integers, the other general ones. Machine integers can
be used in most cases and this version is much faster than
the other one (using generic operations), but we want
correnctly handle general case. I use macro to
share most of body of 'addm!', so the versions just
differ in declarations and few operations which explicitely
involve types.
I do not think there is other way n Spad to have fast
specialized versions and share code...
Of course, for each specific use case one can find a
language feature which handles such case. But the point
is that macros form a simple and general mechanism.
I do not see way should we reject them when they
solve real problems.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
