> Conditional data structure building, although I can't think of a good example right now.  So I'll give a really bogas one.
>
> type BinaryTree(type T)
> {
>   if(T == int)
>   {
>     struct Tree
>     {
>       T data;
>       Tree left;
>       Tree right;
>     }
>
>     return Tree;
>   }
>   else
>   {
>     struct Tree
>     {
>       T data;
>       int  key;
>       Tree left;
>       Tree right;
>     }
>
>     return Tree;
>   }
> }

How about allowing compile-time conditionals outside of function context:

struct BinaryTree<$T>
{
      T data;
      cif ($T != int) { int  key; }
      Tree left;
      Tree right;
};

That's *very* close to the functionality of the current 'version' construct.

Sean

"Craig Black" <cblack@ara.com> wrote in message news:afaljg$2t64$1@digitaldaemon.com...
> > Conditional data structure building, although I can't think of a good example right now.  So I'll give a really bogas one.
> >
> > type BinaryTree(type T)
> > {
> >   if(T == int)
> >   {
> >     struct Tree
> >     {
> >       T data;
> >       Tree left;
> >       Tree right;
> >     }
> >
> >     return Tree;
> >   }
> >   else
> >   {
> >     struct Tree
> >     {
> >       T data;
> >       int  key;
> >       Tree left;
> >       Tree right;
> >     }
> >
> >     return Tree;
> >   }
> > }
>
> How about allowing compile-time conditionals outside of function context:
>
> struct BinaryTree<$T>
> {
>       T data;
>       cif ($T != int) { int  key; }
>       Tree left;
>       Tree right;
> };

Craig Black wrote:

> How about allowing compile-time conditionals outside of function context:
> 
> struct BinaryTree<$T>
> {
>       T data;
>       cif ($T != int) { int  key; }
>       Tree left;
>       Tree right;
> };

Ignoring whether or not this is a good idea for the moment,  I believe the syntax could be improved.  Instead of using many new keywords (cif, cswitch) we could use a single keyword to inform the compiler the statement should be resolved at compile time (it being an error if the statement is not resolved).  So your example would become:

option #1: statement
        struct BinaryTree<$T>
        {
                T data;
                compileTime if ($T != int) { int  key; }
                Tree left;
                Tree right;
        };
option #2: prefix operator
        struct BinaryTree<$T>
        {
                T data;
                if( resolve( $T != int ) ) { int key; }
                Tree left;
                Tree right;
        };
(actual keywords used are debateable)

option #2 should be easier to implement and may have uses elsewhere, such as mandating constant folding.

C 2002/5/26

"Patrick Down" <pat@codemoon.com> wrote in message
news:Xns92385BBDDAE20patcodemooncom@63.105.9.61...
<SNIP>
>
> I have a rather crazy idea.  What if we treated "type" as a type?
>
> type IntType = int;
>
> IntType b = 3;
>
> One of the things you could do with this is create functions that dealt with types.  Here is a function that builds a binary tree type.
>
> type BinaryTree(type T)
> {
>   struct Tree
>   {
>     T data;
>     Tree left;
>     Tree right;
>   };
>
>   return Tree;
> }
>
<SNIP>
>

I like this idea!
And it is not as crazy as you may think. In fact
I am pretty sure something like this is already
in Delphi. I think there it only works for class
types, however...Maybe Pavel can give us some
more insight to this, I think that he knows
Delphi pretty well.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Whichever is easiest to implement and give us the functionality we need. I'm not stuck on any particular keyword here.  In this case, we could just use the if keyword.  Since its outside function context, we can assume it will be resolved at compile time.  In this case there's really no way for the compiler NOT to resolve this conditional at compile time, unless we are dealing with an interpreted or JITed language.  This kind of conditional would sure help me with the C++ templates that I am maintaining right now.

struct BinaryTree<$T>
{
      T data;
      if ($T != int) { int  key; }
      Tree left;
      Tree right;
};

cblack01 wrote:

> Whichever is easiest to implement and give us the functionality we need.

And we want something which is simple to type, easy to figure out the meaning of, consistant with the rest of the language and an effective solution - C++ seams to just go for easy to implement and results in impossible to read syntax (though this may be a by product of the committe design process), we know D can do better.

