> And of course that syntax would not work because it takes the second and
> third interfaces as new parameters :).

And then comes the joy of my suggested way of doing it... it opens up this possibility:
	template foo (T : Interface1 && Interface2 && Interface3)
-or-
	template foo (T : Interface1 and Interface2 and Interface3)

Although after looking at it I started wondering about my (signed && enum) trick... I don't think it would be good, at least not that way.  I get stuck wondering how to interpret something like (signed && struct)... What would make a /struct/ "signed" or "unsigned"??  So it could lead to ambiguity, and nobody likes ambiguity... okay well some of the time.

-Chris S.
-Invironz

"Sha Chancellor" <schancel@pacific.net> wrote in message news:schancel-A163D2.18113529072004@digitalmars.com...
> In article <cebp7v$1pt7$2@digitaldaemon.com>,
>  "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>
> > "Sha Chancellor" <schancel@pacific.net> wrote in message news:schancel-C6DC99.10061329072004@digitalmars.com...
> > > Matthew,
> > >
> > >    Compiler bugs aside, you forté make a few silly arguments.  Such as,
> > > that you can't support iterators because you can't overload the *
> > > operator.  What kind of BS is that?
> >
> > I said "Neither of these preclude the creation of iterators - and I've done a little of that - ".
> >
> > Maybe you should have read it more thoroughly. :-(
>
>
> No, but you did say : "D cannot support generic programming." Presumably, you were griping about it.  Also, you said "it means they're not really very usable."   Please elaborate.

They require explicit instantiation. That's not very usable.

> > > Overloading operators for no apparent good reason is STLs forté.  Obj-C and Cocoa have lots of templates and it doesn't have any operator overloading what-so-ever.
> > >
> > > STLs and C++ use operator overloading incessantly  because somehow their designers thinks it looks cool.
> >
> > Wrong. (Or half wrong anyway). They overload the operators for conformance
> > with pointers. Surely you know/recognise that
> > a pointer is a RandomAccess iterator?
>
> An iterator class is still a class, not a pointer. End of story.  Don't confuse syntax for types with needless philosophical semantics.

I have no idea what this means. I haven't said a class is a pointer.

> And a pointer is not a RandomAccess iterator, although it might be a random access iterator....

Are you kidding here? I don't get the point of saying this, unless you're attempting to be funny.

> > It's been my opinion - espoused often on the D ngs over the last year or so -
> > that we don't need to directly support
> > pointers as "first class" members of the enumerable club in D, since D's
> > arrays (and any UDTs) are already enumerable
> > via foreach().
> >
> > This has been one of the motivating factors in my design toward a
> > foreach-oriented library, with the consequences that
> > two of the four of the enumeration "modes" / "models" in DTL are based on
> > foreach.
>
> Where are you going with this?

No idea. You've cut out your part of the thread to which I was responding.

> >
> > >   IT confuses whether or not an iterator
> > > is a pointer or an object.  Why not just have a real function call:
> >
> > Pointers, as explained above.
>
> Classes, as explained above.

You were talking about STL, which is in C++, and which supports pointers. Are you suggesting that STL should not support pointers, or are you trying to rewrite the history of this thread to make it seem you were talking about D's iterators, which, as I've been saying for the best part of 12 months, are classes.

Seems to me like you're just attempting to be smart/argumentative for the sake of it. Maybe it's me ...

> >
> > > Iterator.getMyFuckingInstanceNow()
> >
> >
> > Yes. The iterators I've played with have taken this approach.
>
> It makes the implementation more clear for novice programmers.

Agreed. (Thank god!)

> >
> > > No instead we must confuse things by going (*Iterator)
> > >
> > > Iterators in STL suck, plain and simple.  Most of C++'s standard template library is overly complicated and obtuse for the job.  Not to mention buggy between implementations.
> >
> > At the risk of pissing off YAA, I think this is naive. (Aside: pretty much
> > everyone in the world apart from fellow
> > Englishmen tend to get shirty if I mention the "n" word. For my part, it's
> > much less offensive to have one's opinion
> > called naive, than ill-informed, or half-considered, or plain dumb. So naive
> > it is.)
>
> Which part of overly complicated, obtuse, and buggy between implementations is naive and ill-informed?

You said "Iterators in STL suck, plain and simple". That is the part I did describe as naive, and which I now describe as ignorant. Let's hope we don't have another round and go for stupid.

> It doesn't matter if you
> have a special method to tie my shoes if I don't know about it, or can't
> remember how to use it.  Especially when I can tie my own shoes, I'll
> probably just go do that, rather than look up your auto-shoe-lace-tier.
>
>
> > Yes, C++'s library is complex, and it's going to get a lot more so in C++-0.x.
> >
> > Yes, templates are hard to understand, and template implementations are
> > virtually impossible not to become dialecticised
> > (?). Consider, even though I value simplicity in templates more highly than
> > pretty much any other aspect, I've done some
> > reasonably complex things with STLSoft, and some people have commented that
> > that stuff is pretty
> > advanced/over-complicated/obtuse/cool/stupid. Point being, I understand the
> > complex techniques I've used in STLSoft, but
> > I cannot understand the implementation of even small Boost modules, for the
> > same reason that some Boosters cannot
> > understand STLSoft: C++ is too complex.
>
> Boost is too complicated too.

Agreed. I would say too complex, but for the fact that a Booster might legitimately level the same at STLSoft

> > But, C++ is powerful, and that's why we stick with it. To stand on the
> > sidelines and just shout about how hard it is is
> > plain silly, until something replaces it. I don't think I speak out of turn
> > to say that Walter would like that to be D.
> > To achieve that D *must* support the currently unmatched power of C++. The
> > other issues are (i) whether it becomes as
> > hard, and (ii) whether it engenders the confusing and disenfranchising
> > dialectisation (?) of C++. I my opinion we can
> > live with (i) if we must, because most developers are reasonably intelligent.
> > But (ii) will kill it, because learning
> > limitless dialects is incredibly irritating and a waste of effort. If D ends
> > up being as big a bag of wild-woman's
> > knitting as C++, then what's the motivation to move to D?
>
> As I would like to see D become also.

Goodo

> > [Apologies to any wild-women who have neat knitting.]
> >
> > > As for implicit instantation,  Why is this required to make an iterator?
> >
> > Sigh. Either I have all the didactic talent of your average post-graduate
> > tutorial host, or you've not read my post
> > correctly.
> >
> > What I said was that to use iterators generically, and without iterators
> > sharing a common interface (e.g.
> > IObjectEnumerator, or IEnumerator!(int)), we need implicit instantiation.
>
>
> Explain why this would help please.

There's no implicit instantiation. So to use an iterator class with a "generic" algorithm either means that one uses a template algorithm and explicitly instantiates its type, or one uses a non-template algorithm that manipulates via an interface and passes only types that inherit from that interface to it.

The DTL containers can all inherit from an otherwise defaulted second template parameter, which defines their "parent" interface, as in:

    Vector!(int, IObjectContainer)    v;
    List!(int, IObjectContainer)        l;

Now v and l are both polymorphically related about the IObjectContainer interface, and either can be passed to a function that knows how to use an IObjectContainer.

    dump(IObjectContainer c);

    dump(v);
    dump(l);

The self same thing would apply to iterators. We would define iterator interfaces, either Object-based (i.e.
IObjectIterator), or parameterised (e.g. IIterator!(int), from which our containers' iterator classes would derive.
Let's say we'll derive the iterator classes for List!(T) and Vector!(T) from IIterator!(T), thus:

    int accumulate(IIterator!(int) from, IIterator!(int) to, int initial);

    int     r1    =    accumulate(v.begin(), v.end(), 0);
    int     r2    =    accumulate(l.begin(), l.end(), 0);

But this is not generic programming, or at least not as I understand the term. accumulate() is not a generic algorith,
it is a specifi function, whose non-template parameters are the type IIterator!(int). To accumulate BigInts, or doubles,
we'd need another implementation of accumulate() for each.

Of course, one could take the next step, and get almost all the way there,

    template accumulate(T) { T accumulate(IIterator!(T) from, IIterator!(T) to, T initial)
    {
        . . . accumulation ...
    }}

    Vector!(BigInt, IObjectContainer)    v;
    List!(double, IObjectContainer)        l;

    BigInt      r1    =    accumulate!(BigInt)(v.begin(), v.end(), new BigInt(0));
    double     r2    =    accumulate!(double)(v.begin(), v.end(), 0.0);

But this is still not generic programming. There are several problems:

1. One must specify the type in the explicit parameterisation of accumulate(). This can be considered a minor problem in
most cases
2. The processing is necessarily inefficient, because it's using virtual functions to access the elements, via the
interface
3. The definition and use of accumulate!() is effectively tied to IIterator!(). Try incorporating another accumulate!()
based on another interface into the mix!
4. There is no mechanism - or at least I've not thought of one - for short-circuiting operations based on the iterator
refinement. In other words, how do we get a random access iterator class to do an efficient distance()? (Actually, I'm
having some ideas now ... but it's likely to be nasty stuff.)


> >
> > > Maybe I'm missing the boat, but what's wrong with something like this:
> > >
> > > class List(T) {
> > >    alias ListIterator(T) iterator;
> > >
> > >    ...
> > > }
> > >
> > > List!(int).iterator iter;
> > > // Hell you could probably even take your existing instance and do:
> > > // Foo.iterator iter;  In fact you should be able to but it seems you
> > > can't  This would allow you to also do aliases for stuff like:
> > >
> > > iter.BaseType t; and do your generic manipulation functions. or List.BaseType; etc.  And have aliases in your class.
> >
> > This kind of thing is already done. One can (or at least could - I've changed
> > a lot of things since April, when I last
> > built and tested with -version=UseIterators) do things such as:
> >
> >     List!(int)    l = new ...
> >
> >     for(List!(int).iterator b = l.begin(), e = l.end(); b != e; b.next())
> >     {
> >         int i = b.value();
> >     }
> >
> > But one cannot do something such as
> >
> >     int j = accumulate(l.begin(), l.end(), 0);
> >
> > To do this, one has to provide the type(s), as in:
> >
> >     int j = accumulate!(List!(int).iterator, int)(l.begin ...)
> >
> > [Actually, since all iterators must be classes, I've prescribed that they all
> > have a standard set of member types, so
> > it's possible to deduce the value type, as in:
> >
> >     int j = accumulate!(List!(int).iterator)(l.begin ...)
> > ]
> >
> > Given that the (currently) only useful mode for iterators is where the type
> > is explicit, it's my opinion (and that of
> > others, I think) that there's no benefit over foreach, hence the focus on
> > foreach for the container enumeration, and the
> > enumeration of transformed ranges, as in:
> >
> >     foreach(int i; l)
> >     {
> >         . . .
> >     }
> >
> > and
> >
> >     foreach(int i; l.select(IsOdd))
> >     {
> >         . . .
> >     }
> >
> > >
> > > I say we bitch at walter.
> > >
> > > for( iter = myList.begin();  iter != myList.end(); iter++ )
> > > {
> > >    printf(iter.getMyFuckingInstanceNow().toString());
> > > }
> > >
> > > This is nearly identical to what C++ does, and i really don't see why it wouldn't work.
> >
> > It can work. It does work. I've mentioned this many times on the NGs.
> >
> > >  You could probably leave the instance-getter function
> > > name a little shorter though.
> >
> > D'ya think?
> >
> > > Maybe you could expand as to why this sucks? (Besides that it's similar
> > > to STL which sucks)
> >
> > Again, a pointless comment that suggests ignorance, or a fondness for glib
> > statements at best. STL is a mostly
> > marvellous idea/technology, but the bits of it that are bad are glaringly
> > bad. It does not suck, it's the current best
> > effort at powerful generic programming. Just because something has bad parts
> > doesn't mean it sucks. If that's the case,
> > then everything sucks.
> >
> > It's my hope and, I would think, that of most people in D, that DTL can be
> > (nearly) as powerful as STL, but jettison
> > most of the glaringly bad parts. I don't expect DTL to be without flaws, but
> > it needs to be simpler, and less prone to
> > spawning dialects, than STL. And it needs more power than the language
> > currently provides.
>
>
> STL is more overloaded and bulky than most things need.

Agreed.

> > > And as for your template example:
> > >
> > >
> > > #    template dump(T) {
> > > #    void dump(IContainer!(T) c)
> > > #    {
> > > #        for(IEnumerator e = c.enumerate(); e.hasMoreElements; )
> > > #        {
> > > #
> > > #        }
> > > #    }
> > > #    }
> > > #
> > > #    List!(int, IContainer!(int))           l = new ...;
> > > #
> > > #    dump(l);
> > >
> > > For one, making those aliases all over is just as ugly and hard to remember as just specifying it.  Second:
> > >
> > > You're passing in l of type List!(int, IContainer!(int)), and then
> > > proceed to do this with it:
> > >
> > > IContainer!(List!(int, IContainer!(int))) c.
> > >
> > > Is that really what you were intending to do?
> >
> > I'm afraid I can't follow the last section. Can you rephrase?
>
> Never mind, the way you used templates there is a bit odd.  Let me see if I've got this correct:
>
> Since you've got a function with the same name as the template some magic happens here presumably.
>
> dump( List!(int, IContainer!(int)) );
>
> Would be equivalent to:
>
> dump!(int).dump( List!(int, IContainer!(int)) );
>
> in this case? And List!(int, IContainer!(int)) would be seen as a
> IContainer!(int) due to the specified interface?

Walter has chosen to allow (in fact it's mandate, which is an irritation all its own) templates with only one member,
whose name is the same as the template, to be specified without the qualification. i.e. one specifies List!(int), rather
than List!(int).List.

> > > It seems like templates should support something along these lines:
> > >
> > > #   template dump( T : IContainer!(T) ) {
> > > #      void dump( IContainer!(t) ) {
> > > #      }
> > > #   }
> > >
> > > Although I seriously doubt that works as it is.
> >
> > What's "t"? If you mean "T", then I presume the different you're providing is
> > the constraint on T to be "in" an
> > IContainer!(T)?? Doesn't the function signature already do that? Please
> > elucidate.
>
> I'm sorry, I made a capitalization error.

No worries. That's what I figured.

> Yes I would be constraining it to be in an IContainer, But also you would then deduce the template's type via template specialization.  Then you could use the base type.  But yes, it looks like your example already does that, I overlooked it.

No worries.

I think in addition to simple properties like:
  template foo(T : struct)

A whole new thing should be used to specify several, like an interface but not, i.e.

requirements Bob {
  interface Interface1,..
  typeof ParentClass,..
  type unsigned,..
}

template foo(T : Bob)

so Bob contains declarations about the type eg, it's type, what interfaces it must support, even what it's derived from. all optional of course.

I am not suggesting a syntax. Simply that we might want to group requirements, give them a name and re-use them all over the place.

Regan

On Thu, 29 Jul 2004 14:37:15 -0500, C. Sauls <ibisbasenji@yahoo.com> wrote:
> Walter wrote:
>> I hadn't realized that structs and classes cannot be discriminated in
>> template specialization, you're right. How does the following look:
>>     template foo(T : struct)
>> and:
>>     template foo(T : class)
>> ?
>
> Looks promising to me... how likely would the following be, as well?
> 	template foo(T : signed)
> 	template foo(T : unsigned)
> 	template foo(T : enum)
>
> I figure the more ways to narrow down the parameters, the better.  Maybe templates could be further revised to have complex filters, such as:
> 	template foo(T : struct || (signed && enum))
>
> This would take as parameter wither a struct, or an enum that derived from a signed type (byte,short,int,long,cent..).  It would reject anything else, including an /un/signed enum (enum : ubyte,ushort,uint,ulong.ucent..).  The use of conditional operators is arbitrary, I guess anything could be used... maybe even new 'or' and 'and' keywords that are template-only.
>
> But I'm sure a certain amount of this is dreaming on my part.  :)
>
> -Chris S.
> -Invironz



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Walter wrote:

> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:cec0fl$1t7c$1@digitaldaemon.com...
> 
>>I'm with Sean on this one. Since D doesn't have implicit instantion, how
> can an accumulate template be instantiated as
>>shown above?
> 
> 
> Can you post a complete example, and I can verify whether it is fixed or
> not.

Just to be pedantic:

# template accumulate( Iter, ValT )
# {
#     ValT accumulate( Iter begin, Iter end, ValT val = ValT.init ) {}
# }
#
# // what Matthew wants
# char* b, e;
# accumulate( b, e, 0 );
#
# // what we've got to do
# accumulate!(char*, char)( b, e, 0 );

So in this case it's not a bug but a language issue :)


Sean

In article <cebr2j$1qic$1@digitaldaemon.com>,
 "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote:

> "Walter" <newshound@digitalmars.com> wrote in message news:cebikp$1mh0$1@digitaldaemon.com...
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:ceaeid$18ir$1@digitaldaemon.com...
> > > Alas, this crashes the compiler. Sigh ...
> >
> > That's my problem, send me the test case!
> 
> That's my problem. There is no test case. There's the DTL implementation. I
> don't know that I have the skill to trim it
> down, but I'm absolutely sure I don't have the time.

I think Walter was implying (maybe not on that line of text, but elsewhere) that if you have anything that elicits bad behavior in the compiler -- regardless of how much trimming it may need -- then you have a test case.

> I really think you need to come up with a better way to diagnose flaws in the
> compiler, such that we can just send you
> dumps. You're a super smart guy. I know you can do this. And I reckon this'll
> save masses of time all round in the long
> run

Well, ok, but how practical is it for walter to sift through voluminous debugging output to try to find a bug whose general case (i.e., the boiled-down version that elicits the buggy behavior) is some phantom about which we have no substantial clue?  Without an example (*any* example, even if it can't be boiled down), it's difficult (if not impossible) to know what to look for.  What kind of turnaround time could we then expect for bugfixes?

Come to think of it, we probably wouldn't speak of a "turnaround time for bugfixes," because there would only be one bug, and it would consume all of Walter's time.  It would become known simply as "The Bug." Hopefully we would see it, and the next DMD point release, sometime before the ISO C++ committee releases the next Standard. :-)

Seriously though, how can anyone reasonably expect to solve a problem this complex without stepping into the compiler's code with a debugger? Suppose Walter finds a bug without a D source sample; how can he know whether it was the right one? And how can he know if he's solved the general case?

All of these reasons, and possibly more, are why Walter gave this succinct response:

> > Trust me, sending me dumps would be quite useless.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:cec85j$204l$1@digitaldaemon.com
| "Carlos Santander B." <carlos8294@msn.com> wrote in message
| news:cec3is$1ug7$1@digitaldaemon.com...
|| There's a question coming: could it be possible that you're trying to achieve
|| too much?
|
| It's certainly likely that I've tried to achieve too much in the first
instance.
|
| But, no, I do not believe the DTL "vision" is overblown. In fact, I think it's
| really neat, easily explained, and self-contained. (But then I would think
that, I
| suppose)

I meant that in the context of what followed.

|
|| I know it's a bit late for it, but do you think it could've been
|| easier if you had done first this, then that, etc.? Just asking.
|
| Most certainly.
|
|| About your boxing module, did you know Andy wrote that some time ago? I
haven't
|| tested it, but I know it exists.
|
| No. Where is it? How to I get it? I'd like to get a look at that.
|
| btw, do you mean Andy Friesen? Andy, want to knock heads together on this?
|
| Mine was just a stab to get me what I needed, and was not intended to be the
| all-things-for-all-men (or women!) approach. However, I thought it might serve
as
| a base for that.

Yes, Andy Friesen indeed. It's part of his apropos library, available at http://andy.tadan.us/d/.

|
|| About your first litany, I agree with you. Sometimes something's working, and
|| you add just one tiny correct thing, and the compiler gets lost. Sometimes
just
|| reorganizing modules makes everything stop working. And it's certainly
|| impossible to reproduce it.
|
| Hurrah! So it's not just me, then.
|
|| Besides that, I just can say don't give up. DTL looks very promising and I
don't
|| think any of us would like to lose it (and you) at this point.
|
| Thanks. I confess I've been skirting the throwing-the-towel-in point over the
last
| couple of weeks. Thankfully, the gritty Yorkshireman in me jumped out and gave
me
| a kick up the arse. :)

No problem.

|
|
|| And release
|| something. I'm not saying I'm going to help (I'm not saying I'm not, either),
|| but, who knows, with luck everyone will stop what they're doing and check DTL
|| and suggest things.
|
| Ok, arm-twisters all. I shall release 0.1 this weekend. It will only have type
1
| ("foreach") enumeration capabilities for each container, although some of the
| other enumeration types will be available for some of the containers. Then we
can
| take it from there.
|
| (btw, the actual "containment" implementations were all done in a couple of
days
| in March, so they may not be optimal. That doesn't matter of course, but I
just
| don't want anyone to think that any aspects of the lib are production-ready
yet.)

I think most of us will be happy with that.

-----------------------
Carlos Santander Bernal

Wow.  That's an awesome idea.  I second it!!

-Owen

In article <opsbxg00bk5a2sq9@digitalmars.com>, Regan Heath says...
>
>I think in addition to simple properties like:
>   template foo(T : struct)
>
>A whole new thing should be used to specify several, like an interface but not, i.e.
>
>requirements Bob {
>   interface Interface1,..
>   typeof ParentClass,..
>   type unsigned,..
>}
>
>template foo(T : Bob)
>
>so Bob contains declarations about the type eg, it's type, what interfaces it must support, even what it's derived from. all optional of course.
>
>I am not suggesting a syntax. Simply that we might want to group requirements, give them a name and re-use them all over the place.
>
>Regan
>
>On Thu, 29 Jul 2004 14:37:15 -0500, C. Sauls <ibisbasenji@yahoo.com> wrote:
>> Walter wrote:
>>> I hadn't realized that structs and classes cannot be discriminated in
>>> template specialization, you're right. How does the following look:
>>>     template foo(T : struct)
>>> and:
>>>     template foo(T : class)
>>> ?
>>
>> Looks promising to me... how likely would the following be, as well?
>> 	template foo(T : signed)
>> 	template foo(T : unsigned)
>> 	template foo(T : enum)
>>
>> I figure the more ways to narrow down the parameters, the better.  Maybe
>> templates could be further revised to have complex filters, such as:
>> 	template foo(T : struct || (signed && enum))
>>
>> This would take as parameter wither a struct, or an enum that derived from a signed type (byte,short,int,long,cent..).  It would reject anything else, including an /un/signed enum (enum : ubyte,ushort,uint,ulong.ucent..).  The use of conditional operators is arbitrary, I guess anything could be used... maybe even new 'or' and 'and' keywords that are template-only.
>>
>> But I'm sure a certain amount of this is dreaming on my part.  :)
>>
>> -Chris S.
>> -Invironz
>
>
>
>-- 
>Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Matthew wrote:

> No. Where is it? How to I get it? I'd like to get a look at that.
> 
> btw, do you mean Andy Friesen? Andy, want to knock heads together on this?
> 
> Mine was just a stab to get me what I needed, and was not intended to be the all-things-for-all-men (or women!)
> approach. However, I thought it might serve as a base for that.

Yeah, that's me.  I put a copy online at <http://andy.tadan.us/d/variant.d>

It's about as simple as it can get. :)

 -- andy

C. Sauls wrote:

>> And of course that syntax would not work because it takes the second and
>> third interfaces as new parameters :).
> 
> 
> And then comes the joy of my suggested way of doing it... it opens up this possibility:
>     template foo (T : Interface1 && Interface2 && Interface3)
> -or-
>     template foo (T : Interface1 and Interface2 and Interface3)
> 
> Although after looking at it I started wondering about my (signed && enum) trick... I don't think it would be good, at least not that way.  I get stuck wondering how to interpret something like (signed && struct)... What would make a /struct/ "signed" or "unsigned"??  So it could lead to ambiguity, and nobody likes ambiguity... okay well some of the time.

Say we decide on some operations that can be done on types:

    T1 == T2 - T1 and T2 are the same type
    T1 >  T2 - T1 is a subclass of T2? (iffy.  T1 is a superset of T2)
    T1 >= T2 - subclass or equal
    D in T   - declaration D is a member of instances of T
    T :  TE  - T is deduced from type expression TE

Then we can borrow a little from C#, a little from ML, and do something like this:

    template ComplexTemplateThing(A, B, C, D)
        where
            A > Stream && // A must extend stream
            B > struct && // B "extends" struct
            void opApply(inout char[]) in C && // C instances must have an opApply method

            D : null[null] // specialization: 'null' matches all types.
                           // (ML uses _ the same way)
                           // Type D can be any associative array
             ||            // or
            D : C[]        // permit D to be an array of C
    { ... }

The only problem is that we've started turning into Lisp all over again. :)

 -- andy

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:cecbh5$21hg$1@digitaldaemon.com...
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
> news:cec85j$204l$1@digitaldaemon.com
> | "Carlos Santander B." <carlos8294@msn.com> wrote in message
> | news:cec3is$1ug7$1@digitaldaemon.com...
> || There's a question coming: could it be possible that you're trying to achieve
> || too much?
> |
> | It's certainly likely that I've tried to achieve too much in the first
> instance.
> |
> | But, no, I do not believe the DTL "vision" is overblown. In fact, I think it's
> | really neat, easily explained, and self-contained. (But then I would think
> that, I
> | suppose)
>
> I meant that in the context of what followed.

No worries. :)

