Am 01.08.2011, 05:31 Uhr, schrieb Jonathan M Davis <jmdavisp...@gmx.com>:
We need to have all of the dmd and Phobos developers in triplicate. Then
maybe we could actually get everything done that we'd like to get done...
From reading what some C++ folks think is 'forced' on them in D (making
common things easy vs a low level structure covering all exotic use cases)
and my experience with the RedBlackTree (it is fast but, couldn't be
created empty as I am used to from other language libraries) I think it is
not just about getting things done, but about brainstorming in advance.
When we use containers, what use cases do we have? Programmer A wants to
be able to easily switch the container implementation from an array list
to a sorted tree, B requires pure speed without the overhead of virtual
functions and a class hierarchy. Either A or B give in, there is room for
both in Phobos or either A or B go and (re)write the containers. I believe
this discussion has been here already, but I wasn't reading the list at
that time. :)
So what I want to say is, before someone starts writing the code for a
parser generator, try to make a list of use cases. I don't say every use
case must be covered, but it would be great, if there were 'entry points'
for others to implement what they need. A common example is a sorted set
that sorts by the natural ordering of elements, but can be augmented with
a comparator function. So far we have the
- general idea of a lexer/parser
- a D source code parser
I'd be very exited to see a CTFE solution to building a parser *g*, you
know just for the awe of it. If that works out and it turns out that it is
actually quite fast it *could* be used to write a D parser from
definitions. But the point that you would want to keep close to the C
source of DMD is strong.
I wanted to write a disk cleanup tool for Linux that uses a simple special
script language basically using list operations (like list all java
processes -> list all files in directory x containing any processes pid ->
protect them from deletion). The format consists keywords that can open
new blocks that again contain other keywords, so I ended up writing parse
functions for each block type. I'd go with a complete AST here instead of
the linear list of tokens that has been proposed. If I wrote a syntax
highlighter then the AST would not be of much use. So this could be two
use cases to cover. Comments?
