On Thu, 30 Nov 2006 00:44:17 +0200, Georg Wrede <georg.wrede@nospam.org> wrote:

>> The thing is that in the real world, most programmers need a standard, familiar dialect which has all the everyday high level tools available from the start. If OOP is an immediately useful concept, programmers should be using OOP from day one, not learning how to reinvent OOP from the basic building blocks. So, has anyone created widely-used standard librarys for high level programming?
>
>The very point of Common Lisp is *precicely* what you wrote here!
>
>CL tries to be a practical language for people doing real-world programming. (Sound familiar?) And they explcitly take distance to Scheme, which they consider more Purist, Academic, and for theoreticians. (The latter of course disagree, as usual.)

And this too may be a big clue to why me and Brad aren't making sense to each other.

I somehow had the impression that Common Lisp was created for standardisation reasons but at least as academic as any other dialect. Possibly I read some stuff by your theoreticians who disagree at some point.

Well, it's good to finally understand the nature of my ignorance - now I can do something about it!

-- 
Remove 'wants' and 'nospam' from e-mail.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:456E1768.7090504@nospam.org...

> If we had Perfect Metaprogramming(TM) in D, then I could do the following:
>
>   I'm coding some stuff and I notice that what I'd really want
>   is a new keyword, "unless", that would make it so much easier
>   for me to write this application clearly. I decide to create it.
>
>   I want to use it like this
>
>     unless (fullMoonTonight) { doRegularStuff() }
>
>   So, to create such a thing in D, I'd write something like
>
>     define("unless", "(", BooleanExpression, ")", BlockStatement)
>     {
>       if(!BooleanExpression) BlockSTatement;
>     }
>
> Now, if I'd made errors in writing the meta code, then the compiler would error me, of course. No biggie. And since the D compiler would understand what's going on (as opposed to the C preprosessor or compiler), the error messages would be what we're used to in D.
>
> Later, when I actually use the "unless" construct, again the error messages would be normal because D now understands what "unless" is all about.

Unfortunately, that then breaks the separation of the lexical/syntactic/semantic passes.  The define statements have to be syntaxed and semantic'ed before any other code can be even syntaxed.

One way around this would be to have some kind of "d metamodule" file which would define all the metacode.  Those metamodules would be compiled first, allowing the compiler to compile the normal D code.  Scary.

Georg Wrede wrote:
> renoX wrote:
>> Back on the subject of metaprogamming, one thing which makes me cautious about
>> metaprogramming is debugging: when there is a problem debugging generated code is
>> a nightmare usually..
> 
> It's not metaprogramming itself, it's the bad implementations that make it hard.
> 
> If we had Perfect Metaprogramming(TM) in D, then I could do the following:
> 
>   I'm coding some stuff and I notice that what I'd really want
>   is a new keyword, "unless", that would make it so much easier
>   for me to write this application clearly. I decide to create it.
> 
>   I want to use it like this
> 
>     unless (fullMoonTonight) { doRegularStuff() }
> 
>   So, to create such a thing in D, I'd write something like
> 
>     define("unless", "(", BooleanExpression, ")", BlockStatement)
>     {
>       if(!BooleanExpression) BlockSTatement;
>     }

What's wrong with

void unless(bool cond, lazy void delegate() blockstatement) {
   if (!cond) blockstatement();
}

?

Sure, you have to write

unless(fullMoonTonight, { doRegularStuff(); });

but if there was a way to have trailing delegates, you could have the exact syntax you wanted.

(The interaction between lazy parameters and template metaprogramming is a really interesting unexplored area. What can be achieved with tuples containing lazy code blocks???).

> ---
> 
> People say GC has to be slow, but that is mostly because it used to only exist in languages that were slow to begin with (and badly implemented).
> 
> The same thing with metaprogramming. C++ has given it such a bad rep, it'll take years before folks learn away from their fears.

Absolutely.

Don Clugston wrote:
> Georg Wrede wrote:
>> If we had Perfect Metaprogramming(TM) in D, then I could do the following:
> 
> What's wrong with
> 
> void unless(bool cond, lazy void delegate() blockstatement) {
>    if (!cond) blockstatement();
> }

What's wrong is that it's besides the point. :-)

Your solution is a good one, it works today, and looks uncomplicated. Of course, like you said, one has to get accustomed to a slightly unusual syntax. (Well, at least unusual for a simple conditional.) Which would of course be more hassle for the user than if(!fullMoonTonight){}, so the point gets lost.

But even that's beside the point. The point had already got derailed because I jumped to specifics too soon. ;-)

---