> I'm not stuck on any particular keyword here.  In this case, we could just use the if keyword.  Since its outside function context, we can assume it will be resolved at compile time.

Probably, and that is what D does implicitly - adding a keyword would make resolving explicit.  In your example it would need to be resolved however if we had a similar construct within a function then some keyword would be needed to ensure,  for example...

int aFunc($T t) {
        if( $T == MyClass ) { ... do someting ... }
        else { ... do something else ... }
}

> In this case there's really no way for
> the compiler NOT to resolve this conditional at compile time, unless we
> are dealing with an interpreted or JITed language.

Or if the types compared are classes - then RTTI could come into play, which is not what we want in the above example.

>  This kind of conditional
> would sure help me with the C++ templates that I am maintaining right now.

Yes, though D version statements may be used to achieve a similar effect.

C 2002/6/26

On Wed, 26 Jun 2002 15:27:45 +0200 "OddesE" <OddesE_XYZ@hotmail.com> wrote:

> I like this idea!
> And it is not as crazy as you may think. In fact
> I am pretty sure something like this is already
> in Delphi. I think there it only works for class
> types, however...Maybe Pavel can give us some
> more insight to this, I think that he knows
> Delphi pretty well.

Well, I wouldn't say I know it very well, but I don't remember anything like this in Delphi.

Ada has a type type, if memory serves, so does ecmsScript 2.0 (not a proper standard jet, but it's in development).

I think the type type is an elegant solution that fits in with the rest of D, much better than C++ style templates do...

The other solution I can imagine fitting in with D syntactically, is to have a type that is a supertype of the primitives, structs etc, and objects, a bit like a void* but without being a pointer. To my mind however, it seems overly complicated.

-- 
Alix Pexton...

Webmaster, The D Journal
web: www.thedjournal.com
email:webmaster@thedjournal.com
"The D journal, a work in progress..."

OddesE <OddesE_XYZ@hotmail.com> wrote in article <afcenf$1bka$1@digitaldaemon.com>...
> "Patrick Down" <pat@codemoon.com> wrote in message
> news:Xns92385BBDDAE20patcodemooncom@63.105.9.61...
> <SNIP>
> >
> > I have a rather crazy idea.  What if we treated "type" as a type?
> <SNIP>
> >
> 
> I like this idea!
> And it is not as crazy as you may think. In fact
> I am pretty sure something like this is already
> in Delphi. I think there it only works for class
> types, however...Maybe Pavel can give us some
> more insight to this, I think that he knows
> Delphi pretty well.

"Alix Pexton" <Alix@seven-point-star.co.uk> wrote in news:01c21d38$e8680360$96497ad5@jpswm:

> Ada has a type type, if memory serves, so does ecmsScript 2.0 (not a proper standard jet, but it's in development).
> 
> I think the type type is an elegant solution that fits in with the rest of D, much better than C++ style templates do...
> 
> The other solution I can imagine fitting in with D syntactically, is to have a type that is a supertype of the primitives, structs etc, and objects, a bit like a void* but without being a pointer. To my mind however, it seems overly complicated.
> 

If you look in the D libary right now you will see that there is
( if I remember correctly ) a ClassInfo and a TypeInfo structure.
ClassInfo describes user defined classes.  TypeInfo is used more
internally to hold certain functions related to basic types and
to help implement dynamic arrays and such.  It would seem that
perhaps these two could be unified to make a standard type descriptor
for all types, basic and user defined.

On Wed, 26 Jun 2002 18:10:29 +0000 (UTC) Patrick Down <pat@codemoon.com> wrote:

> If you look in the D libary right now you will see that there is
> ( if I remember correctly ) a ClassInfo and a TypeInfo structure.
> ClassInfo describes user defined classes.  TypeInfo is used more
> internally to hold certain functions related to basic types and
> to help implement dynamic arrays and such.  It would seem that
> perhaps these two could be unified to make a standard type descriptor
> for all types, basic and user defined.

However, it's a run-time solution, as opposed to compile-time (and thus fast and easy to optimize) templates. Personally, I'd prefer to have both, but if I had to choose, I'd better have templates, because they allow to create a set of _fast_, mostly inline classes, encapsulating common algorithms (like STL).