www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Uniform syntax for templates (second try)

reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
This is my second try to propose better syntax for templates. My previous
proposal was added to bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=1827

In this proposal I modified a little bit syntax, took into consideration
more cases and put into table few examples of new syntax compared to old
one.

Attached html version of document. Other formats are too big to send it
through news group, but they are available on request.

I hope for comments from you :-)

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 11 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Marcin Kuszczak wrote:

 This is my second try to propose better syntax for templates. My previous
 proposal was added to bugzilla:
 http://d.puremagic.com/issues/show_bug.cgi?id=1827
 
 In this proposal I modified a little bit syntax, took into consideration
 more cases and put into table few examples of new syntax compared to old
 one.
 
 Attached html version of document. Other formats are too big to send it
 through news group, but they are available on request.
 
 I hope for comments from you :-)


I'll make some candid comments without speaking for Walter.

a) The proposal prevents creating names in expressions, something we 
were talking about:

formattedRead("%s", &(int n));

The sequence "int n" will be ambiguous with a sequence of types.

b) At point 4 my eyes started glazing a bit.

void changeElement(T U N : U[N=uint] if(N>100))
     (T array, U value, int index);

The N=uint jumps as a surprising baroque element. Besides, U[N=uint] 
could be interpreted as a hash with uint as the default key type.

The rewrite in current D2 is:

void changeElement(T : U[N], U, uint N)
     (T array, U value, int index)
     if (N > 100);

To me it's not clear which is better. The second actually may be more 
expressive because you can collectively use all elements of the template 
in one place, something much clunkier in the other version.

c) I totally agree that this should be abolished:

string stringize(T : T[])(T value);

d) Let's try another example.

void parse(T E : E[], U : bool, V E N : E[N] if(N>100))
     (T array, U flag, V sarray);

In D2:

void parse(E, U : bool, V : E[N], uint N)
     (E[] array, U flag, V sarray)
     if(N>100);

e) This will be very hard to understand for both human and machine:

S toupper(isSomeString!(S))(S input)

f) You mention this is not possible, but they are:

void do(T : class)(T instance);
===>
void do(T : Object)(T instance);

void do(T E : E[class])(T sarray, E element);
===>
void do(K, V)(V[K] sarray, K element) if (is(K : Object))

S toupper(isSomeString!(S))(S input)
===>
S toupper(S)(S input) if (isSomeString!(S))

static if (T : Storage!(STORAGETYPE) if (T == MyType))
===>
static if (is(MyType : Storage!(STORAGETYPE), STORAGETYPE)

static if(T == invariant)
===>
static if(T == invariant) ----- should be added

static assert(V E K : E[K] if (K == int), "Not supported");
===>
static assert(is(V : E[int], E), "Not supported");

g) I think this is a rather minor improvement:

alias Variant[][] A B C;

h) I think this should be supported one way or another. Decomposing 
types quickly and easily would be a boon.

alias T U : U[];
alias T U N : U[N=uint] if (N>100);


Andrei
Oct 11 2008
parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Andrei Alexandrescu wrote:


 Marcin Kuszczak wrote:

 This is my second try to propose better syntax for templates. My previous
 proposal was added to bugzilla:
 http://d.puremagic.com/issues/show_bug.cgi?id=1827
 
 In this proposal I modified a little bit syntax, took into consideration
 more cases and put into table few examples of new syntax compared to old
 one.
 
 Attached html version of document. Other formats are too big to send it
 through news group, but they are available on request.
 
 I hope for comments from you :-)


 
 I'll make some candid comments without speaking for Walter.


First of all thanks for your comments. I really appreciate them.
My comments are inlined below.

 

 a) The proposal prevents creating names in expressions, something we
 were talking about:
 
 formattedRead("%s", &(int n));
 
 The sequence "int n" will be ambiguous with a sequence of types.


What is this proposal about? Is there some topic on NG? Is above example
compile time feature? or runtime? 

Well it was difficult for me to take it into consideration, because I was
unaware of this proposal... :-)


 b) At point 4 my eyes started glazing a bit.
 
 void changeElement(T U N : U[N=uint] if(N>100))
      (T array, U value, int index);
 
 The N=uint jumps as a surprising baroque element. 


Another alternative would be e.g.:
void changeElement(T U N=uint : U[N] if(N>100)) (T array, U value, int
index);
Above was in my first proposal (in bugzilla). Then default value could be
given as N=uint(5) where necessary.

or 

void changeElement(T U uint N : U[N] if(N>100)) (T array, U value, int
index);

What ever syntax would be choosen, it should be also choosen for default
template parameters.

