Ddbg 0.0.4 alpha release

[Jascha Wetzel]

> to do the latter, you can
> adjust the syntax to identify bracketed terms as casts if they're
> followed by an identifier and identify them as expressions if they're
> followed by an operator or nothing.

oh - it's even worse than i thought. even those little ddbg expressions
can't be parsed *at all* without semantic information:
is (asdf.qwer)(yxcv.fghj) a valid expression?
you can only tell if you know what asdf.qwer and yxcv.fghj are. it might
by (cast)(expr), (cast)(cast) or (expr)(expr). the first is ok, the
latter two are invalid in ddbg.

correct me if i'm wrong here, but these casts are also one root of evil
in c++, since expressions like (foo)(bar) aren't parseable without
semantic information about the identifiers involved. foo could evaluate
to an object that has the () operator overwritten, then (bar) is an
argument list. it could also be a class name, then (foo) is a cast and
(bar) is another expression.

this stuff is pandora's box - i won't open it ;)
we can have the {cast} syntax though, if you like. i can't possibly
think of anything else ddbg could ever need the curly brackets for. to
be sure we could also use something else:
§cast§
#cast#
:)

Jascha Wetzel wrote:
> the main reason i used the cast keyword is that it's faster and easier
> to parse.
> (asdf.qwer) can be interpreted as class/struct access or a cast to the
> type qwer in package asdf. to tell them apart you either need to know
> semantics, namely whether asdf and qwer are variables, types or
> packages, or you need arbitrary lookahead. to do the latter, you can
> adjust the syntax to identify bracketed terms as casts if they're
> followed by an identifier and identify them as expressions if they're
> followed by an operator or nothing.
> 
> atm the parser is a recursive descent LL(k) parser and not very fast.
> it's not even working in linear time. using syntax that makes use of
> arbitrary lookaheads will make it worse.
> considering that expressions will potentially have to be evaluated very
> often (open watch window while stepping through the code), i really want
> this to be as fast as possible and therefore use a LALR parser in some
> of the next releases, which doesn't allow arbitrary lookaheads.
> 
> so if you don't like the cast keyword for it's length, then i could add
> an alternative, shorthand syntax, that doesn't require arbitrary lookahead.
> for example: {char[][]}args. i guess ddbg expressions will never need
> the D meaning of curly brackets, so this will not collide at some point.
> 
> Bill Baxter wrote:
>> Jascha Wetzel wrote:
>>> slices are supported. in your example, the cast needs to be in brackets,
>>> though: (cast(int[])hugelist)[200..210]
>> Ah, ok.  I didn't think to try that for some reason.
>>
>> So what do you think about allowing C-style (or even better -- c++
>> style) casts?
>>
>> I think the various reasons they are not allowed in D do not really
>> apply to an interactive debugger.  The main thing you want in a debugger
>> is just something easy to type and read.  I think C++ function-style
>> casts fit the bill very nicely there.
>>
>> In Visual Studio for instance I find I often end up with ridiculous
>> looking watch expressions that are hard to read because of the cast syntax.
>>
>> Just a thought.  Basically idea is that the debugger cast syntax doesn't
>> *have* to look like the language syntax.  (Note that in Visual Studio,
>> for example, C cast syntax is all that's supported whether you're
>> debugging C or C++).
>>
>> --bb