> |
> || I know it's a bit late for it, but do you think it could've been
> || easier if you had done first this, then that, etc.? Just asking.
> |
> | Most certainly.
> |
> || About your boxing module, did you know Andy wrote that some time ago? I
> haven't
> || tested it, but I know it exists.
> |
> | No. Where is it? How to I get it? I'd like to get a look at that.
> |
> | btw, do you mean Andy Friesen? Andy, want to knock heads together on this?
> |
> | Mine was just a stab to get me what I needed, and was not intended to be the
> | all-things-for-all-men (or women!) approach. However, I thought it might serve
> as
> | a base for that.
>
> Yes, Andy Friesen indeed. It's part of his apropos library, available at http://andy.tadan.us/d/.
>
> |
> || About your first litany, I agree with you. Sometimes something's working, and
> || you add just one tiny correct thing, and the compiler gets lost. Sometimes
> just
> || reorganizing modules makes everything stop working. And it's certainly
> || impossible to reproduce it.
> |
> | Hurrah! So it's not just me, then.
> |
> || Besides that, I just can say don't give up. DTL looks very promising and I
> don't
> || think any of us would like to lose it (and you) at this point.
> |
> | Thanks. I confess I've been skirting the throwing-the-towel-in point over the
> last
> | couple of weeks. Thankfully, the gritty Yorkshireman in me jumped out and gave
> me
> | a kick up the arse. :)
>
> No problem.
>
> |
> |
> || And release
> || something. I'm not saying I'm going to help (I'm not saying I'm not, either),
> || but, who knows, with luck everyone will stop what they're doing and check DTL
> || and suggest things.
> |
> | Ok, arm-twisters all. I shall release 0.1 this weekend. It will only have type
> 1
> | ("foreach") enumeration capabilities for each container, although some of the
> | other enumeration types will be available for some of the containers. Then we
> can
> | take it from there.
> |
> | (btw, the actual "containment" implementations were all done in a couple of
> days
> | in March, so they may not be optimal. That doesn't matter of course, but I
> just
> | don't want anyone to think that any aspects of the lib are production-ready
> yet.)
>
> I think most of us will be happy with that.

Hope so.