But it did bring up an interesting remark by Andrey about Nemerle. Got me thinking, some implementations of Lisp are compile-only (that is, they never interpret), and there probably are other compiled languages too (Don't know about Nemerle, gotta check it out some day), that support the kind of stuff that I did in the example.

So there should exist no a priori reason why it couldn't be done in D?

(Of course the mere proposition scares everybody gutless here, but I'm talking _technical_ reason. Compare also to my reply to Jarrett, right next to this post in this thread.)

Jarrett Billingsley wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:456E1768.7090504@nospam.org...
> 
> 
>>If we had Perfect Metaprogramming(TM) in D, then I could do the following:
>>
>>  I'm coding some stuff and I notice that what I'd really want
>>  is a new keyword, "unless", that would make it so much easier
>>  for me to write this application clearly. I decide to create it.
>>
>>  I want to use it like this
>>
>>    unless (fullMoonTonight) { doRegularStuff() }
>>
>>  So, to create such a thing in D, I'd write something like
>>
>>    define("unless", "(", BooleanExpression, ")", BlockStatement)
>>    {
>>      if(!BooleanExpression) BlockSTatement;
>>    }
>>
>>Now, if I'd made errors in writing the meta code, then the compiler would error me, of course. No biggie. And since the D compiler would understand what's going on (as opposed to the C preprosessor or compiler), the error messages would be what we're used to in D.
>>
>>Later, when I actually use the "unless" construct, again the error messages would be normal because D now understands what "unless" is all about.
> 
> Unfortunately, that then breaks the separation of the lexical/syntactic/semantic passes.  The define statements have to be syntaxed and semantic'ed before any other code can be even syntaxed.

Not necessarily.

If we wanted the metalanguage to let us do a hairy definition that, say, lets us use ][ as an operator, then yes, it breaks the separation.

But if we restrict ourselves to the kind of things done in the "unless" example, then there is no risk of this breakage.

You can think of it like this: had Walter wanted to implement "unless" last week in D, we'd have no problem today with the separation, right? So, if our metalanguage lets us do only things "Walter could have done without touching the parser", then this separation issue doesn't exist.

> One way around this would be to have some kind of "d metamodule" file which would define all the metacode.  Those metamodules would be compiled first, allowing the compiler to compile the normal D code.  Scary. 

It doesn't have to be scary. All it means is that some things (like "unless" above) are valid somewhere in the code, and not valid somewhere else. The word for that is scope. We do it currently with functions, and nobody complains.

So you could look at the meta definition like just an ordinary function definition. I honestly think that if we'd had this in D all along, folks would hardly notice.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:456EBAFF.10000@nospam.org...

> Not necessarily.
>
> If we wanted the metalanguage to let us do a hairy definition that, say, lets us use ][ as an operator, then yes, it breaks the separation.
>
> But if we restrict ourselves to the kind of things done in the "unless" example, then there is no risk of this breakage.

How so?  The 'define' statement would be a statement like anything else, which would not be recognized until the syntactic pass.  Since the 'unless' construct makes a construct that doesn't exist in the language, how would D know how to parse 'unless' statements unless it parses and semantics the 'define' statement first?

void foo(bool cond)
{
    unless(cond)
    {
        writefln("not cond");
    }
}

define("unless", "(", BooleanExpression, ")", BlockStatement)
{
    if(!BooleanExpression) BlockStatement;
}

When D does the semantic pass on this, it semantics 'foo' first, and so would fail to parse the 'unless' statement correctly.  Although, now that I think of it, D's semantic pass is split up, and the first pass only semantics the function signature and not the body, so in this case, the 'define' would be semantic'ed before foo's body, and it'd work.  So..  :)

Well there!  I made your job easier :)  Although I wonder if there'd be odd corner cases regarding things like templates.

> You can think of it like this: had Walter wanted to implement "unless" last week in D, we'd have no problem today with the separation, right? So, if our metalanguage lets us do only things "Walter could have done without touching the parser", then this separation issue doesn't exist.
>
>> One way around this would be to have some kind of "d metamodule" file which would define all the metacode.  Those metamodules would be compiled first, allowing the compiler to compile the normal D code.  Scary.
>
> It doesn't have to be scary. All it means is that some things (like "unless" above) are valid somewhere in the code, and not valid somewhere else. The word for that is scope. We do it currently with functions, and nobody complains.
>
> So you could look at the meta definition like just an ordinary function definition. I honestly think that if we'd had this in D all along, folks would hardly notice.

Jarrett Billingsley wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:456EBAFF.10000@nospam.org...
> 
>>Not necessarily.
>>
>>If we wanted the metalanguage to let us do a hairy definition that, say, lets us use ][ as an operator, then yes, it breaks the separation.
>>
>>But if we restrict ourselves to the kind of things done in the "unless" example, then there is no risk of this breakage.
> 
> How so?  The 'define' statement would be a statement like anything else, which would not be recognized until the syntactic pass.  Since the 'unless' construct makes a construct that doesn't exist in the language, how would D know how to parse 'unless' statements unless it parses and semantics the 'define' statement first?
> 
> void foo(bool cond)
> {
>     unless(cond)
>     {
>         writefln("not cond");
>     }
> }
> 
> define("unless", "(", BooleanExpression, ")", BlockStatement)
> {
>     if(!BooleanExpression) BlockStatement;
> }
> 
> When D does the semantic pass on this, it semantics 'foo' first, and so would fail to parse the 'unless' statement correctly.  Although, now that I think of it, D's semantic pass is split up, and the first pass only semantics the function signature and not the body, so in this case, the 'define' would be semantic'ed before foo's body, and it'd work.  So..  :)

Whew!

> Well there!  I made your job easier :)  Although I wonder if there'd be odd corner cases regarding things like templates.

Today you can define a function and instantiate it within a template body, and you can instantiate that template within another function body. So far, I see no fundamental reason why meta-definitions should be any different.

>>You can think of it like this: had Walter wanted to implement "unless" last week in D, we'd have no problem today with the separation, right? So, if our metalanguage lets us do only things "Walter could have done without touching the parser", then this separation issue doesn't exist.
>>
>>
>>>One way around this would be to have some kind of "d metamodule" file which would define all the metacode.  Those metamodules would be compiled first, allowing the compiler to compile the normal D code.  Scary.
>>
>>It doesn't have to be scary. All it means is that some things (like "unless" above) are valid somewhere in the code, and not valid somewhere else. The word for that is scope. We do it currently with functions, and nobody complains.
>>
>>So you could look at the meta definition like just an ordinary function definition. I honestly think that if we'd had this in D all along, folks would hardly notice. 
> 
> 
>