I'm just waiting on some linker weirdies being divined by big-W.

Once that's done, I'll be mere hours (a couple of days at most) from release of 0.2. Currently slated for inclusion are:

 - D-like syntax for templates. (Less of the C++ influence <g>)
 - renamed collect() => transform()
 - renamed x_with() => xWith(), e.g. max_with() => maxWith()
 - Set class. Rudimentary as all hell - in that it uses a T[int] assoc array - but it is a fully fledged member of DTL
(i.e.
 - containers will be able to derive from parameterisable interfaces, e.g. IContainer!(int), which will make that
enumeration mode much more flexible
 - more general coverage of the various select() / transform() range operations over the breadth of DTL containers.
 - auto generation of the pseudo-recursive templates. (With Ruby, of course. <g>.)

I'm also hoping that one of the dfilter updates that've been posted of late will enable me to Doxygenate them into some rudimentary kind of help.

Future things, not to be included in 0.2:

 - "The DTL Vision" document
 - talking with Ben about how DTL and minTL might be merged
 - associative containers. How that exactly fits into the range stuff, I currently don't know because I've not thought
about it. I'm sure it will though ... (famous last words??)
 - putting all the ranges "smarts" into mixins
 - persuade Walter that recursive templates should be allowed.
 - associative containers
 - performance profiling and optimisation
 - algorithms and the like, for interface-based enumeration
 - Iterators???
 - applying DTL aspects to "real-world" containers, e.g. std.recls.FileSearch


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

" I fold like a cheap hooker who got hit in the stomach by a fat guy with sores on his face" -- Joey

-------------------------------------------------------------------------------

Matthew wrote:

>  - persuade Walter that recursive templates should be allowed.

Are they not? One rather fundamental argument you might try: If you talk about "meta-programming", this implies that you have a "meta-language". The meta-language of D is a purely functional language, with templates being the "functions" (executed at compile-time). Without recursion, a functional language has to way to express loops, so I doubt it would even be turing complete and deserve to be called "language"...

(Of course, this is a rather abstract argument, but it may relieve you from having to proove that in your special case there is no way avoiding recursion.)

Norbert Nemec wrote:
> Matthew wrote:
> 
> 
>> - persuade Walter that recursive templates should be allowed.
> 
> 
> Are they not? One rather fundamental argument you might try: If you talk
> about "meta-programming", this implies that you have a "meta-language". The
> meta-language of D is a purely functional language, with templates being
> the "functions" (executed at compile-time). Without recursion, a functional
> language has to way to express loops, so I doubt it would even be turing
> complete and deserve to be called "language"...
> 
> (Of course, this is a rather abstract argument, but it may relieve you from
> having to proove that in your special case there is no way avoiding
> recursion.)
> 

What I hate is that everyone here is 1000x smarter than me. Unless I'm not the only one.

----- Original Message ----- 
From: "Gold Dragon" <dragonwing@dragonu.net>
Newsgroups: digitalmars.D.dtl
Sent: Thursday, August 19, 2004 7:08 PM
Subject: Re: DTL 0.2 coming soon ...


> Norbert Nemec wrote:
> > Matthew wrote:
> >
> >
> >> - persuade Walter that recursive templates should be allowed.
> >
> >
> > Are they not? One rather fundamental argument you might try: If you talk about "meta-programming", this implies that you have a "meta-language". The meta-language of D is a purely functional language, with templates being the "functions" (executed at compile-time). Without recursion, a functional language has to way to express loops, so I doubt it would even be turing complete and deserve to be called "language"...
> >
> > (Of course, this is a rather abstract argument, but it may relieve you from having to proove that in your special case there is no way avoiding recursion.)
> >
>
> What I hate is that everyone here is 1000x smarter than me. Unless I'm not the only one.

There is not a single software engineer in the whole world who cannot be made to feel stupid (or at least lacking) in three sentences from another.

Presumably you'd think that Walter and myself were both reasonably cluey chaps? (I hope so, anyway!! <G>) Well I tell you, there've been many times over the last couple of years when we've discombobulated each other. That's just the game we're in.

The days of the Natural Philosopher - when a man could know all of science - ended 150-200 years ago. For IT, I would say that those days went the way of the Dodo in the 70s. As it stands now, the world of IT is so large, so diverse, and so complex, that it is downright impossible for anyone, and I mean _anyone_, to know but a small part of it.

So, worry not about your ignorance, for you're no more ignorant than anyone else. Just keep learning, and learn the lessons of your learning. :-)

Cheers

Matthew

P.S. Norbert's post impressed the hell out of me, also.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cg19b4$2sha$1@digitaldaemon.com...
> I'm just waiting on some linker weirdies being divined by big-W.
>
> Once that's done, I'll be mere hours (a couple of days at most) from
release of 0.2. Currently slated for inclusion are:
>
>  - D-like syntax for templates. (Less of the C++ influence <g>)
>  - renamed collect() => transform()
>  - renamed x_with() => xWith(), e.g. max_with() => maxWith()
>  - Set class. Rudimentary as all hell - in that it uses a T[int] assoc
array - but it is a fully fledged member of DTL
> (i.e.

T[int] ? really? Mine used int[T] but i swiched to T[].
Anyway, i'm looking forward to see set implemented as some tree (or
something simmilar)
with O(ln(N)) search and insertion times :)

