[nem-en] Scala: what you say about it?

Kamil Skalski kamil.skalski at gmail.com
Sun Nov 19 00:48:51 CET 2006


For me this is just a proof that macro capabilities are a needed
feature for modern languages. It is just a matter of time when some
(probably limited) form of them will be getting into more and more
languages, also those branded by *big* companies.

As for the mail, I don't quite understand what does he mean by
"Instead of adding explicit macros as a specialized
code-transformation abstraction". In Nemerle code is also just a
value, which can be built programatically and decomposed by pattern
matching. Moreover, it is not some special value with type recognized
by compiler, it is just a plain set of classes. We can (and we do)
have libraries generating or analyzing some code chunks.
Macros are only the mechanism to RUN these code transformations and
place result into program.

The only major difference I can see between his proposal and our
macros is that he proposes run-time macros executed by interpretation
instead of compile-time macros. I can  only say that our experience
with macros is a very good basis for claiming that this is a BAD
choice, for several reasons:
- debugging, with compile-time macros you usually get a good feedback
from compiler before you even run the code. Ok, this can be done
Just-In-Time by compiling / interpreting code in runtime, but this is
more of a dynamic/static choice, where we definitely prefer static.
But what I cannot imagine to be easily done with runtime macros is
inspecting the results of all code transformations in their final form
- from time to time I use Reflector to look at my macro-generated code
and with the recently added feature of creating faked source for
macro-generated methods is should be even easier.
- performance - this is obvious that compiled macros are faster than
run-time macros
- usability of Nemerle macros in multi-language, large projects - in
my currently developed application I have a Nemerle library + some
macros and GUI client in C#. Now I can use macros to generate parts of
my library and then it becomes instantly usable by any other .NET
language, since the generated classes / methods are plain .NET
structures after the compile-time code transformation stage

Gilles Dubochet  mentions MetaML - the interesting thing to point here
is that MetaML / MetaOcaml, etc. are all statically typed and I mean
*strongly* statically typed - the code inside quotations is also
type-checked. This is of course very nice feature, but hm... honestly,
to do anything usable in such a setting you need to sweat a lot. The
theoretical foundations in this field are improving, but so far this
is just too limiting. Most of the macros I wrote and found nice are in
fact "dynamic" - it means that they build code in a very dynamic way,
just putting some parts of code generated by utility functions
together. Their result is then type-checked at use-site when somebody
calls the macro.
So, my observation is that if you want run-time code transformation
and execution it would be better to do strong type-checking, otherwise
the hard time debugging macros becomes even harder. But if you have
strong type-checking you cannot do anything useful with your macros..
:(  For me the dynamic macros + their compile-time execution is much
closer to the usability optimum in this field.

And to do not disappoint the run-time code transformation + execution
fans I can just say that this is of course also possible in Nemerle.
You can just build the code (from strings or using code quotations)
and evaluate it. See existing example in Nemerle tests:

http://nemerle.org/svn/nemerle/trunk/tools/nemerlish/tests/eval.n

The only thing I envy a little bit from Scala guys is the "fresh"
state ;)  I think there are many things we could have cleaner in our
macro system and starting the stuff from scratch has the best
potential (and hope) to make things well designed. But, as I am
thinking mainly about the compiler API design, not the general
concepts of our macro system, it still seems fixable in future for
Nemerle.

As to note, also F# (and Boo of course) incorporates macros these
days. And hey, every of those language mentions Nemerle as a language
to consider in their design. This is inspiring ;)

On 11/18/06, vc <vc at rsdn.ru> wrote:
> Scala: what you say about it?
>
> http://permalink.gmane.org/gmane.comp.lang.scala/2660
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


-- 
Kamil Skalski
http://nazgul.omega.pl



More information about the devel-en mailing list