Gabriel Dos Reis wrote:
> 
> Waldek Hebisch <[email protected]> writes:
> 
> | This is reasonable choice if you _have to_ give meaning to '=='
> | in such cases. 
> 
> Indeed, all flavours of AXIOM support the following style
> 
>    SomeFunctor(): Public == Private where
>      Public == some category expression
>      Private == some domain expression
> 
> I am unconvinced of the value of requiring that to be written as
> 
>    SomeFunctor(): Public == Private where
>      Public ==> some category expression
>      Private ==> some domain expression

Well, inside toplevel 'where' FriCAS blindly converts '==' to '==>'
(because othere uses of '==' make no sense here).  But that is
clearly a hack.  IMHO normal constant definitions should be
typechecked.  But above we need to "expand" where to see what
type is defined (the 'some category expression' part).  Worse,
freqently we have things like:

SomeFunctor(A : CA, B : CB) : Public == Private where
    CA ==> cata
    CB ==> catb
    ...

that is even to get types of parameters we need to analyse 'where'.

Macros give clear semantics for such constructs, without
need need for special hacks.  I must admit that properly
giving types to 'Public', 'Private' above seems tricky,
given that both contains references to other parts of
algebra.  Probably some fixpoint definition with sufficiently
lazy implementation would do, but this is very far from
current implementation.  To say the truth, even with
macro expansion before typechecking, parameters of
constructors lead to "interesting" dependencies (current
compiler avoids the problem by not checking parameters
in definitions at all).

OTOH untyped treatment of 'Public == ...' is an irregularity
that I prefer to avoid.

> From my point of view, a macro is a `papering over some pesky imperfection'.

Well, that is my feeling of untyped use of '=='.

-- 
                              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.

Reply via email to