>  - containers will be able to derive from parameterisable interfaces, e.g.
IContainer!(int), which will make that
> enumeration mode much more flexible
>  - more general coverage of the various select() / transform() range
operations over the breadth of DTL containers.
>  - auto generation of the pseudo-recursive templates. (With Ruby, of
course. <g>.)

All sound great, except the last one (wich i do not understand)

> I'm also hoping that one of the dfilter updates that've been posted of
late will enable me to Doxygenate them into some
> rudimentary kind of help.
>
> Future things, not to be included in 0.2:
>
>  - "The DTL Vision" document
>  - talking with Ben about how DTL and minTL might be merged
>  - associative containers. How that exactly fits into the range stuff, I
currently don't know because I've not thought
> about it. I'm sure it will though ... (famous last words??)
>  - putting all the ranges "smarts" into mixins
>  - persuade Walter that recursive templates should be allowed.
>  - associative containers
>  - performance profiling and optimisation
>  - algorithms and the like, for interface-based enumeration
>  - Iterators???
>  - applying DTL aspects to "real-world" containers, e.g.
std.recls.FileSearch
>
>
> --
> Matthew Wilson
>
> Author: "Imperfect C++", Addison-Wesley, 2004
>     (http://www.imperfectcplusplus.com)
> Contributing editor, C/C++ Users Journal
>     (http://www.synesis.com.au/articles.html#columns)
> STLSoft moderator
>     (http://www.stlsoft.org)
>
> " I fold like a cheap hooker who got hit in the stomach by a fat guy with
sores on his face" -- Joey
>
> --------------------------------------------------------------------------
-----
>
>
>

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cg1th4$1les$1@digitaldaemon.com...
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cg19b4$2sha$1@digitaldaemon.com...
> > I'm just waiting on some linker weirdies being divined by big-W.
> >
> > Once that's done, I'll be mere hours (a couple of days at most) from
> release of 0.2. Currently slated for inclusion are:
> >
> >  - D-like syntax for templates. (Less of the C++ influence <g>)
> >  - renamed collect() => transform()
> >  - renamed x_with() => xWith(), e.g. max_with() => maxWith()
> >  - Set class. Rudimentary as all hell - in that it uses a T[int] assoc
> array - but it is a fully fledged member of DTL
> > (i.e.
>
> T[int] ? really? Mine used int[T] but i swiched to T[].

Maybe it's int[T]. I'd have to check. LOL!

> Anyway, i'm looking forward to see set implemented as some tree (or
> something simmilar)
> with O(ln(N)) search and insertion times :)

Absolutely. I'm not focusing on implementations at all until we get nearer DTL 1.0. At the moment I'm more interested in interfaces, methodologies, etc. :)

Once we get to the performance-caring phase, I'll be plumbing the collective knowledge base. One thing I'm very keen on is that DTL kicks the arse of other generics libraries.

> >  - containers will be able to derive from parameterisable interfaces, e.g.
> IContainer!(int), which will make that
> > enumeration mode much more flexible
> >  - more general coverage of the various select() / transform() range
> operations over the breadth of DTL containers.
> >  - auto generation of the pseudo-recursive templates. (With Ruby, of
> course. <g>.)
>
> All sound great, except the last one (wich i do not understand)

Basically, D doesn't support recursive templates.

Since DTL containers provide transform() (and similar, e.g. select(), minWith(), etc.) methods, which filter the
contents of a container in the form of a "range" object. The range object type for the transform() method is
TransformedRange().

Since a very important aspect of this is to be able to compose multiple filters, the TransformedRange() template itself
provides the same transform() (and similar, e.g. select(), minWith(), etc.) methods, it returns TransformedRange1().
TransformedRange1()'s transform returns TransformedRange2(). And so on and so forth.

Since doing all that by hand is a total PITA, I'm doing auto-generated via a Ruby script. (Or I will be, anyway, in a day or so.)

Since I'm only doing 10 levels, there's a maximum composable depth of 10 filters. That sounds like more than we'd ever practically need, and it is a lot certainly, but we may be passing these intermediate ranges about other other functions, so it's conceivable we might exceed that. In which case, I guess DTL'd have to provide 20, 30, 50, 100, 1000?!?

Naturally, the only really elegant solution is if we have recursive templates, and I hope to have help in ganging up on big-W to that end. But for the moment I'll content myself with the hard-coded (or hard-generated, anyway) solution.

Ok this I understand... somewhat (who the hell is Ruby and where can I find her? :) jk).

