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"))
}

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 ?

Intuitive has a lot of benefits:

1. easy to learn
2. easy to use correctly
3. easy to spot mistakes
4. makes code look more attractive
5. less intimidating


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.

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.....to........give..up

BLS:
> I see your point... you are doing bio informatics..so speed matters.. for me the things are a bit different...

Bioinformatics doesn't matter much here. One of the PCs I use has a CPU with 4 cores plus about a ~$100 3D card (that can be programmed with CUDA to produce spectacular programs, I have seen demos run on this PC that almost scare me, like this one: http://www.youtube.com/watch?v=RqduA7myZok  and this is a low-end 3D card: there are cards that probably have 3-6X more computing power), when I write normal D1 code today I am probably using 10-30% of such computing power. Compared to such "waste" even the performance gain of LDC over DMD is small.

A sufficiently determined programmer can learn CUDA for the GPU and do all the low level multithread programming you want on the CPU, to find ways to use most of that computing power. But something similar can be said about programming in assembly too. I'm willing to lose 20% of efficiency if the language (future D2) will give me handy&safe ways to use the other cores of the CPU and maybe even to use the GPU too at the same time (see OpenCL). Tapping some percentage of that CPU+GPU power in a handy enough way is today quite important.


> 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"))
> }

Scala pattern matching, when used for simple/medium things, is simple to read and understand (when you use it for complex things it quickly becomes hard to understand).
But beside the extra syntax, if you want to add pattern matching to D2 (OCaML-style pattern matching may be more fit for D2, because it probably has a higher performance at run-time and it's closer to the style of C++-like languages where as much as possible is done at compile-time) you probably need a more complex type system, and adding such improved type system to D2 looks like a too much big work now (and it increases complexity of other things too, I fear). That's why I have stopped for long time asking to add a built-in pattern matching to D, even if I can't deny it's sometimes handy.

Bye,
bearophile

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.

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 ?
> 
> Intuitive has a lot of benefits:
> 
> 1. easy to learn
> 2. easy to use correctly
> 3. easy to spot mistakes
> 4. makes code look more attractive
> 5. less intimidating
> 
> 
> 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.

On a visit to London, there was a guy in a very circulated pedestrian area downtown who challenged people to ride a bicycle that had reverted steering - you'd have to turn the steering to the left to veer right. He'd challenge people 5 pounds to only ride the bike straight for a few yards (no need to even pedal, just push it once). He'd demonstrate how to do it first.

He made $35 only as I ate a pizza watching.


Andrei

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.)

On Mon, 13 Jul 2009 14:33:56 -0700
Walter Bright <newshound1@digitalmars.com> wrote:

> There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts.

Something that viewers may alos like. Didn't see this posted anywhere
else here:
http://www.reddit.com/r/programming/comments/93j7u/bjarne_stroustrup_discusses_the_remove_concepts/