Jason House Wrote:
> How is that different from a normal function definition that includes some
> compile-time calls? I agree that compile-time code should look and feel like
> normal code. It seems you use macro to switch to compile-time by default and
> runtime when explcitly marked? Having both defaults (compile time or run
> time) makes sense.
>
The way it's implemented in Nemerle, a macro is actually a class.
the above is not how it works.
the code inside a macro is regular run-time code. it is compiled into a lib and
loaded by the compiler as a plugin.
the code is run at run-time but run-time here means run-time of the compiler
since it's a plugin of the compiler.
in nemerle (like in FP) the last value in a function is what the function
returns. so that macro *returns* an AST representation of what's inside.
you can use this operator to de/compose AST.
>
>
> > one important design goal is to clearly separate the stages, so this
> > will go to a separate .d file and will be compiled into a lib.
> > to use this macro you simply specify
> > compiler --load-macro=myMacro sources.d
> >
> > in user code you just use "print();"
>
> I disagree with this. The code that uses the macros should declare what it
> uses.
I meant from a syntax POV - calling a macro is the same as calling a function.
no template syntax. importing the namespace is still required IIRC.
>
>
> >
> > OK, here's an example:
> >
> > class Foo {
> > int a;
> > void bar();
> > }
> >
> > auto obj = new Foo;
> > obj.a = 42; // obj contains a
> > obj.bar(); // calls 'Foo.vtbl.bar
> >
> > remember that 'Foo is the classinfo singelton for Foo
> >
> > class Foo {
> > static a;
> > static void bar();
> > }
> >
> > Foo.a = 42; // 'Foo contains a
> > Foo.bar(); // calls ''Foo.vtbl.bar
> >
> > ''Foo is the classinfo singelton for 'Foo
> >
> > we get the following chain ("-->" means instance of)
> > obj --> Foo --> MetaFoo --> MetaClass --> Class
> >
> > compared with C++/D/Java/etc:
> > obj --> Foo --> Class
>
> Ok. That makes sense. It can be simplified when statics are removed.
>
I don't understand this. How removal of statics simplifies this?
I think that having class shared functions/data should still be possible but
implemented as above instead of static memory as in c++/D.
class Foo {
static int value;
}
this still works as in D but value is a member of the singleton object that
represents Foo at runtime instead of stored in static memory.
those singletons need to be concurrency friendly unlike the static memory
design that is definitely is not.
btw, in dynamic languages like smalltalk/ruby those meta classes are mutable so
you can for example add methods at run-time. I don't know if this should be
allowed in a compiled language.
