From: David Abrahams (dave_at_[hidden])
Date: 2002-07-29 14:28:14
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> > Until very recently, MWCW had a hard-coded limit on template nesting
> > If you want to support CWPro 7.2, you might need to use long type
> > in lieu of type lists just to avoid running into those limits. You can
> > as much loop unrolling as you want to; it won't help if you can't even
> > represent your inputs or results.
> Let's think we did not need to support bad compilers for a second. Would
> separation of data structures and algorithms still be a design decision
Weren't we just talking about how wicked good that compiler was <wink>?
Answer, regardless: yes.
> > > An s-expression is a tree alright. You wouldn't have to flatten it in
> > order
> > > to process it. LISP provides many examples of elegant tree
> > and
> > > all it uses as data structures is the dot list.
> > Yes, but you need to flatten it in order to *treat it as a sequence* if
> > of your sequence algorithms are hard-coded to work on slists.
> I'm completely at a loss. S-expressions *are* trees.
I know you're awfully smart, so I can only imagine you're playing dumb
here. Let me try again to illustrate:
Take any of your favorite typelist algorithm, e.g. the one that finds the
length of a sequence.
Now, without rewriting it, find the number of elements in a tree (not a
trivial, linear tree such as
typelist<x, typelist<y, typelist<z, null> > >
but something that's roughly balanced).
Now, pick another algorithm, say one that finds the largest type in a
sequence. Use that to find the largest element in a balanced tree.
> > Hmm, either way you now you have support for different data
> It's a wonder LISP programmers never felt the need for that... and they
> trees all the time.
Which lisp implementation are you talking about? I admit I'm not a bigtime
lisp guy, but the ones I know of all have vectors... oh, and properties,
too. That's another thing that moves the data structures away from pure
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk