Wolfgang Draxinger wrote:
> I'd like to write e.g the following (note the '#' indicating,
> that the template parameter "name" is to be literally replaced
> by what is written at the respective point in the template
> instanciation. The rule would be, that what follows after a '#'
> in a template must be a valid identifier and not a statement or
> expression. The usage of such a parameter within a template
> declaration would automatically limit it's usage to mixins;
> implicit mixin expansion could be assumed, but I'd discourage
> that):
> 
> template GLTexParameter(T type, GLenum Param, #name)
> {
>         T #name(T value)
>         {
>                 static if ( is ( T == GLint ) ) {
>                         glTexParameteri(Target, Param, value);
>                 } else static if ( is ( T == GLfloat ) ) {
>                         glTexParameterf(Target, Param, value);
>                 }
>                 return value;
>         }
> 
>         T #name()
>         {
>                 T value;
>                 static if ( is ( T == GLint ) ) {
>                         glGetTexParameteriv(Target, Param, &value);
>                 } else static if ( is ( T == GLfloat ) ) {
>                         glGetTexParameterfv(Target, Param, &value);
>                 }
>                 return value;
>         }
> }
> 
> class Texture
> {
>         mixin GLTexParameter!(GLint, GL_TEXTURE_MIN_FILTER, min_filter);
>         mixin GLTexParameter!(GLint, GL_TEXTURE_MAG_FILTER, mag_filter);
>         mixin GLTexParameter!(GLfloat, GL_TEXTURE_PRIORITY, priority);
> /*...*/
> }
> 
> I used a '#' since it is not being assumed a token by the D specs
> right now. I'd also like '$' like in shell scripts or Perl, but
> that's a D token already, but right now I can't remember what it
> is for, or if it's actually used.

The '#' character does already have a meaning.  It is the prefix for "Special Token Sequences."  See the specs at:
http://www.digitalmars.com/d/lex.html#specialtokenseq

The '$' is currently used as an alias to the '.length' property of arrays, available only as a right-hand-side to the range sub-op in the slice-op.
array[0 .. $] == array[0 .. array.length]

Personally I don't think '$' having other uses would be a problem, as this usage is pretty distinct.  Also, while I'm not sure if '#' is the best choice for your proposal, I do agree that its something I'd love to see.  There have been a few times where I'd had to resort to tricks like the "named mixin + aliases" style, or ended up just copy-pasting whole sections of code and sighing a lot, especially if something changes.

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:

> Personally I don't think '$' having other uses would be a
> problem, as this usage is pretty
> distinct.  Also, while I'm not sure if '#' is the best choice
> for your proposal, I do
> agree that its something I'd love to see.  There have been a
> few times where I'd had to resort to tricks like the "named
> mixin + aliases" style, or ended up just copy-pasting whole
> sections of code and sighing a lot, especially if something
> changes.

Yes, I think D is not ready for becomming version 1.0 until there
are no sophisticated metaprogramming facilities. I hate to admit
it, but on this topic D is lacking something C++, err no the C
preprocessor provides. Without strong metaprogramming D is
not "ready for combat ;-)" with C++.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E

Chris Nicholson-Sauls wrote:
> The '$' is currently used as an alias to the '.length' property of arrays, available only as a right-hand-side to the range sub-op in the slice-op.
> array[0 .. $] == array[0 .. array.length]

Actually, it also works perfectly fine in the left sub-op in the slice-op:

    import std.stdio;

    void main()
    {
        char[] a = "Hello world!";
        char[] b = a[$-6 .. $-1];
        writefln(b);
    }

prints "world" to stdout, no problem :).

