Yigal Chripun Wrote:

> 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.


Your examples in Nemerle or D-ish looked like they are returning strings. I'm still not seeing the magic of AST macros.



> > 

> > > 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?

As I understood it 'Foo contains the static data and class info for Foo, and ''Foo contains class info for 'Foo. Without statics, ''Foo is unnecessary. I'm sure I've misinterpreted what you're saying ;)


> 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.

The singleton object should be in static memory... I don't really see the distinction since the finer storage details don't affect the programmer.

> 
> 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.

On 26/10/2009 20:30, Jason House wrote:
>
> Your examples in Nemerle or D-ish looked like they are returning
> strings. I'm still not seeing the magic of AST macros.

When we want to decompose some large code (or more precisely, its syntax
tree), we must bind its smaller parts to variables. Then we can process
them recursively or just use them in an arbitrary way to construct the
result.

We can operate on entire subexpressions by writing $( ... ) or $ID
inside the quotation operator <[ ... ]>. This means binding the value of
ID or the interior of parenthesized expression to the part of syntax
tree described by corresponding quotation.

macro for (init, cond, change, body)
{
  <[
    $init;
    def loop () : void {
      if ($cond) { $body; $change; loop() }
      else ()
    };
    loop ()
  ]>
}


he above macro defines function for, which is similar to the loop known
from C. It can be used like this

for (mutable i = 0, i < 10, i++, printf ("%d", i))
/quote

the above is taken from the macros_tutorial page of nemerle.org.
unfortunately the site is down so I'm using Google's cache instead.

there are a few more related topics: Constructs with variable number of
elements, hygiene, ...

Hello Denis,


> I believe templates are better be written in imperative style. That's
> why  a built-in "type" type is needed.

The problem there is that real template (that, at compile time, generate a difference instance per type) are fundamentally declarative rather than imperative. What might work best is having template be declarative but provide powerful enough compile time imperative constructs that make functional programing (e.g. C++ style meta programming) more or less pointless.

The thought is that rather than mix compile time and runtime imperative construct the template can /declare/ "there is a ___" but can access pure compile time constructs to do whatever processing/computation is needed.