kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> kris wrote:
> [snip]
>>> So, "invariant" is already a keyword ... what about that?
>>>
>>> "Invariant" is currently used to stipulate a condition that must remain constant (or true) for the extent of the enclosing/relevant scope. Right now, it is used within a class only, but the semantics could presumably extend elsewhere too:
>>>
>>> invariant int * p = &x;
>>>
>>> void myFunc (invariant char[] arg) {}
>>>
>>> in both these cases, the "invariance" should remain for the extent of the relevant scope?
>>
>>
>> I completely missed that one. I think it's a good idea to look into it as a candidate for a qualifier name. Thank you.

Typically with invariants in CS the meaning is that "you can change all you want as long as you put things back the way you found them when you're done".  And that's definitely not the connotation desired here.

> If it gets tossed for whatever reason, It might be worthwhile renaming the current "invariant" to whatever is settled upon? That may reclaim a keyword at least.

Invariant can refer to an abstract property that doesn't change, like "full.length + empty.length == buffer.length".  The individual constituents of that expression can change all they want.  So calling it constant/readonly/immutable doesn't make as much sense as 'invariant'.

--bb

Bill Baxter wrote:
> Sean Kelly wrote:
>> Bill Baxter wrote:
>>>
>>> So you mean foreach(reverse) then?  I do like that!  You're right that it is quite D-like.  Too bad you weren't around back when foreach_reverse was introduced?   ;-)
>>
>> This actually came up in more general terms:
>>
>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=5015 
>>
>>
>> Perhaps I over-complicated it with the talk of parallelism, but the idea was still there :-)
> 
> You have it using foreach!(arg) syntax there.  But it's not really a template.  Maybe it could be, and if it were then that would be great syntax for it.  But otherwise it's just unprecendented.  A new special case.

The syntax isn't really important.  I was mostly looking for a way to avoid creating a new keyword while supporting multi-directional iteration.


Sean

On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright <newshound@digitalmars.com> wrote:

> eao197 wrote:
>> No, at first there must be 'D with macros' (like 'C with classes') and only then -- D++ :))
>
> D will get macros - but they won't be text processing macros, they'll be abstract syntax tree (AST) processing macros.

It is very interesting to hear that. Could you say more about the future macro system in D? Or it is a secret now?

> C++ programmers often try to use text macros to do syntax tree manipulation, but the result usually looks like one tried to use a belt buckle to drive screws.

Yes, I know. I have used C++ macros a lot in some cases.

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> eao197 wrote:
>>> No, at first there must be 'D with macros' (like 'C with classes') and only then -- D++ :))
>>
>> D will get macros - but they won't be text processing macros, they'll be abstract syntax tree (AST) processing macros.
> 
> It is very interesting to hear that. Could you say more about the future macro system in D? Or it is a secret now?

It's pretty simple:

	macro foo(args)
	{
		...syntax that gets inserted...
	}

and the args and syntax is evaluated in the context of the invocation of the macro, not the definition of the macro. You'll be able to do things like:

	macro print(arg)
	{
		writefln(__FILE__, __LINE__, arg);
	}

which get the file and line in the right context. There's no way to do that right now.

Funny, this is beginning to read like dialogue from Sam & Max: Episode 1...

Daniel Keep wrote:
> Walter Bright wrote:
>> eao197 wrote:
>>> On Sat, 17 Mar 2007 01:41:54 +0300, Walter Bright <newshound@digitalmars.com> wrote:
>>>> D will get macros - but they won't be text processing macros, they'll be abstract syntax tree (AST) processing macros.

Bosco: And I might have another item of interest behind the counter...

>>> It is very interesting to hear that. Could you say more about the future macro system in D? Or it is a secret now?

Sam: I accept your thinly veiled invitation to ask about the item behind the counter.

>> It's pretty simple:
>> 
>>     macro foo(args)
>>     {
>>         ...syntax that gets inserted...
>>     }

Bosco: Oh, it's a little something I like to call a Tear Gas Grenade Launcher.

> Oh, VERY slick.

Max: "Tear Gas Grenade Launcher?"  Oh, I *really* want that!

>> and the args and syntax is evaluated in the context of the invocation of the macro, not the definition of the macro. You'll be able to do things like:
>> 
>>     macro print(arg)
>>     {
>>         writefln(__FILE__, __LINE__, arg);
>>     }
>> 
>> which get the file and line in the right context. There's no way to do that right now.

Bosco: It'll clear out a room full of militant college students in no time; guaranteed!

> Wow.  <3

Max: I feel really close to you right now.

:P

Question: in terms of usage, will these macros be like functions?  Or will we able to define, say, a new kind of control structure with keywords?  Or perhaps even a construct with a trailing curly brace block?

You spoil us Walter, you really do.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> Question: in terms of usage, will these macros be like functions?

