Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
| 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.
OK.
| > 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.
essentially, yes.
| 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.
Ah, yes, there is that weirdness in the old parser (but not in the
interpreter) that
xx == some expression
is implictily turned (at the postparse phase) into
xx() == some expression
I should point out that OpenAxiom made a cleanup in the parser and
compiler; that is no longer the case so a constant is properly
distinguished from a nullary function already at the parsing stage.
| 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.
I am not sure we get actual circularity. I believe that for
`where'-expressions, we compile the body of the expression in the scope
of the side definitions/declarations.
| 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.
I (pain)fully appreciate scarce resource allocation :-)
What I describe above is what I implemented in OpenAxiom some time ago
(last year.)
-- Gaby
------------------------------------------------------------------------------
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
