I don't like the idea of separate syntax for the macro language.
I think it would be more convenient to have similar syntax to D
and special statements indicating macros.
For example something like this:

macro void test(int arg)
{
  printf("a = %d;\n", arg);
}

what do you think?
you then could write
"macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
just a thought... :)

Roland wrote:
> "Sean L. Palmer" a écrit :
> 
> 
>>All those ?? and # are really ugly as well... surely there would be a way to
>>do it without so many wierd symbols everywhere.
>>
> 
> 
> ok, I could have choosen a more appealing syntax.
> one problem is that i like a separate syntax for directive and statement.
> I'm just understanding it is not necessary if you have a good optimizer.
> now i understand why in this example (C++ sorry):
> 
> template <class T, int SIZE>
> class Toto {
>     int afunc() {
> //you write
>             if (SIZE==2) {
> //instead of
>             #if (SIZE==2) {
> //as it always seems logical to me
>                 .
>                 .
>             }
>     }
> };
> 
> 
> 
>>Listen, I can figure out your macros, I've written many assembler macros in
>>my time.  And I kinda like the idea of automatically-generated code.  But
>>your example is basically unreadable because of all the symbols.  I'm
>>actually more in favor of something like forced-inline functions combined
>>with generics, and language features that enable the generics to deal with
>>unknown types nicely, such as
>>
>>bool Foo(type T : IComparable tparm, type uparm) // whatever you pass for T
>>must be derived from IComparable; uparm can be anything
>>{
>>  typealias U = typeof(uparm);
>>  U ucopy = uparm; // declare new variable same type as uparm
>>  T tcopy = tparm;   // tparm's type was named in the declaration
>>
>>  // the following checks compile time constant properties of the type to
>>determine what kind of code to generate
>>  // blocks controlled by constant compile time false are never evaluated
>>sematically thus won't cause compile errors.
>>  printf("U is of type %s",U.name);
>>  if (U.isstruct)
>>  {
>>    printf("U is a struct\n");
>>    for (int i=0; i<U.numfields; ++i)
>>      printf("  U field #%d named %s is type %s\n", i, U.fields[i].name,
>>U.fields[i].type.name);
>>  }
>>  else if (U.isclass)
>>  {
>>    printf("U is a class derived from %s\n",U.type.ancestor);
>>  }
>>  else if (U.isarray)
>>  {
>>     printf("U is an array %d elements\n",uparm.size);
>>    for (int i=0; i<U.numfields; ++i)
>>      printf("  U element #%d is %s\n", i, uparm[i].tostring);
>>  }
>>  else if (U.isenum) printf("U is an enum %s\n",uparm.tostring);
>>  else if (U.isintegral) printf("U is a integral %l\n",long(uparm));
>>  else if (U.isreal) printf("U is a real %f\n",extended(uparm));
>>  else printf("dunno how to deal with type U\n");
>>
>>  assert(T.derivesfrom(IComparable)); // just to give a meaningful error
>>message; without the assert it still would fail to compile
>>
>>  return tcopy.CompareWith(ucopy); // type T must provide this function
>>overloaded for type U or a compile error will result during expansion.
>>}
>>
>>Since most of the stuff in there is known at compile time, quite a bit of
>>compile time optimization is possible.  And I'm sure people could come up
>>with more stuff that would enable even cooler tricks.
>>
>>Sean
>>
> 
> 
> you got the idea.
> now is it interesting enough to search for a syntax ?
> for me yes
> 
> roland
> 
> 
> 

So what, then, is the difference between a macro and an inlined function?

Sean

"Marius S." <mars@centras.lt> wrote in message news:3CC4A2FB.3000403@centras.lt...
> I don't like the idea of separate syntax for the macro language.
> I think it would be more convenient to have similar syntax to D
> and special statements indicating macros.
> For example something like this:
>
> macro void test(int arg)
> {
>    printf("a = %d;\n", arg);
> }
>
> what do you think?
> you then could write
> "macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
> just a thought... :)
>
> Roland wrote:

macro is compile-time function :)

Sean L. Palmer wrote:
> So what, then, is the difference between a macro and an inlined function?
> 
> Sean
> 
> "Marius S." <mars@centras.lt> wrote in message
> news:3CC4A2FB.3000403@centras.lt...
> 
>>I don't like the idea of separate syntax for the macro language.
>>I think it would be more convenient to have similar syntax to D
>>and special statements indicating macros.
>>For example something like this:
>>
>>macro void test(int arg)
>>{
>>   printf("a = %d;\n", arg);
>>}
>>
>>what do you think?
>>you then could write
>>"macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
>>just a thought... :)
>>

"Sean L. Palmer" a écrit :

> So what, then, is the difference between a macro and an inlined function?
>
> Sean
>
> "Marius S." <mars@centras.lt> wrote in message news:3CC4A2FB.3000403@centras.lt...
> > I don't like the idea of separate syntax for the macro language.
> > I think it would be more convenient to have similar syntax to D
> > and special statements indicating macros.
> > For example something like this:
> >
> > macro void test(int arg)
> > {
> >    printf("a = %d;\n", arg);
> > }
> >
> > what do you think?
> > you then could write
> > "macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
> > just a thought... :)
> >
> > Roland wrote:

right.
to be usefull, arg must not be typed:

macro void test(arg) {
    .
    .
}

so what is the difference with template function ?
none
exept that it could be parcical to have some more directives like symbole
name concatenation,
repeat statement directive, local symbole names, etc..

macro void opeq(dim,p,op,a) {
    int i;
   for (i=0; i<dim; i++) {    //dim is a constant. compiler may unfold the
loop
        p.coord#i op a;         //# concatenate symbols. p.coord0 op a;
p.coord1 op a...
    }
}

now what does it do ?
example:

void afunction(point3d& p; const int a) {
    .
    .
    opeq(3,p,-=,a);
    .
    .
}

expand like

void afunction(point3d& p; const int a) {
    .
    .
     p.coord0 -= a;
     p.coord1 -= a;
     p.coord2 -= a;
    .
    .
}

???????

personaly i made my mind: complex macros should be processed externally from
the compiler.
just i have to find a good preprocessor for that. any suggestions ?

roland

Roland wrote:
> 
> "Sean L. Palmer" a écrit :
> 
> 
>>So what, then, is the difference between a macro and an inlined function?
>>
>>Sean
>>
>>"Marius S." <mars@centras.lt> wrote in message
>>news:3CC4A2FB.3000403@centras.lt...
>>
>>>I don't like the idea of separate syntax for the macro language.
>>>I think it would be more convenient to have similar syntax to D
>>>and special statements indicating macros.
>>>For example something like this:
>>>
>>>macro void test(int arg)
>>>{
>>>   printf("a = %d;\n", arg);
>>>}
>>>
>>>what do you think?
>>>you then could write
>>>"macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
>>>just a thought... :)
>>>
>>>Roland wrote:
>>
> 
> right.
> to be usefull, arg must not be typed:
> 
> macro void test(arg) {
>     .
>     .
> }

I'd say arg coud be typed too and i think there should be some type which matches all types (like "var" in java script).

> so what is the difference with template function ?
> none
> exept that it could be parcical to have some more directives like symbole
> name concatenation,
> repeat statement directive, local symbole names, etc..
> 
> macro void opeq(dim,p,op,a) {
>     int i;
>    for (i=0; i<dim; i++) {    //dim is a constant. compiler may unfold the
> loop
>         p.coord#i op a;         //# concatenate symbols. p.coord0 op a;
> p.coord1 op a...
>     }
> }

It could be more powerfull (but maybe less right) if its output would be compiled, then you could generate more flexible source code with it :)
...like PHP in HTML... no, i think that's not right :) sorry.

> 
> now what does it do ?
> example:
> 
> void afunction(point3d& p; const int a) {
>     .
>     .
>     opeq(3,p,-=,a);
>     .
>     .
> }
> 
> expand like
> 
> void afunction(point3d& p; const int a) {
>     .
>     .
>      p.coord0 -= a;
>      p.coord1 -= a;
>      p.coord2 -= a;
>     .
>     .
> }
> 
> ???????
> 
> personaly i made my mind: complex macros should be processed externally from
> the compiler.
> just i have to find a good preprocessor for that. any suggestions ?
> 
> roland

"Marius S." <mars@centras.lt> wrote in message news:3CC51C12.8030902@centras.lt...
> macro is compile-time function :)

Preeee-cisely.  :-)

A macro is a function that is executed at compile time.  It has the program source code as an input stream, and output it writes is input to the compiler.  It intimate with the compiler's current context, so that it can discover variable and expression types, it can interrogate class and struct membership, and it can do, well, whatever else might be useful (read and write files; issue database queries; perform socket/Internet transactions).