Yes. No !( ) syntax.

> Or
> will we able to define, say, a new kind of control structure with
> keywords?

No. Abner Hale thwacks such things with "abomination!"

>  Or perhaps even a construct with a trailing curly brace block?

Yes.

> You spoil us Walter, you really do.

macros should be the final piece needed to make DSL's work nicely, and they are actually rather simple conceptually and implementation-wise. I tried for a long time to figure out how to make templates do the work, until I finally realized that AST macros are *fundamentally different* from templates.

A nice side benefit to macros is we should be able to deprecate lazy.

On Fri, 16 Mar 2007 15:54:26 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> Given ...
>> 
>>    int[int**][]*[char[]][3][17][3,17]* x;
>> 
>> and I want to make the 'x' immutable and the 'char[]' immutable, how does one write the declaration? Where does one place the 'final'/'const'/'super const' and where do the parenthesis go?
> 
> final int[int**][]*[ const(char[]) ][3][17][3,17]* x;

Are you serious????

I want 'x' to be immutable so I need to use 'final' and place it the furtherest away from what is is qualifying.

I want 'char[]' to be immutable so I must use 'const' and place it next to what it is qualifying plus use parenthesis around its target too.

Why do you think that this is intuitive, consistent, and easy to read?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Walter Bright wrote:

> It's pretty simple:
> 
> macro foo(args)
> {
> ...syntax that gets inserted...
> }
> 
> and the args and syntax is evaluated in the context of the invocation of the macro, not the definition of the macro. You'll be able to do things like:
> 
> macro print(arg)
> {
> writefln(__FILE__, __LINE__, arg);
> }
> 
> which get the file and line in the right context. There's no way to do that right now.

And what about mixin templates? Couldn't they just be fixed to do this work?

From docs:
" Unlike a template instantiation, a template mixin's body is evaluated
within the scope where the mixin appears, not where the template
declaration is defined. It is analogous to cutting and pasting the body of
the template into the location of the mixin. It is useful for injecting
parameterized 'boilerplate' code, as well as for creating templated nested
functions, which is not possible with template instantiations. "

For me it looks exactly like this what you want to do with macro.

What would be a difference?

For me it seems that the whole mixin thing is rather buggy and unusfull at the moment - for reference see: http://www.digitalmars.com/d/archives/digitalmars/D/learn/3412.html#N3416


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

Derek Parnell wrote:
> On Fri, 16 Mar 2007 15:54:26 -0700, Walter Bright wrote:
>> Derek Parnell wrote:
>>> Given ...
>>> 
>>> int[int**][]*[char[]][3][17][3,17]* x;
>>> 
>>> and I want to make the 'x' immutable and the 'char[]' immutable, how does
>>>  one write the declaration? Where does one place the
>>> 'final'/'const'/'super const' and where do the parenthesis go?
>> final int[int**][]*[ const(char[]) ][3][17][3,17]* x;
> 
> Are you serious????
> 
> I want 'x' to be immutable so I need to use 'final' and place it the furtherest away from what is is qualifying.
> 

Or you want it to be static:

static int[int**][]*[char[]][3][17][3,17]* x;

Or you want it to be private:

private int[int**][]*[char[]][3][17][3,17]* x;

Or deprecated:

deprecated int[int**][]*[char[]][3][17][3,17]* x;

In all cases, you place the attribute the furthest away from what it qualifies. It's quite standard in C-family languages, including D, as I'm sure you know. I don't see why "final"/"const"/"super const" should be any different.

> I want 'char[]' to be immutable so I must use 'const' and place it next to what it is qualifying plus use parenthesis around its target too.

You need it within the same "scope" as the char[]: inside the [] where the char[] is.

> Why do you think that this is intuitive, consistent, and easy to read?

What makes you think anything to do with a 35-character type is intuitive or easy to read? ;-)

It's consistent enough for me.

-- 
Remove ".doesnotlike.spam" from the mail address.

Walter Bright wrote:
> 
> macros should be the final piece needed to make DSL's work nicely, and they are actually rather simple conceptually and implementation-wise. I tried for a long time to figure out how to make templates do the work, until I finally realized that AST macros are *fundamentally different* from templates.

Yup.  It sounds like the implementation will really be quite like the new mixin feature wrapped in some syntactic sugar.  Oddly, I'm actually looking forward to this.  There have been a few instances where I actually needed macros... some being cases where I wanted to define a local template function (which is illegal), and others for more bizarre uses.

> A nice side benefit to macros is we should be able to deprecate lazy.

I actually like 'lazy' for a narrow range of uses.  It makes creating an optimal debug logger exceedingly simple, for example.  Compared to all the evil tricks Matthew needed for Pantheios, 'lazy' has a clear and measurable benefit.  But if the same thing could be accomplished using macros then so much the better.


Sean