Re: C++0x Concepts - Dead?
Walter Bright wrote:
aarti_pl wrote:
Walter Bright pisze:
aarti_pl wrote:
My proposal would make meta programing in D much more intuitive
(because of using rules - not bunch of corner cases as it is today).
Unfortunately almost no one from NG commented on that...
Thank you, but I don't see in your proposal a method that can:
1. instantiate templates only if a value argument is prime or odd.
2. instantiate templates only on a type which supports addition and
has the method foo.
Note that C++ Concepts could do (2) but could not do (1).
ad.1
template normalizedType((T U N : U[N=size_t]) (N 1))
As it is stated in proposal commas are only syntax sugar for more
general form with ''.
How do you distinguish a type from an expression?
ad.2.
This case is in fact the same as 1. Because of the fact that A, B, C
= A B C, you can create expressions as you want just using
second form with logical operators. In this case you should just use
proper compile time reflection mechanism in D to get information about
type properties.
class C {
int opAdd(C);
}
How would I write the parameter to accept any type that supports
addition? I want to support int, float, C, etc., without having to
exhaustively enumerate them.
That's actually pretty close to what I want, I want to support any type
that has a field or readable property named key which field supports
and =. Since I want to include various integer types I can't require
that it support opCmp.
The way I'd been wishing was that the built-in types supported the
pre-defined operators, such as opCmp. (I haven't tried, but if they do
it doesn't seem to be documented. Eventually I'll probably get around
to trying, but so far it's a comment in the class header.)
(If you haven't guessed, even the current template system intimidates
me, so I generally look for other ways to do things. I'm especially
intimidated, among the parts that I've looked at, by the rules for
instantiation of a template type. It probably takes me half an hour
each time I do it, and I'm never certain I've done it correctly until
the program either works or doesn't work.)
I REALLY appreciate syntactic regularity. I like being able to leave
out empty parentheses. And I'd really like it if things like opCmp were
available for the built-in types (although, I don't think opCmp should
be defined for the complex numbers).
Actually, I'd like it if one could build classes that inherited from the
built-in types, also. That would frequently be the cleanest way to do
something. I understand that this would be essentially implementing
inheritance for structs, and there may be good reasons to not do this.
But it would regularize the syntax markedly. It would make it so that
the main difference between classes and structs is that classes were
referenced by handles, and structs were value types.
I don't THINK I've drifted far from the original point. If I have, my
appologies. But where possible I feel that syntax should be made more
regular. And this includes being able to test classes, structs, and
built-in types in templates using the same constructions. Like opAdd or
opCmp. One often doesn't care what kind of thing one is checking, but
only what features it possesses. So there should be easy ways to check
for the possession of those features.
I note that I'm not making a clear distinction between types and
instances of types, but in D every instance should be an instance of
some particular type. I didn't explicitly mention expressions, but the
definitions of delegates and pointers to functions involve
expressions...so I'm not exactly certain where the boundary lies.
More on expressions: if one allows type variables, and testing of type
variables for features, then it becomes reasonable to allow expressions
that combine those type variables (and probably type literals). OTOH,
even if those type expressions exist, it seems unlikely that the normal
operations would be the desired ones. One would be more likely to want
expressions of the form if v implements method m and has feature f,
then I think this can probably already be done with static if and
traits, though I'm not sure if traits are available at compile time.
But HOW COMPLICATED DO YOU WANT TEMPLATE SPECIFICATION TO BE???
OTOH, most of the changes that I want are along the lines of
regularizing syntax. And I realize that they may be either too
difficult or too costly in ways that aren't readily apparent to me.
Like allowing structures to support inheritance, and having the
overloaded operator names be accessible for the built-in types. (And I
haven't checked that yet.)
Re: C++0x Concepts - Dead?
Dnia 2009-07-17, pią o godzinie 02:32 +0200, BLS pisze:
bearophile wrote:
BLS:
bearophile brings in several times Scala/OCAML like pattern matching.
Why not using that for constraints ?
I have no idea how that works, though Bartosz has been looking into it.
O well, I am pretty sure that bearophile is willing to give you any
information you need :)
Pattern matching is handy and it can be powerful, for example I've seen
OCaML code that uses it to implement a AVL search tree in about 15 lines of
code. But probably it also adds lot of complexity to a language like D, so
there are more important things to add to D2 now (like good concurrency).
Bye,
bearophile
I see your point... you are doing bio informatics..so speed matters..
for me the things are a bit different...
But I guess that you'll agree with me that Scala pattern matching has a
reasonable syntax. (Not necessarily talking about How difficult is it
from a compiler author's view)
object MatchTest2 extends Application {
def matchTest(x: Any): Any = x match {
case 1 = one
case two = 2
case y: Int = scala.Int
}
println(matchTest(two))
}
Hi,
I will point you into two projects:
Prop: http://www.cs.nyu.edu/leunga/prop.html (C++)
Tom: http://tom.loria.fr/wiki/index.php5/Main_Page (multi language)
Both are source-to-source translators.
First is imho nicer (considering syntax), but not maintained.
I'm thinking now about implementing similar thing for D (especially
that I'm also working with Erlang, and some symbolic data and
expressions in D). Or adding D support to Tom (but it is ugly)
Nemerle have also interesting pattern matching.
PS. There is also project called App for C++ pattern matching, but
cant find info now.
Re: C++0x Concepts - Dead?
Walter Bright wrote:
Christian Kamm wrote:
Christian Kamm wrote:
Is there a difference between
template Foo(T : U) {} and
template Foo(T) if(is(T : U)) {} ?
Walter Bright wrote:
Yes. Constraints determine the list of candidate template declarations,
but do not participate in the partial ordering of candidates to
determine the 'best' match.
Thanks for the explanation!
I expect the reason is that for constrained templates it is impossible
to determine whether all valid template arguments for one would lead
to a valid instantiation of another?
That's a good technical reason, but I also felt that the current way
just made intuitive sense.
The current Template specialization implementation is doing a best fit
search anyway, so why constraints are not able to use the same mechanism. ?
So, instead of IFTI we should have EFTI*, driven by constraints.
*The name is rather confusing so fuzzy templates are probably better.
bearophile brings in several times Scala/OCAML like pattern matching.
Why not using that for constraints ?
IMO the current D constraints implementation is nice and easy, but I
thing there is much more hidden power in that idea.
Thanks for ignoring my ignorance..
Re: C++0x Concepts - Dead?
Reply to Nick, Hmm, but I guess it does allow match/not-match to be determined by arbitrary compile-time expressions. Is there another benefit to the constraints that I'm missing? Not that I know of (but that says very little :). It might be a good rule of thumb to never directly use the simple is(T:U) in a template constraint.
Re: C++0x Concepts - Dead?
BLS wrote: The current Template specialization implementation is doing a best fit search anyway, so why constraints are not able to use the same mechanism. ? The template specialization method is based on types - but there's no way to look inside those types and specialize based on properties of those types. That's where constraints come in. Constraints use a completely different matching method than the type parameters do. It makes intuitive sense to logically separate them, rather than to mix them up. bearophile brings in several times Scala/OCAML like pattern matching. Why not using that for constraints ? I have no idea how that works, though Bartosz has been looking into it.
Re: C++0x Concepts - Dead?
Reply to Jarrett, I was thinking it'd be more intuitive if constraints - which are more general - would be used to implement specialization. That is, template X(T: A, U: B) would basically be syntactic sugar for template X(T) if(is(T: A) is(U: B)) Then you have only a single system of specialization and constraining to worry about. How would best matching work? The compiler could definitely be smart enough to pick apart the logical expression in the constraint, My thought on this is discard non `is(T:U)` terms and expand the expressions into a set of simple AND expressions: - discard any template options where the expression fails - replace all sub trees other than AND, OR and `is(T:U)` nodes with their evaluated value. - expand to disjunctive normal form (http://en.wikipedia.org/wiki/Disjunctive_normal_form) - discard false disjuncts - discard negated terms - treat each disjunct or each template options as it's own specialization option and apply the current partial ordering rules.
Re: C++0x Concepts - Dead?
aarti_pl wrote: My proposal would make meta programing in D much more intuitive (because of using rules - not bunch of corner cases as it is today). Unfortunately almost no one from NG commented on that... Thank you, but I don't see in your proposal a method that can: 1. instantiate templates only if a value argument is prime or odd. 2. instantiate templates only on a type which supports addition and has the method foo. Note that C++ Concepts could do (2) but could not do (1).
Re: C++0x Concepts - Dead?
Ary Borenszweig wrote: Suppose you implement partial ordering with template constraints and drop the others. What things you couldn't do? (I need an example because I can't see it). How could I do partial ordering if one constraint expression accepts only odd integers? Remember that partial ordering is not done with the specific argument values, but with the general parameter ones.
Re: C++0x Concepts - Dead?
On Thu, Jul 16, 2009 at 5:03 PM, Walter Brightnewshou...@digitalmars.com wrote: Jarrett Billingsley wrote: Let's try to *simplify* metaprogramming and make things *orthogonal* instead of tacking on features with no regard to the existing ones. Type matching cannot do what expression matching can do. You'd need a totally new syntax anyway to bring expression matching into the template type parameter list. Wow, can you say taken out of context? I proposed the *exact* opposite. Note: template X(T: A, U: B) would basically be syntactic sugar for template X(T) if(is(T: A) is(U: B))
Re: C++0x Concepts - Dead?
Walter Bright pisze:
aarti_pl wrote:
How would you do currently in D?
template (T) if (T.init + T.init)
{
}
in D1.0
template(T if typeof(T.init + T.init) == T)
or in D2.0
template(T if __traits(compiles, T.init + T.init))
I could mess something in above examples, but as you can see, getting it
to work is not a problem of my syntax for templates. It is just a matter
of using proper syntax for compile time reflection.
BR
Marcin Kuszczak
(aarti_pl)
Re: C++0x Concepts - Dead?
Reply to Walter, How could I do partial ordering if one constraint expression accepts only odd integers? you wouldn't, but rather ignore that clause and mine the constraints that you would use out of the expression (see my post for details)
Re: C++0x Concepts - Dead?
aarti_pl wrote:
Walter Bright pisze:
aarti_pl wrote:
How would you do currently in D?
template (T) if (T.init + T.init)
{
}
in D1.0
template(T if typeof(T.init + T.init) == T)
D1 is closed to such enhancements, in any case, the ==T part is wrong.
byte+byte==int, for example.
or in D2.0
template(T if __traits(compiles, T.init + T.init))
I could mess something in above examples, but as you can see, getting it
to work is not a problem of my syntax for templates.
Ok, but it's hard to see why it is better.
Re: C++0x Concepts - Dead?
BCS wrote: Reply to Walter, How could I do partial ordering if one constraint expression accepts only odd integers? you wouldn't, but rather ignore that clause and mine the constraints that you would use out of the expression (see my post for details) Then aren't things getting just as, or even more, complicated? My big beef with Concepts is it was 40 pages of specification. D's constraints are a couple lines of specification. To replace them, it needs to be significantly simpler, not just different.
Re: C++0x Concepts - Dead?
BLS wrote: Thanks for taking the time to answer ; But the question remains the same : _Why_ ? Constraints /have/ to use a completely different approach ? (more intuitive than is not ..ahem.. is not a good enough reason) I think it is a very good reason. Of course, we can argue about if it is actually intuitive or not.
Re: C++0x Concepts - Dead?
BCS pisze: Reply to Aarti_pl, template(T if typeof(T.init + T.init) == T) who ever said T + T == T? What if that is not needed? That is the only way to do it in D1 AFAIK. In D2 you have __traits(compile, ). But before you get into discussion, please read my point made to Walter: possibility to get such a functionality is not and SHOULD NOT be connected with template instantiations, but rather with proper compile time reflection. BR Marcin Kuszczak (aarti_pl)
Re: C++0x Concepts - Dead?
Reply to Walter, BCS wrote: Reply to Walter, How could I do partial ordering if one constraint expression accepts only odd integers? you wouldn't, but rather ignore that clause and mine the constraints that you would use out of the expression (see my post for details) Then aren't things getting just as, or even more, complicated? 99% of the time nobody needs to worry about how exactly partial ordering works. 90% of the time* people don't need to worry about putting constraints in the if clause or in the argument list. I'd much rather have more complexity on the thing I need 1% of the time than the thing I need 10%. And the the rules I proposed are arguably simpler than the partial ordering bit that it inherits wholesale from the current solution so it might not even be the hard part. On top of that, they may also alow for fewer cases wher the partial ordering even comes into play. *87.6% of statistics are made up on the spot.
Re: C++0x Concepts - Dead?
BLS: bearophile brings in several times Scala/OCAML like pattern matching. Why not using that for constraints ? I have no idea how that works, though Bartosz has been looking into it. O well, I am pretty sure that bearophile is willing to give you any information you need :) Pattern matching is handy and it can be powerful, for example I've seen OCaML code that uses it to implement a AVL search tree in about 15 lines of code. But probably it also adds lot of complexity to a language like D, so there are more important things to add to D2 now (like good concurrency). Bye, bearophile
Re: C++0x Concepts - Dead?
Walter Bright pisze:
aarti_pl wrote:
Walter Bright pisze:
aarti_pl wrote:
How would you do currently in D?
template (T) if (T.init + T.init)
{
}
in D1.0
template(T if typeof(T.init + T.init) == T)
D1 is closed to such enhancements, in any case, the ==T part is wrong.
byte+byte==int, for example.
I don't want to dive into it. It has nothing to do with origins of this
discussion. You asked - I answered :-)
or in D2.0
template(T if __traits(compiles, T.init + T.init))
I could mess something in above examples, but as you can see, getting
it to work is not a problem of my syntax for templates.
Ok, but it's hard to see why it is better.
So you suggest that advantage of if constraint is possibility to get
compile time information about types?
In my opinion they are completely different concepts and they should be
separated. In most cases messing two concepts together is wrong.
Advantages of my syntax are enumerated in my proposal. I will not repeat
them here again.
BR
Marcin Kuszczak
(aarti_pl)
Re: C++0x Concepts - Dead?
bearophile wrote:
BLS:
bearophile brings in several times Scala/OCAML like pattern matching.
Why not using that for constraints ?
I have no idea how that works, though Bartosz has been looking into it.
O well, I am pretty sure that bearophile is willing to give you any
information you need :)
Pattern matching is handy and it can be powerful, for example I've seen OCaML
code that uses it to implement a AVL search tree in about 15 lines of code. But
probably it also adds lot of complexity to a language like D, so there are more
important things to add to D2 now (like good concurrency).
Bye,
bearophile
I see your point... you are doing bio informatics..so speed matters..
for me the things are a bit different...
But I guess that you'll agree with me that Scala pattern matching has a
reasonable syntax. (Not necessarily talking about How difficult is it
from a compiler author's view)
object MatchTest2 extends Application {
def matchTest(x: Any): Any = x match {
case 1 = one
case two = 2
case y: Int = scala.Int
}
println(matchTest(two))
}
Re: C++0x Concepts - Dead?
Walter Bright wrote: BLS wrote: Walter Bright wrote: BLS wrote: (more intuitive than is not ..ahem.. is not a good enough reason) I think it is a very good reason. Of course, we can argue about if it is actually intuitive or not. ok. but that's only eye candy, no ? I once drove a tractor that you stepped on the gas to stop it, and released the pedal to get it to go. I nearly drove the thing through the owner's boat. Missed it by about an inch. OK!, this argument is simply _too_ good. have.togive..up
Re: C++0x Concepts - Dead?
Christian Kamm wrote:
BLS Wrote:
I have somehow the idea that D constraints and template specialization
should merge.
I also feel that specialization may just be a special case of constraints -
with the added benefit that implicit function template instantiation works.
will see what Walter is thinking.
Maybe we can call that stuff later on ... meta generics ? Now serious ,
looking a bit ahead, complete templated decision trees are /at least/
imaginable.
Is there a difference between
template Foo(T : U) {} and
template Foo(T) if(is(T : U)) {} ?
erm, give me an hour or so.. :)
Re: C++0x Concepts - Dead?
Christian Kamm:
Is there a difference between
template Foo(T : U) {} and
template Foo(T) if(is(T : U)) {} ?
I think if() offers better error messages here (I have not tried it in this
case, so I may be wrong).
Even if I am right, it's not inevitable, GCC shows to give better error
messages (better == the first line of error shows the line number where you
have tried to instantiate the template).
See also:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=92766
I have tried to ask this (simple?) but handy feature to LDC developers, but
they have answered me that it's something that has to be done by the front-end
(by Walter, mostly), so it's not something LDC devs want to to add just to LDC
for me :-)
Bye,
bearophile
Re: C++0x Concepts - Dead?
Christian Kamm wrote:
BLS Wrote:
I have somehow the idea that D constraints and template specialization
should merge.
I also feel that specialization may just be a special case of constraints -
with the added benefit that implicit function template instantiation works.
Is there a difference between
template Foo(T : U) {} and
template Foo(T) if(is(T : U)) {} ?
Yes. Constraints determine the list of candidate template declarations,
but do not participate in the partial ordering of candidates to
determine the 'best' match.
Re: C++0x Concepts - Dead?
Walter Bright Wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. This seems to be the relevant pre-Frankfurt text: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf I doubt concepts are 'dead' - from the rumors you've heard it sounds likely the 'decoupled' or 'semi-decoupled' option was chosen.
Re: C++0x Concepts - Dead?
Christian Kamm: This seems to be the relevant pre-Frankfurt text: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf C++ as a language has competition -- from high-level runtimes such as JavaScript, .NET etc; from hardware such as graphics accelerators; and from C and Objective C. Ideally, the pace of overall C++ feature development should be such as to maintain C++s competitive position against such alternatives. Despite the performance of the Chrome V8 JS JIT, JavaScript isn't much a competitor to C++, they have different purposes and kind of programmers. And graphics accelerators do little by themselves, they are there to be used from C++ too, if for example C++ improves its support for OpenCL and similar things. C++ feature development sounds a little scary if you think about the too much complex implementation of lambda functions in C++0x... (And such kind of developments will not help C++0x face any competition from JavaScript, it's like nailing a second bigger cannon on a large tank to help it fight better against an infestation of mice). Bye, bearophile
C++0x Concepts - Dead?
There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:46 PM, Jarrett Billingsleyjarrett.billings...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow. I mean, really, I'm kind of speechless. I thought they were supposed to be one of the killer features.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:59 PM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: On Mon, Jul 13, 2009 at 5:46 PM, Jarrett Billingsleyjarrett.billings...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow. I mean, really, I'm kind of speechless. I thought they were supposed to be one of the killer features. You were at the wrong tense: -ing, not -er. :o) Ahaha, good one :) Yeah, what's the solution to a complex, incomprehensible language? More complexity!
Re: C++0x Concepts - Dead?
Walter Bright wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Who cares. Or, in other words ; do you consider D constraints as can't life without feature ? (no offense.. just think it's not that remarkable)
Re: C++0x Concepts - Dead?
Andrei Alexandrescu wrote: Jarrett Billingsley wrote: On Mon, Jul 13, 2009 at 5:59 PM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: On Mon, Jul 13, 2009 at 5:46 PM, Jarrett Billingsleyjarrett.billings...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow. I mean, really, I'm kind of speechless. I thought they were supposed to be one of the killer features. You were at the wrong tense: -ing, not -er. :o) Ahaha, good one :) Yeah, what's the solution to a complex, incomprehensible language? More complexity! Speaking of which, I think D has reached the perfect shade with restricted templates. That is, after Walter fixes the related bugs... Andrei ... And gets rid of SFNAE... Seriously, with restricted templates, template specializations, static if, etc., SFNAE is about as bug-prone a feature as we have in the language.
Re: C++0x Concepts - Dead?
BLS wrote: Walter Bright wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Who cares. Or, in other words ; do you consider D constraints as can't life without feature ? (no offense.. just think it's not that remarkable) It's remarkable in that Concepts were considered the marquee feature of C++0x. I think that D constraints fill the same niche, but without any of the complexity of Concepts.