> Sean L. Palmer wrote:
> > So what, then, is the difference between a macro and an inlined
function?
> >
> > Sean
> >
> > "Marius S." <mars@centras.lt> wrote in message news:3CC4A2FB.3000403@centras.lt...
> >
> >>I don't like the idea of separate syntax for the macro language.
> >>I think it would be more convenient to have similar syntax to D
> >>and special statements indicating macros.
> >>For example something like this:
> >>
> >>macro void test(int arg)
> >>{
> >>   printf("a = %d;\n", arg);
> >>}
> >>
> >>what do you think?
> >>you then could write
> >>"macro a" or "macro{ a b }" and maybe "macro: a" (like "public")
> >>just a thought... :)
> >>

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:aa3jr9$2pka$1@digitaldaemon.com...
> A macro is a function that is executed at compile time.  It has the
program
> source code as an input stream, and output it writes is input to the compiler.  It intimate with the compiler's current context, so that it can discover variable and expression types, it can interrogate class and
struct
> membership, and it can do, well, whatever else might be useful (read and write files; issue database queries; perform socket/Internet
transactions).

Macros are great, but they make it impractical to separate the tokenizing step from the semantic processing.

"Walter" <walter@digitalmars.com> wrote in message news:aa4svh$19ia$1@digitaldaemon.com...
>
> "Richard Krehbiel" <rich@kastle.com> wrote in message news:aa3jr9$2pka$1@digitaldaemon.com...
> > A macro is a function that is executed at compile time.  It has the
> program
> > source code as an input stream, and output it writes is input to the compiler.  It intimate with the compiler's current context, so that it
can
> > discover variable and expression types, it can interrogate class and
> struct
> > membership, and it can do, well, whatever else might be useful (read and write files; issue database queries; perform socket/Internet
> transactions).
>
> Macros are great, but they make it impractical to separate the tokenizing step from the semantic processing.

Um... why is this important?

Here's my understanding of compiler phases: Once upon a time, when 4K machines were being asked to compile FORTRAN, it was crucial to be able to separate lexical analysis from syntactic, syntactic from semantic, semantic from optimization, optimization from assembly, etc so that the individual phases could fit into core, and each phase would forward their results to the next phase in intermediate files.

No longer.  Today's compiler does everything but linking in one step, and everything fits in memory (and if not in real memory, then virtual).

So what if it's not easy to make a token stream from your input source?  I'm afraid I don't get it.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

Richard Krehbiel wrote:

> Um... why is this important?
>
> Here's my understanding of compiler phases: Once upon a time, when 4K machines were being asked to compile FORTRAN, it was crucial to be able to separate lexical analysis from syntactic, syntactic from semantic, semantic from optimization, optimization from assembly, etc so that the individual phases could fit into core, and each phase would forward their results to the next phase in intermediate files.
>
> No longer.  Today's compiler does everything but linking in one step, and everything fits in memory (and if not in real memory, then virtual).

Maybe 15 years (?) ago, the first single-pass compiler (Turbo C?) came out, and the point of doing it all in one pass was to increase performance.  However, any time that you tightly integrate two very different parts of the code (i.e. token parsing with semantic analysis, or semantic analysis with compilation), you make things more complex and harder to debug.

That means that compilers are harder to write, harder to "prove correct," and therefore more likely to have subtle errors.  Errors in compilers, or having a wide variety of compilers with differing levels of support for various features, is a Bad Thing.

One of D's stated objectives is to make it easy to write a correct compiler that implements all of the features.  By keeping the phases separate, this is much easier to do.

Similarly, it allows people to write tools to view, debug, or perhaps even
rearrange D code without having to parse all of the import files to find odd
macros.  Thus, you can bet that
    MY_THING *[]*foo;
is the declaration of a variable called foo, and that MY_THING is a user type
declared elsewhere - you don't have to parse for macros and find out that
MY_THING is some weird alternate expansion.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CC6DFC0.F01424E6@deming-os.org...
> Richard Krehbiel wrote:
>
> > Um... why is this important?
> >
> [ ... ]
> Similarly, it allows people to write tools to view, debug, or perhaps even
> rearrange D code without having to parse all of the import files to find
odd
> macros.  Thus, you can bet that
>     MY_THING *[]*foo;
> is the declaration of a variable called foo, and that MY_THING is a user
type
> declared elsewhere - you don't have to parse for macros and find out that MY_THING is some weird alternate expansion.

Oh, I think I get it.  The simpler a language is to parse, the more IDE-able it is.

I'm thinking of the Visual Studio IDE, where you type along:

   struct a { int z; double y; } var;
   var.

...and upon typing the "." the editor gives you a pop-up to choose among the struct members.  The editor has interpreted the struct definition in real time.

A package of fancy macros could certainly defeat that.  Indeed, the simple macros of CPP defeat Visual Studio's editor quite handily.

So a language with powerful macros would need a more powerful IDE.  (And here was I, wondering what use is a 2.4GHz processor to a plain text editor - why, it's running a full compile behind every keystroke...)

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)