"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> escreveu na mensagem news:b0h0gs$159b$1@digitaldaemon.com...
> Daniel Yokomiso wrote:
> >     We can add more powerful array operations if they became safer:
> > http://www.sys.uea.ac.uk/~jrwg/Sisal/ This may solve the problems
> > Expression Templates try to solve...
>
> You may also take a look at SAC (Single Assignment C) at http://www.informatik.uni-kiel.de/~sacbase/ which claims to the the official successor of Sisal. Anyway: Both languages are tailored towards high-performance numerical computing. No way to even consider taking D, which is explicitely designed to be a general purpose language in that direction. And just trying to pick bits from them will not buy us much.
>

SAC is also very nice too. IMO their array semantics could be extended to D without changing much of D's nature as general purpose programming language.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003

Daniel Yokomiso wrote:
> 
>     The way I see it, a template is always correct. The complete set of
> requirements that a type parameter must meet is in all the possible usages
> inside the template (all execution paths). So if the template requires your
> type to provide + & [] .connectToSQL() operations, it's your problem meeting
> this. At least until we can add operation interfaces. In current mechanisms
> the template determine a structural typing constraint a la OCaml methods on
> their parameters.
> 

Hi,

In C++ templates there are concepts like iterator, forward_iterator, allocator, etc. They exist, but are not enforced by the language.

Maybe in D we could use interfaces to enforce the concepts needed by the templates.  And explicitly tell the compiler the concepts/interfaces a certain template type expects. I think it would make error detection much simpler.

OT: Just to put my 2 cents, I prefer the proposed template notation using the $ to specify the generic part.

--
Marcelo Fontenele S Santos <msantos@pobox.com>

Marcelo Fontenele S Santos wrote:
> Daniel Yokomiso wrote:
> 
>>
>>     The way I see it, a template is always correct. The complete set of
>> requirements that a type parameter must meet is in all the possible usages
>> inside the template (all execution paths). So if the template requires your
>> type to provide + & [] .connectToSQL() operations, it's your problem meeting
>> this. At least until we can add operation interfaces. In current mechanisms
>> the template determine a structural typing constraint a la OCaml methods on
>> their parameters.
>>
> 
> Hi,
> 
> In C++ templates there are concepts like iterator, forward_iterator, allocator, etc. They exist, but are not enforced by the language.
> 
> Maybe in D we could use interfaces to enforce the concepts needed by the templates.  And explicitly tell the compiler the concepts/interfaces a certain template type expects. I think it would make error detection much simpler.

Predicate types - or type constraints - are supported by most generic systems that I've seen.  One way they could be in D is like this:

   predicate TComparable ($T)
   {
       $T a, b;

       a < b;
   }

A type is TComparable if it can be inserted in this block statement and pass the semantic phase.  In use it would be, say:

   $T min ($T first, $T [] rest...)
   predicate TComparable ($T)
   body
   {
       foreach ( ; i in rest; )
       {
           if (i < first)
               first = i;
       }
       return first;
   }

This is more powerful than Eiffel's syntax because you can include multiple arguments to the predicate and fail a set of types because of an incompatible interaction.  It could even include type arguments to act as specialisations.  So for example:

   predicate TMatrix4x4 (int $Rows, int $Cols)
   {
       assert ($Rows == 4 && $Cols == 4);
   }

   struct Matrix ($T, int $Rows, int $Cols)
   predicate TMatrix4x4 ($Rows, $Cols)
   body
   {
      /* Various SIMD functionality. */
   }

Burton Radons wrote:
> Predicate types - or type constraints - are supported by most generic systems that I've seen.  One way they could be in D is like this:
> 
>    predicate TComparable ($T)
>    {
>        $T a, b;
> 
>        a < b;
>    }
> 
> A type is TComparable if it can be inserted in this block statement and pass the semantic phase.  In use it would be, say:
> 
>    $T min ($T first, $T [] rest...)
>    predicate TComparable ($T)
>    body
>    {
>        foreach ( ; i in rest; )
>        {
>            if (i < first)
>                first = i;
>        }
>        return first;
>    }
> 

The problem I see with this approach is that you can add something to the body that is not tested in the predicate. So it would pass the test but could fail to instantiate for a specific type.

Before I give my sugestion I must say that I don't know anything about compilers. So anything I say can be impossible or unnecessary.

My sugestion is to use template interfaces:

interface TComparable($T) // $T is the self type
{
  int cmp( $T rhs );
}

And maybe a syntax like:

$T min ($T first, $T [] rest...)
use($T) TComparable
{
  ...
}

This means $T must implement that interface and in the body it would only allow the use of $T vars through interface defined calls.

$T search( $T first1, $T last1, $U first2, $U last2 )
use($T) TForwardIterator,
use($U) TForwardIterator
{
  ...
}

Extending the above example to be more restrictive we could do:

interface TComparable( $T, $U ) { // $T is self type
  int cmp( $U rhs ); // compare itself with another type
}

$T search( $T first1, $T last1, $U first2, $U last2 )
use($T) TForwardIterator,
use($U) TForwardIterator,
use(*$T, *$U) TComparable // TForwardIterator must provide a * op
{
  ...
}

The problem I see is with built-in types. I don't know how the operators relate to the overloadable methods.

Should this work?

int i = 0;
if ( i.cmp( 0 ) == 0 ) {
  printf("ok\n");
}

It doesn't compile in dli-0.1.2.

I also don't know how to check if they implement an interface. For it to work, interfaces should not need to be defined in the class (they could be to detect errors). They would have to be checked during compilation.

class X : TComparable { // ok X must implement cmp
  int cmp( X x );
}

class Y {
  int cmp( Y y );
}

TComparable c = (TComparable) Y; // ok Y implements cmp

So it would work for built-ins.

int i = 0;
TComparable c = (TComparable) i; // ok int implements cmp

Sugestions?
Opinions?

-- 
Marcelo Fontenele S Santos <msantos@pobox.com>

"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> wrote in message news:b08u26$2orh$1@digitaldaemon.com...
> Probably, the whole power of the C++ template
> mechanism was never actually planned.

It wasn't. I remember Bjarne's original template paper, and conversations with him about it. The original scheme was not much more than a glorified macro substitution scheme, and few thought it would be hard to implement <g>. There was no hint it would evolve into what it is today.

> Actually, the fact that it hides a
> complete language on its own was even found by accident.

Yes.

> And up to now, I
> guess nobody has really pinned down what the details are that make it so
> powerful. Guess it will take a good portion of genious to extract that
part
> without carrying over all the drawbacks...

I think the partial specialization is the real source of the power of templates.

"Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> wrote in message news:b0bej0$18bu$1@digitaldaemon.com...
> Dream on! Ingenious ideas have always suddenly sprung up from somewhere,
and
> the hardest part always was to recognize them as such. There are probably tons of ingenious ideas hidden in the discussions of this newsgroup,

You're right about that, and I've adopted more than a few into D.

> but in
> the end it will be the responsibility of Walter to pick out the good ones.

My worry is that some adverse combinations of features of D will box it into a corner.

> And that will always need some geniality on its own... :-)

Saying no to someone's proposed feature they expended a lot of thought and effort into presenting is really the hardest part of my task. I know how they feel, as not one of my proposed changes ever was adopted by the C++ standards people <g>. (And hence, the genesis of D.)