> Your attachment is zero-byte.
> 

Oops... Try this one..

cr*p, I've pasted too little. Try this one instead..

I'll use a proper diff tool next time..

Nick Sabalausky wrote:
> "Lionello Lunesu" <lio@lunesu.remove.com> wrote in message news:gpc4j3$30a0$2@digitalmars.com...
>> Oops, sorry, I didn't notice this was the .learn newsgroup. I guess a patch to the DMD source was not really what you expected. I just got so anxious!
>>
>> L.
> 
> Hey, solutions are solutions :)  In fact I may very well try that out. I'm not particularly keen on using an ugly mixin to declare all my enums just so that I can use a simple reflection feature like that (which I'd mostly just be using for debugging info anyway).
> 

I'm really glad it's so easy to hack stuff into the compiler. Although I'm still strugling to get these new "string expression" to evaluate at compile time. The enum.tupleof is done at compile time, the foreach as well, but I cannot pragma(msg) the values, nor can they be mixin-ed.. Must be some constness flag somewhere?

L.

Reply to Lionello,

> cr*p, I've pasted too little. Try this one instead..
> 
> I'll use a proper diff tool next time..
> 

you client is messing with you, paste-bin the sucker or add it to a bugzilla item

//src\dmd\mtype.c, line 5025 (in TypeEnum::dotExp, after the #endif):

/* If e.tupleof
 */
if (ident == Id::tupleof)
{
	/* Create a TupleExp out of the fields of the struct e:
	 * (e.field0, e.field1, e.field2, ...)
	 */
	e = e->semantic(sc);	// do this before turning on noaccesscheck
	Expressions *exps = new Expressions;
	exps->reserve(sym->members->dim);
	for (size_t i = 0; i < sym->members->dim; i++)
	{
		EnumMember *em = ((Dsymbol *)sym->members->data[i])->isEnumMember();
		char* s = em->ident->toChars();
		Expression *fe = new StringExp(e->loc, s, strlen(s), 'c');
		exps->push(fe);
	}
	e = new TupleExp(e->loc, exps);
	Scope sss;
	e = e->semantic(&sss);
	return e;
}

On Thu, 12 Mar 2009, BCS wrote:

> Reply to Lionello,
> 
> > cr*p, I've pasted too little. Try this one instead..
> > 
> > I'll use a proper diff tool next time..
> > 
> 
> you client is messing with you, paste-bin the sucker or add it to a bugzilla item

Just to be sure the two don't get combined (I know you didn't say to do both, just making sure), please don't paste-bin stuff for bug reports. Either put it directly in a comment or attach it as a patch.  While paste-bin's aren't super ephemeral, there's no good reason to have thing disconnected from the bug like that.

That said, I don't think this really helps the desired usecase much.  It's useful, don't get me wrong, but still requires code to build up the bi-directional translations.  Or am I missing something?  Seems to be happening to me a lot lately, so I'm very prepared to be wrong here too. :)

Later,
Brad

"Brad Roberts" <braddr@bellevue.puremagic.com> wrote in message news:alpine.DEB.2.00.0903121755240.4513@bellevue.puremagic.com...
> That said, I don't think this really helps the desired usecase much.  It's
> useful, don't get me wrong, but still requires code to build up the
> bi-directional translations.  Or am I missing something?  Seems to be
> happening to me a lot lately, so I'm very prepared to be wrong here too.
> :)


You're not wrong :)
The problem is that the foreach variable is not evaluatable to a compile-time string. I don't know why, but I'll figure it out tonight.

I've also managed to convert an enum to an AssocArrayLiteralExp* (with the name/string as the key and the value/int as the value) but it seems that it cannot be foreached at compile time, even if it's a literal expression. But hell, I've spent about 1 hour browsing through dmd's code, so I'm pretty sure it's possible with a little more research.

I want to get either one to work at compile-time. In the case of TupleExp, one could then use a string mixin to convert the string to a value.

L.

* I don't have the AA patch handy (I'm at work) but it's a good exercise: start with my original tupleof patch but create an AssocArrayLiteralExp instead of the TupleExp. You'll need two Expressions arrays, one for keys and one for values. EnumMember::ident is the name, EnumMember::value is the value expression. Pretty straightforward.

Lionello Lunesu wrote:
> 
> "Brad Roberts" <braddr@bellevue.puremagic.com> wrote in message news:alpine.DEB.2.00.0903121755240.4513@bellevue.puremagic.com...
>> That said, I don't think this really helps the desired usecase much.  It's
>> useful, don't get me wrong, but still requires code to build up the
>> bi-directional translations.  Or am I missing something?  Seems to be
>> happening to me a lot lately, so I'm very prepared to be wrong here too.
>> :)
> 
> 
> You're not wrong :)
> The problem is that the foreach variable is not evaluatable to a compile-time string. I don't know why, but I'll figure it out tonight.
> 
> I've also managed to convert an enum to an AssocArrayLiteralExp* (with the name/string as the key and the value/int as the value) but it seems that it cannot be foreached at compile time, even if it's a literal expression. But hell, I've spent about 1 hour browsing through dmd's code, so I'm pretty sure it's possible with a little more research.

Can you foreach at compile-time? I thought you could only do that in CTFE (or templates?). Maybe that's why it's not working. How do you do it to pragma msg the members of a struct?

I remember someone proposed "static foreach" some time ago...

Ary Borenszweig wrote:
> Lionello Lunesu wrote:
>>
>> "Brad Roberts" <braddr@bellevue.puremagic.com> wrote in message news:alpine.DEB.2.00.0903121755240.4513@bellevue.puremagic.com...
>>> That said, I don't think this really helps the desired usecase much.
>>> It's
>>> useful, don't get me wrong, but still requires code to build up the
>>> bi-directional translations.  Or am I missing something?  Seems to be
>>> happening to me a lot lately, so I'm very prepared to be wrong here too.
>>> :)
>>
>>
>> You're not wrong :)
>> The problem is that the foreach variable is not evaluatable to a
>> compile-time string. I don't know why, but I'll figure it out tonight.
>>
>> I've also managed to convert an enum to an AssocArrayLiteralExp* (with
>> the name/string as the key and the value/int as the value) but it
>> seems that it cannot be foreached at compile time, even if it's a
>> literal expression. But hell, I've spent about 1 hour browsing through
>> dmd's code, so I'm pretty sure it's possible with a little more research.
> 
> Can you foreach at compile-time? I thought you could only do that in CTFE (or templates?). Maybe that's why it's not working. How do you do it to pragma msg the members of a struct?
> 
> I remember someone proposed "static foreach" some time ago...

We have a sort-of static foreach.  The trick is that the aggregate HAS to be a tuple.  When in doubt, you can always fall back on the following construct:

template Tuple(T...)
{
    alias T Tuple;
}

template Range(int n)
{
    static if( n <= 0 )
        alias Tuple!() Range;
    else
        alias Tuple!(Range!(n-1), n-1) Range;
}

void blah()
{
    // Note that static foreach ONLY works inside a function
    foreach( i ; Range!(n) )
    {
        // do stuff with i, which should be a const int
    }
}

There have been times when directly accessing some CT construct would make the compiler choke, but going via an index worked fine.

    -- Daniel

Daniel Keep:
> template Range(int n)

If some of you needs a version that takes 1 or 2 or 3 arguments, for the start, stop and stride, take a look at my dlibs:
http://www.fantascienza.net/leonardo/so/dlibs/templates.html

Bye,
bearophile