So you want us to beat the MAN down? I don't know, I have a lot of respect for a guy who gets pimped out by every other Joe in here (another joke, I guess I should stop before a mob is called upon me). I certainly don't know enough general programming but I know that recursive is always good (i've never personally did any of it but I can see how you can't use a for or foreach loop for a template (or can you?).

I'll bring a bat with a nail at the end.

Jacob Santos

> 
> Basically, D doesn't support recursive templates.
> 
> Since DTL containers provide transform() (and similar, e.g. select(), minWith(), etc.) methods, which filter the
> contents of a container in the form of a "range" object. The range object type for the transform() method is
> TransformedRange().
> 
> Since a very important aspect of this is to be able to compose multiple filters, the TransformedRange() template itself
> provides the same transform() (and similar, e.g. select(), minWith(), etc.) methods, it returns TransformedRange1().
> TransformedRange1()'s transform returns TransformedRange2(). And so on and so forth.
> 
> Since doing all that by hand is a total PITA, I'm doing auto-generated via a Ruby script. (Or I will be, anyway, in a
> day or so.)
> 
> Since I'm only doing 10 levels, there's a maximum composable depth of 10 filters. That sounds like more than we'd ever
> practically need, and it is a lot certainly, but we may be passing these intermediate ranges about other other
> functions, so it's conceivable we might exceed that. In which case, I guess DTL'd have to provide 20, 30, 50, 100,
> 1000?!?
> 
> Naturally, the only really elegant solution is if we have recursive templates, and I hope to have help in ganging up on
> big-W to that end. But for the moment I'll content myself with the hard-coded (or hard-generated, anyway) solution.
> 
> 
> 

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:cg3am5$2k41$1@digitaldaemon.com...
> Ok this I understand... somewhat (who the hell is Ruby and where can I
> find her? :) jk).

Ruby is the hands-down best scripting language for people who wish both to use (it's very good, maybe not better than Python, though) and extend (no competition here; Ruby rocks) their scripting language.

Check out http://www.ruby-lang.org/, though there are many Ruby sites coming on.


> So you want us to beat the MAN down? I don't know, I have a lot of respect for a guy who gets pimped out by every other Joe in here (another joke, I guess I should stop before a mob is called upon me). I certainly don't know enough general programming but I know that recursive is always good (i've never personally did any of it but I can see how you can't use a for or foreach loop for a template (or can you?).
>
> I'll bring a bat with a nail at the end.

Nah, just some reasoned argument and some parfait.

:-)

>
> Jacob Santos
>
> >
> > Basically, D doesn't support recursive templates.
> >
> > Since DTL containers provide transform() (and similar, e.g. select(), minWith(), etc.) methods, which filter the
> > contents of a container in the form of a "range" object. The range object type for the transform() method is
> > TransformedRange().
> >
> > Since a very important aspect of this is to be able to compose multiple filters, the TransformedRange() template
itself
> > provides the same transform() (and similar, e.g. select(), minWith(), etc.) methods, it returns TransformedRange1().
> > TransformedRange1()'s transform returns TransformedRange2(). And so on and so forth.
> >
> > Since doing all that by hand is a total PITA, I'm doing auto-generated via a Ruby script. (Or I will be, anyway, in
a
> > day or so.)
> >
> > Since I'm only doing 10 levels, there's a maximum composable depth of 10 filters. That sounds like more than we'd
ever
> > practically need, and it is a lot certainly, but we may be passing these intermediate ranges about other other functions, so it's conceivable we might exceed that. In which case, I guess DTL'd have to provide 20, 30, 50, 100, 1000?!?
> >
> > Naturally, the only really elegant solution is if we have recursive templates, and I hope to have help in ganging up
on
> > big-W to that end. But for the moment I'll content myself with the hard-coded (or hard-generated, anyway) solution.
> >
> >
> >

On Fri, 20 Aug 2004 09:57:26 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:

<snip>

> Nah, just some reasoned argument and some parfait.

<quote>Everybody loves parfait</quote>

Regan

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

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opscz92iu45a2sq9@digitalmars.com...
> On Fri, 20 Aug 2004 09:57:26 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
>
> <snip>
>
> > Nah, just some reasoned argument and some parfait.
>
> <quote>Everybody loves parfait</quote>
>
> Regan
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

So've you also got Shrek-obsessed kids? (Or are you also a Shrek-obsessed kid?)

:-)