On 17/05/2011, at 3:25 AM, Paul Stansifer wrote:
>
> > - Powerful macros that cover the "needs to be efficient" cases as well
> > as the various other macro scenarios. Definitely front-end!
>
> I do not understand the need for macros. Could someone explain?
> If you have polymorphic functions you basically don't need macros.
> But perhaps I misunderstand what a macro is in Rust.
>
> Scheme has a very powerful macro system and it doesn't even have static
> types. Macros abstract over whatever second-class features a language has. In
> a non-polymorphic language, this includes types, but even the lambda calculus
> has a second-class feature: binding. If you want to create a new kind of
> 'let' or 'case' or 'lambda' construct (and Scheme people love doing that kind
> of thing), you need macros. The surface syntax of the language is also
> second-class, so macros can provide nicer surface syntaxes (for things like
> printf and regexpes, for example). Macros are ideal for embedding
> domain-specific languages.
No they're not. They're the hack you use when you don't have higher order
polymorphism.
They definitely not "ideal".
Just to be clear, I think of macros as "without proper typing and kinding" and
in addition "operate by replacement, not programmatically".
The first feature is used because the system doesn't have a good enough
type/kinding system as a band aid; it is better than bleeding to death,
but not as good a proper dressing :)
The second feature is the main problem. Code generators, that is,
actual code which generates code, is MUCH better than macros
because the replacement rules for macros so that everything remains
fairly nice and predictable just can't be formed. The obvious problem
is quotation, and when you're nesting stuff the need to quote quotes to
multiple levels and escape them. This problem doesn't exist at all in
a programatic code generator.
In Felix I had macros (very powerful) and also the build system was written
in Python so I could easily write Python script to "print out" code.
I tried to get rid of the Python script and put what it did into the language
directly with macros, but this proved to be extremely hard to do because
of the quoting problem. Macros lack transparency in the sense you have
to change the arguments to macro calls to match the implementation,
which you never need to do when you're generating code with a real
programming language (like Python).
[I actually got rid of most of the code generation and macro stuff with
a "proper feature": type classes. The syntax hackery was got rid of with
an extensible GLR parser that with user defined grammar and
parser actions (AST generating code) written in Scheme]
Basically, macros in any form are the poor mans code generator
which don't work so well but seem easy to use because they fit into
the existing syntax. The right way is to have proper high order
"code generating" constructions, but this is hard.
>
> Macros could be used to create what are effectively inline functions, but if
> that's all the macro does, I'm really uncomfortable with the thought, because
> we don't want to encourage that kind of behavior. I have this terrible vision
> of programmers saying "Oh, use macros instead of functions, they're faster.",
> and then writing code that is (a) terrible, since it uses macros as if they
> were functions, and (b) slow, since the huge hunks of code produced don't fit
> in the instruction cache.
Agreed, and a good example. Directly from experience with C no doubt :)
Note in C++ need for macros for this purpose was removed by inline functions.
And for the hacked up polymorphism macros provide in C:
# define addmul(a,b,c) a + b * c
C++ provided templates which re-enabled proper type checking.
My point above is that these macros uses always represent a hack to do something
that should be properly supported. My view is: if you have an example where you
think you need macros, try to fix the language so you don't.
Its actually "useful" to have macros for this reason: provide them because you
can't
solve all problems in the first release of the language, and then use client's
actual
use cases as a way to drive getting rid of that usage with proper constructions.
BTW: I'm not against putting macros in for this reason.
--
john skaller
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