Wolfgang Draxinger wrote:
> I'd like to write e.g the following (note the '#' indicating,
> that the template parameter "name" is to be literally replaced
> by what is written at the respective point in the template
> instanciation. The rule would be, that what follows after a '#'
> in a template must be a valid identifier and not a statement or
> expression. The usage of such a parameter within a template
> declaration would automatically limit it's usage to mixins;
> implicit mixin expansion could be assumed, but I'd discourage
> that):
> 
> template GLTexParameter(T type, GLenum Param, #name)
> {
>         T #name(T value)
>         {
>                 static if ( is ( T == GLint ) ) {
>                         glTexParameteri(Target, Param, value);
>                 } else static if ( is ( T == GLfloat ) ) {
>                         glTexParameterf(Target, Param, value);
>                 }
>                 return value;
>         }
> 
>         T #name()
>         {
>                 T value;
>                 static if ( is ( T == GLint ) ) {
>                         glGetTexParameteriv(Target, Param, &value);
>                 } else static if ( is ( T == GLfloat ) ) {
>                         glGetTexParameterfv(Target, Param, &value);
>                 }
>                 return value;
>         }
> }
> 
> class Texture
> {
>         mixin GLTexParameter!(GLint, GL_TEXTURE_MIN_FILTER, min_filter);
>         mixin GLTexParameter!(GLint, GL_TEXTURE_MAG_FILTER, mag_filter);
>         mixin GLTexParameter!(GLfloat, GL_TEXTURE_PRIORITY, priority);
> /*...*/
> }
> 
> I used a '#' since it is not being assumed a token by the D specs
> right now. I'd also like '$' like in shell scripts or Perl, but
> that's a D token already, but right now I can't remember what it
> is for, or if it's actually used.

My proposal was to add a compile - time utility to convert stings to identifiers: http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005564.html
It wouldn't need new special characters, just one new keyword and it could allow for some more magic.


>> btw, does your engine have some place in the net ? i'd be
>> curious to see it :)
> 
> Ever tried to make self reflecting components in
> C++, _with_ template support?

Hmmm nope...


> Rest assured, that as soon the engine is done I'm going to
> announce it's release on the D newsgroups.

Cool :)


> Check http://www.darkstargames.de/ and if you don't want to loose
> your eyes for eye cancer better do it in about 2 months and then
> go directly to http://www.darkstargames.de/even ;-)

It wasn't that bad. Probably because I have a sentiment for black backgrounds and bright fonts.


> In about a
> week the semester break begins and I got 3 months worth of time
> to spend only my private projects, which one of them is to make
> a new XHTML compliant homepage with sane CSS and modern look.

Great ! I'll pay you a visit later, then :)


--
Tomasz Stachowiak /+ a.k.a. h3r3tic +/

Tom S wrote:

> My proposal was to add a compile - time utility to convert stings to identifiers: http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005564.html It wouldn't need new special characters, just one new keyword and it could allow for some more magic.

Yes, I've thought of that too (somehow managed to miss your post while a was on
a conference).
I think something like that could allow cool LINQ-like things in D.

So, let's hope to see it in D 2.0.

-- 
AKhropov

Tom S wrote:

>
http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005564.html
> It wouldn't need new special characters, just one new keyword and it could allow for some more magic.

I don't know. I understand what you mean by it, but that mixes up runtime types with compiletime tokens. In interpreted languages this would be done by some builtin eval(...) or compile(...) function. But D is a compiles language and I think, that any metaprogramming structures clearly separate compiletime and runtime stuff. And let's face it: char[] is a runtime type, that takes most of it's guts from phobos implementation of Arrays, with some additional sugar to support UTF. I think it should be made clear that such a "identifier parameter" is something special not to be mistaken for a runtime template parameter.

>> Ever tried to make self reflecting components in
>> C++, _with_ template support?
> 
> Hmmm nope...

It's a reliable way to end up in an asylum.

> Cool :)

The engine's going to be licenced GPL/Dual. Kinda like Qt4: Free of charge for open source and educational projectes, but you need a commercial license for use in closed source applications.

> It wasn't that bad. Probably because I have a sentiment for black backgrounds and bright fonts.

Those will stay, but we'll get rid of the late 90ies Java Script clutter, the frames and bonbon style.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E

Wolfgang Draxinger wrote:
> Tom S wrote:
> 
> http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005564.html
>> It wouldn't need new special characters, just one new keyword
>> and it could allow for some more magic.
> 
> I don't know. I understand what you mean by it, but that mixes up
> runtime types with compiletime tokens. In interpreted languages
> this would be done by some builtin eval(...) or compile(...)
> function. But D is a compiles language and I think, that any
> metaprogramming structures clearly separate compiletime and
> runtime stuff. And let's face it: char[] is a runtime type, that
> takes most of it's guts from phobos implementation of Arrays,
> with some additional sugar to support UTF. I think it should be
> made clear that such a "identifier parameter" is something
> special not to be mistaken for a runtime template parameter.

I wouldn't say that char[] is a 'runtime' type. It's a perfectly legit template specialization parameter. It might be runtime-only in other languages, like C++. D gives us more power - power to use string literals as template specializations. Extending this feature (e.g. in the way I proposed it) might yield even more powerful metaprogramming facilities.


--
Tomasz Stachowiak

Wolfgang Draxinger wrote:

> Tom S wrote:
> 
> > 
> http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005564.html
> > It wouldn't need new special characters, just one new keyword and it could allow for some more magic.
> 
> I don't know. I understand what you mean by it, but that mixes up runtime types with compiletime tokens.

That's the idea of templates - you can parametrize them by compile-time known
literals of different types (Type, float, int, char[]...).
I think 'char[]' is no worse than others. Why not extend its capabilities?

> In interpreted languages
> this would be done by some builtin eval(...) or compile(...)
> function. But D is a compiles language and I think, that any
> metaprogramming structures clearly separate compiletime and
> runtime stuff. And let's face it: char[] is a runtime type, that
> takes most of it's guts from phobos implementation of Arrays,
> with some additional sugar to support UTF. I think it should be
> made clear that such a "identifier parameter" is something
> special not to be mistaken for a runtime template parameter.

It maybe of some interest to you how metaprogramming is performed in Nemerle which is a compiled language but allows arbitrary code in metaprograms (they call them macros there):

http://nemerle.org/Macros http://nemerle.org/Macros_tutorial

I would like to see comparable power in D metaprogramming.


-- 
AKhropov

Wolfgang Draxinger wrote:
> Chris Nicholson-Sauls wrote:
> 
>> Personally I don't think '$' having other uses would be a
>> problem, as this usage is pretty
>> distinct.  Also, while I'm not sure if '#' is the best choice
>> for your proposal, I do
>> agree that its something I'd love to see.  There have been a
>> few times where I'd had to resort to tricks like the "named
>> mixin + aliases" style, or ended up just copy-pasting whole
>> sections of code and sighing a lot, especially if something
>> changes.

To follow several other languages...
identifier(str)

creates an identifier called 'str', and is intended for dealing with
keyword conflicts. If str was allowed to be a compile-time string
literal, you could do practically *anything*. Easy enough to implement.
BUT...
The problem is, it would be practically impossible for an IDE to deal with.
(although, maybe that's true already).

> Yes, I think D is not ready for becomming version 1.0 until there
> are no sophisticated metaprogramming facilities. I hate to admit
> it, but on this topic D is lacking something C++, err no the C
> preprocessor provides. Without strong metaprogramming D is
> not "ready for combat ;-)" with C++.

LOL!
D metaprogramming leaves C++ for dead. This is one of the few things
that C++ can do (with a hack!) that D can't; but there are far more
things that D can do, that C++ can't.

Check out my meta.nameof module in DDL on dsource.

Don Clugston wrote:

> To follow several other languages...
> identifier(str)
> 
> creates an identifier called 'str', and is intended for dealing with keyword conflicts. If str was allowed to be a compile-time string literal, you could do practically *anything*. Easy enough to implement. BUT...

Hmm, what about this, somebody might come up with:

template Foo(T, char[] name)
{
        sprintf(name, "foo_%s_1", name);
        T identifier(name)(...){...};
}

I'd prefer to have string literals being treated by the compiler not directly as char[]. Depending on the context it may be treated like a char[] initializer or a lexical object. Additionally it might be usefull to add some string manipulation in the compiler, e.g. implementing the concatenation operator on the lexical scope (if not done already).

template Foo(T, @name)
{
        T @"foo_" ~ name ~ "_1"(...);
}

The '@' prefixing a template parameter would indicating, that it must be a compile time fixed string literal (this could also include const char[] literals on the module level). Within the template the '@' indicates, that the following string, which must be defined at compile time, is to be treated as a literal.

I understand, that it would make no large difference to implement this in form of char[] template parameter, but I prefer a different syntax to make it clear, that it means something different.

> The problem is, it would be practically impossible for an IDE to deal with. (although, maybe that's true already).

Hmm, it wouldn't bee too complicated for an IDE to follow. D is dread easy to parse compared to C or C++ (what the DMD frontend proofes). An IDE using a D frontend would have no problems.

> LOL!
> D metaprogramming leaves C++ for dead.

I know, it one of the reasons why I completely dropped C++ as an option for new projects by me.

> This is one of the few
> things that C++ can do (with a hack!) that D can't; but there
> are far more things that D can do, that C++ can't.

Actually I used this sort of stuff (C++ templates with C preprocessor macro hacks) a lot of times to create boilerplate code.

Of course D's metaprogramming is already way ahead of C++, but the lack of ability to introduce new identifiers by templates/mixins is an itching spot to me. Although C++ does not even provide the abilities of mixins, the preprocessor allows to hack it. - yes it's ugly, yes it's error prone, but it's there and people make use of it.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E