Maybe some other syntax for default parameter type/value should be invented.
I don't care so much about that until the main advantages (summarized at
the end of this post) will be kept...


 Besides, U[N=uint] 
 could be interpreted as a hash with uint as the default key type.


No, because you are "fixing" one dimension (type) of type variable, and are
still expecting N to be defined by compiler. On compile time it is only
possible for static array, where N (value) is known at compile time. For
associative arrays it would be an error.

Side note: In fact it seems that arrays can be treated as special case of
associative arrays with perfect hashes, so your notice is fully
understandable ;-)

 

 The rewrite in current D2 is:
 
 void changeElement(T : U[N], U, uint N)
      (T array, U value, int index)
      if (N > 100);
 
 To me it's not clear which is better. The second actually may be more
 expressive because you can collectively use all elements of the template
 in one place, something much clunkier in the other version.


Yes, you are right. And after rethinking this case I think that current if()
after function arguments can stay as it is with global access to all
defined symbols. But in my opinion it should be added also as (optional)
extension for pattern matching expression. This way it will be possible to
use such expression in every compile time statement.
 

 c) I totally agree that this should be abolished:
 
 string stringize(T : T[])(T value);


Yeah. I know :-)

 

 d) Let's try another example.
 
 void parse(T E : E[], U : bool, V E N : E[N] if(N>100))
      (T array, U flag, V sarray);
 
 In D2:
 
 void parse(E, U : bool, V : E[N], uint N)
      (E[] array, U flag, V sarray)
      if(N>100);
 


It's not the same. In my version you restrict first template parameter to be
an array, in your example it can be any type. And additionally, isn't
declaration of N after its usage ugly ;-)



 e) This will be very hard to understand for both human and machine:
 
 S toupper(isSomeString!(S))(S input)


Please don't consider this example and my comments below as part of my main
proposal. This example is more about template specialization resolution,
not about syntax of compile time expression. I didn't put much thinking in
template specialization resolution so below only few random thoughts:

It might be possible to define score based template function resolution. For
every function some logic in compiler would calculate points for "is
function matching". In case one of parameters don't match score would be 0
(false). In other cases there should be chosen function with maximal score. 

Well, I will stop now, as ground is getting more and more swampy :-)



 f) You mention this is not possible, but they are:
 
 void do(T : class)(T instance);
 ===>
 void do(T : Object)(T instance);


This will not work for other categories than class and should be considered
rather as workaround of problem - not solution. Try to make the same with
struct, union, typedef etc. etc.


 void do(T E : E[class])(T sarray, E element);
 ===>
 void do(K, V)(V[K] sarray, K element) if (is(K : Object))


Not an equivalent. You allows here any types. In my version you allow only
associative arrays with classes as key. My function will not be used for
template function resolution. Comment for previous case also applies. And
my syntax is shorter...


 S toupper(isSomeString!(S))(S input)
 ===>
 S toupper(S)(S input) if (isSomeString!(S))


See my comment to your "e"
 

 static if (T : Storage!(STORAGETYPE) if (T == MyType))
 ===>
 static if (is(MyType : Storage!(STORAGETYPE), STORAGETYPE)


You will get syntax error in your example :-). It could be avoided with less
parenthesises. STORAGETYPE is not introduced parameter. Well my example is
also not very good. Although it would work for following case:

alias int STORAGETYPE;

class MyType : Storage!(STORAGETYPE) {
}

static if (T : Storage!(STORAGETYPE) if (T == MyType))



 static if(T == invariant)
 ===>
 static if(T == invariant) ----- should be added


You will probably just get:
static if(is(T == invariant))

I reserved already version without is() :-)
 

 static assert(V E K : E[K] if (K == int), "Not supported");
 ===>
 static assert(is(V : E[int], E), "Not supported");


Please notice that my syntax doesn't disallow shorter version:
static assert(V E : E[int], "Not supported");

In such a case it is even shorter.


 g) I think this is a rather minor improvement:
 
 alias Variant[][] A B C;


I agree. Probably it should be just a syntax error.

 

 h) I think this should be supported one way or another. Decomposing
 types quickly and easily would be a boon.
 
 alias T U : U[];
 alias T U N : U[N=uint] if (N>100);


Yep. It's usefull in some cases. But why not to do it in same way as other
compile time constructs and introduce something new?

---

As general comment I would like to notice that I am not considering this
syntax as finished work. There might be some changes in it, and I even
don't care too much about all details which should be adjusted. In my
opinion major advantages of this proposal are:

1. Same syntax for practically every compile time expression in D. You have
to learn it only once and then intuitively you will apply same pattern in
every case. Currently you have to learn by heart the whole IsExpression
table and additionally syntax for template functions. E.g. matching static
arrays, is far from intuitive, and even I would say that it is against good
practices of programming which demands that symbols are defined *before*
usage, not after.

2. Dropping redundant IsExpression for templates. This makes a lot of code
easier to read (e.g. because of less parenthesis). The notation gets also
shorter.

3. My proposal is more flexible & extensible than current syntax(-es). It's
also shorter in general case. And adding additional possibilities to this
compile time expression will allow to use them in all compile time
statements, differently than it is now.

4. It seems additionally that better pattern matching will render redundant
many use cases for if(ct_expression).


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Marcin Kuszczak wrote:

 Andrei Alexandrescu wrote:

 formattedRead("%s", &(int n));

 The sequence "int n" will be ambiguous with a sequence of types.


 
 What is this proposal about? Is there some topic on NG? Is above example
 compile time feature? or runtime? 


It's just that you can introduce a symbolic definition whenever an 
expression is expected. So "int n" is good as an expression of type int.


 d) Let's try another example.

 void parse(T E : E[], U : bool, V E N : E[N] if(N>100))
      (T array, U flag, V sarray);

 In D2:

 void parse(E, U : bool, V : E[N], uint N)
      (E[] array, U flag, V sarray)
      if(N>100);


 
 It's not the same. In my version you restrict first template parameter to be
 an array, in your example it can be any type. And additionally, isn't
 declaration of N after its usage ugly ;-)


It is the same. Look at how E is used.


 f) You mention this is not possible, but they are:

 void do(T : class)(T instance);
 ===>
 void do(T : Object)(T instance);


 
 This will not work for other categories than class and should be considered
 rather as workaround of problem - not solution. Try to make the same with
 struct, union, typedef etc. etc.


I can by saying:

void do(T)(T instance) if (is(T == whatever));


 void do(T E : E[class])(T sarray, E element);
 ===>
 void do(K, V)(V[K] sarray, K element) if (is(K : Object))


 
 Not an equivalent. You allows here any types. In my version you allow only
 associative arrays with classes as key. My function will not be used for
 template function resolution. Comment for previous case also applies. And
 my syntax is shorter...


The D2 variant is the same because it restricts K to be a class. Also D2 
  eliminates the function from the overload set if the "if" clause is 
not respected (it's pretty much the whole point of the feature).


 S toupper(isSomeString!(S))(S input)
 ===>
 S toupper(S)(S input) if (isSomeString!(S))


 
 See my comment to your "e"


Equivalent.


 static if (T : Storage!(STORAGETYPE) if (T == MyType))
 ===>
 static if (is(MyType : Storage!(STORAGETYPE), STORAGETYPE)


 
 You will get syntax error in your example :-).


I know. That's a bug in the compiler.


 It could be avoided with less
 parenthesises. STORAGETYPE is not introduced parameter. Well my example is
 also not very good. Although it would work for following case:
 alias int STORAGETYPE;
 
 class MyType : Storage!(STORAGETYPE) {
 }
 
 static if (T : Storage!(STORAGETYPE) if (T == MyType))
 
 

 static if(T == invariant)
 ===>
 static if(T == invariant) ----- should be added


 
 You will probably just get:
 static if(is(T == invariant))


Correct.


 I reserved already version without is() :-)
  

 static assert(V E K : E[K] if (K == int), "Not supported");
 ===>
 static assert(is(V : E[int], E), "Not supported");


 
 Please notice that my syntax doesn't disallow shorter version:
 static assert(V E : E[int], "Not supported");
 
 In such a case it is even shorter.
 

 g) I think this is a rather minor improvement:

 alias Variant[][] A B C;


 
 I agree. Probably it should be just a syntax error.
 
  

 h) I think this should be supported one way or another. Decomposing
 types quickly and easily would be a boon.

 alias T U : U[];
 alias T U N : U[N=uint] if (N>100);


 
 Yep. It's usefull in some cases. But why not to do it in same way as other
 compile time constructs and introduce something new?
 
 ---
 
 As general comment I would like to notice that I am not considering this
 syntax as finished work. There might be some changes in it, and I even
 don't care too much about all details which should be adjusted. In my
 opinion major advantages of this proposal are:
 
 1. Same syntax for practically every compile time expression in D. You have
 to learn it only once and then intuitively you will apply same pattern in
 every case. Currently you have to learn by heart the whole IsExpression
 table and additionally syntax for template functions. E.g. matching static
 arrays, is far from intuitive, and even I would say that it is against good
 practices of programming which demands that symbols are defined *before*
 usage, not after.


