Gabriel Dos Reis wrote:
> 
> Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
> 
> | > 
> | > Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
> | > 
> | > [...]
> | > 
> | > | I would discourage using this form of macro definition -- it
> | > | just wastes potentially valuable syntax for trivial purpose.
> | > | AFAICS there are no uses of 'macro' in algebra.
> | > 
> | > For what it is worth, OpenAxiom leans in the opposite direction: the
> | > recommended style is 
> | > 
> | >      macro m == expr
> | > 
> | > over
> | > 
> | >     m ==> expr
> | > 
> | > hoping that in the future, ==> will be deprecated and removed.
> | > There is no grouping though.
> | 
> |  
> | Any reason for this choice?
> 
> The form
> 
>     macro m == expr
> 
> is already supported in all flavours of AXIOM, so there is no innovation
> here.

FYI, this form is only partially supported in FriCAS, it will fail
at toplevel.

> For me, trigraphs are much harder to visually parse than digraphs
> and prefix keywords, when reading programs.  When doing a code review, a
> change from a constant to a macro isn't easily lost.
> 
> | 'xx ==>' is used a lot in algebra
> | and is shorter than 'macro xx ==' so I would expect some strong
> | argument for such change.
> 
> I do not expect to change the algebra "by hand" for this.  It is a job
> for a tool.  For the argument about 'shortness' or 'conciseness', the
> constant definition notation 'xx == ' is even shorter and will do in
> almost all the cases.  If there is a situation that warrants an emphasis
> that something is a macro, I don't think that emphasis should be done
> just by appending one character; I would prefer it being -announced-
> upfront, e.g. prefixing with 'macro'.

OK, IIUC you propose 'xx == ' for trivial macros and 'macro xx =='
for more hairy ones.  More precisely, you say that most macros
may be replaced by constants.

I have serious problem with this proposal: 'xx == ' is used for
argumentless functions.  To distingish between macros (or constants
when properly supported) and such functions one needs to look at
type declarations.  But type declarations contain macros.  So we
get circular dependency between macro expansion (or constants) and
typechecking.  FriCAS removed most of this circularity (at cost
of hacky handling of '==' and ':' in toplevel 'where').  To
be more precise, FriCAS is doing first macroexpansion pass just
after parsing, then postTransform and parseTransform.  Remaing
macros (and typechecking) are handled in compiler proper.

Properly supporting constants is theoretically more elegant,
but I am not sure it is the best place to allocate developement
effort.

 
-- 
                              Waldek Hebisch
hebi...@math.uni.wroc.pl 

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel

Reply via email to