Uniformity is good.


 2. Dropping redundant IsExpression for templates. This makes a lot of code
 easier to read (e.g. because of less parenthesis). The notation gets also
 shorter.


I think this is rather minor.


 3. My proposal is more flexible & extensible than current syntax(-es). It's
 also shorter in general case. And adding additional possibilities to this
 compile time expression will allow to use them in all compile time
 statements, differently than it is now.


I'm not sure about terseness. Your patterns tend to introduce more symbols.


 4. It seems additionally that better pattern matching will render redundant
 many use cases for if(ct_expression).


Yah, that I'm looking forward to.

This is a big change. To sell this big change to people and Walter, you 
need to have some smashing advantages. So far you have I'm not seeing a 
smashing advantage. Easily decomposing types in patterns would be one, 
but that is something that could be pulled out of your proposal and 
implemented alone.


Andrei
Oct 12 2008
parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Andrei Alexandrescu wrote:


 Marcin Kuszczak wrote:

 As general comment I would like to notice that I am not considering this
 syntax as finished work. There might be some changes in it, and I even
 don't care too much about all details which should be adjusted. In my
 opinion major advantages of this proposal are:
 
 1. Same syntax for practically every compile time expression in D. You
 have to learn it only once and then intuitively you will apply same
 pattern in every case. Currently you have to learn by heart the whole
 IsExpression table and additionally syntax for template functions. E.g.
 matching static arrays, is far from intuitive, and even I would say that
 it is against good practices of programming which demands that symbols
 are defined *before* usage, not after.


 
 Uniformity is good.
 

 2. Dropping redundant IsExpression for templates. This makes a lot of
 code easier to read (e.g. because of less parenthesis). The notation gets
 also shorter.


 
 I think this is rather minor.


IsExpression is causing problems for newbies, as I already mentioned before.
Is syntax for templates was mentioned as difficult for students of D
language. And it must be learnt by heart. (Well, maybe that's opposite:
template function parameters must be learnt by heart, as they are
inconsistent with is()?)
 

 3. My proposal is more flexible & extensible than current syntax(-es).
 It's also shorter in general case. And adding additional possibilities to
 this compile time expression will allow to use them in all compile time
 statements, differently than it is now.


 
 I'm not sure about terseness. Your patterns tend to introduce more
 symbols.


You will need more symbols only when you need to take more information from
expression. There will be always version which will introduce not more
symbols than currently.


 4. It seems additionally that better pattern matching will render
 redundant many use cases for if(ct_expression).


 
 Yah, that I'm looking forward to.
 
 This is a big change. To sell this big change to people and Walter, you
 need to have some smashing advantages. So far you have I'm not seeing a
 smashing advantage. Easily decomposing types in patterns would be one,
 but that is something that could be pulled out of your proposal and
 implemented alone.


Well, I am not saying that this is top-priority change right now. I am just
saying that it would be better to have it implemented - it should be a way
to go. I really don't have an idea how much work is it to implement this.
The fact is that most pieces are already in-place, they just have to be
connected together. Maybe it would be possible to introduce this change
partially, finally depreciating is() completely? There will be probably not
so much impact on user code, as only heavily templated code (using matching
by e.g. static arrays) will be affected. Common cases will stay exactly the
same.

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Marcin Kuszczak wrote:

 Well, I am not saying that this is top-priority change right now. I am just
 saying that it would be better to have it implemented - it should be a way
 to go. I really don't have an idea how much work is it to implement this.
 The fact is that most pieces are already in-place, they just have to be
 connected together. Maybe it would be possible to introduce this change
 partially, finally depreciating is() completely? There will be probably not
 so much impact on user code, as only heavily templated code (using matching
 by e.g. static arrays) will be affected. Common cases will stay exactly the
 same.


Why are you sure deprecating is() is a goal in and of itself? You 
mention beginners are having trouble understanding it, but then you'd 
need to make a pretty good case that beginners won't have much trouble 
understanding your way. (It took me a while.)

Besides one good thing about is() is that it allows you to match type 
patterns without error. For example:

static if (is(T = V[K], K, V)) {
     // T is a hash, use K and V
} else static if (is(T = V[], V)) {
     // T is an array, use V
} ...

In contrast, aliasing can only fail with a compile-time error:

alias T K V : T = V[K];

I agree that using a symbol before clarifying that it's being introduced 
is odd. Anyhow, it would be great if more people added to this exchange 
to get a feel of the level of interest.


Andrei
Oct 12 2008
next sibling parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Andrei Alexandrescu wrote:


 Marcin Kuszczak wrote:

 Well, I am not saying that this is top-priority change right now. I am
 just saying that it would be better to have it implemented - it should be
 a way to go. I really don't have an idea how much work is it to implement
 this. The fact is that most pieces are already in-place, they just have
 to be connected together. Maybe it would be possible to introduce this
 change partially, finally depreciating is() completely? There will be
 probably not so much impact on user code, as only heavily templated code
 (using matching by e.g. static arrays) will be affected. Common cases
 will stay exactly the same.


 
 Why are you sure deprecating is() is a goal in and of itself? You
 mention beginners are having trouble understanding it, but then you'd
 need to make a pretty good case that beginners won't have much trouble
 understanding your way. (It took me a while.)


They will have to learn my syntax anyway. Currently there is no way around,
as my syntax is based on is() expression from D1.0. But in my proposal
there is only one syntax to learn. Currently you have to learn how to write
is() expression and how to write template function parameters.
 

 Besides one good thing about is() is that it allows you to match type
 patterns without error. 


It will be still possible as in your example below, but in simpler way:
static if (T V K :V[K])
I am not arguing about removing this case. It is usefull.


 For example: 
 
 static if (is(T = V[K], K, V)) {
      // T is a hash, use K and V
 } else static if (is(T = V[], V)) {
      // T is an array, use V
 } ...


LOL. And now you have been stroked by D template syntax nuances! 

Above code is incorrect. And it is not only matter of '=' instead '=='. It
is the matter of funky syntax, which doesn't keep any rules. In fact in 2.0
it's even worse than in 1.0 after adding TemplateParameterList to is()
expression.

Above code should be written as below:

void main() {
    alias long[char[]] T;
    static if (is(T V == V[K], K)) {
        pragma(msg, V.stringof ~ " " ~ K.stringof);
    } else static if (is(T V == V[])) {
        pragma(msg, V.stringof);
    }
}

Who will guess how to write above without looking into docs? No one.

BTW. first pragma prints: "long const(char)[]". Is it by design or is it an
error?


 In contrast, aliasing can only fail with a compile-time error:
 
 alias T K V : T = V[K];


This syntax would be usefull only in case where you can know for sure that T
is associative array. In such a case you can safely decompose T into
subtypes.


 I agree that using a symbol before clarifying that it's being introduced
 is odd. Anyhow, it would be great if more people added to this exchange
 to get a feel of the level of interest.


 
Well, I wonder why no one except you commented about this issue. That might
be the case that people didn't write so much code using isExpression and
complicated template function's template parameters. I have written
automatic serializer, which is currently probably the most advanced
solution for D. It has definable back-ends (SimpleText, JSon and
Binary(thanks to Bill Baxter, who wrote it)), versioning of classes,
importing old versions, thread safety, exception safety, discovering of
templated functions in user classes and optional saving results to string
or any other stream (btw. I would be happy to discuss with someone about my
design :-)). It is heavily templated code, with many different corner cases
which stresses type system a lot (e.g. I discovered that it's not possible
to create pointer to class in straight way). Maybe only few people wrote
such a code? I don't know because inconstancy just strikes in the eyes when
working with it...

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 12 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Marcin Kuszczak" <aarti_please_no spam_interia.pl> wrote in message 
news:gctj4a$2k7p$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 I agree that using a symbol before clarifying that it's being introduced

 is odd. Anyhow, it would be great if more people added to this exchange
 to get a feel of the level of interest.


 Well, I wonder why no one except you commented about this issue.


I've been following, but feeling completely out of my league. The idea of 
more consistency in the syntaxes (as well as removing is()) sounds great, 
but I really haven't been using D templates and such enough to feel like I'd 
really know what I was talking about and actually have real informed 
opinions.
Oct 12 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 13, 2008 at 4:28 AM, Marcin Kuszczak
<aarti_please_no spam_interia.pl> wrote:

 Well, I wonder why no one except you commented about this issue.


I also have been glancing over this thread, but just haven't had the
time to really follow it.
But is and template matching syntax really is fu-bar right now, and
something to make it saner, more consistent and easier to remember
would be great.  Any time I want to use pattern matching is
expressions I basically open up the manual to the is expression page
right now, but I can't remember that bizarre syntax to save my life.

--bb
Oct 12 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 12 Oct 2008 11:15:59 -0500,
Andrei Alexandrescu wrote:

 Anyhow, it would be great if more people added to this exchange 
 to get a feel of the level of interest.


I admit I felt disappointed a couple of times when I wasn't able to use 
some is() tricks in a template type list.  If that's fixed then I'm fine 
with the rest of the syntax.

Unconditional type decomposition sounds useful.
Oct 12 2008