Howdy Doug,
Based on recommendations, I'm looking at the following decision tree after seeing a '['.
if lang = C++
if lang = Objective-C
if lookahead indicates lambda
parse_lambda
else if lookahead indicates message
parse_message
else
allocate lambda capture list
if tentative parse of lambda successful
finish_parse_lambda(list)
else
parse_message
else
parse_lambda
else if lang = Objective-C
parse_message
else
error
The parse_lambda and finish_parse_lambda functions will need to be different, although the first function could call the second.
Is it too much? Should I try something simpler? Should I try an alternative structure, like this:
if lang = C++ && lang != Objective-C
parse_lambda
else if lang != C++ && lang = Objective-C
parse_message
else if lang = C++ && lang = Objective-C
if lookahead indicates lambda
parse_lambda
else if lookahead indicates message
parse_message
else
allocate lambda capture list
if tentative parse of lambda successful
finish_parse_lambda(list)
else
parse_message
else
error
Should I wrap the lookahead and the tentative parsing into a single TryParse* function? Perhaps it could return a valid but unusable ExprResult upon parsing a lambda with unrecoverable errors, and an invalid ExprResult when lookahead or tentative parsing indicated a message. If that does not fit within the convention for invalid/usable, could you please explain it?
- John
Based on recommendations, I’m looking at the following decision tree
after seeing a ‘[’.
Hi John,
Slightly tangential, but given a recent thread on llvm-commits about CR size - I only recently subscribed to the cfe-commits list, so I might’ve missed any CRs you’ve sent out for this so far, but I was wondering if you’re sending this lambda work out incrementally as it sort of sounds like you’re working on one big patch (at least for the parser stage, for example) when it might be possible to break this up into some very small chunks which would help development, review, & might allow more collaborative work (ie: I’d like to be able to write some small parts of this work, perhaps, without going blind for large periods of time & duplicating your work).
For example, I was thinking of starting with parsing of only C++0x without ObjC support, as per the previous email thread we had going. And in that instance only parsing the simplest of C++0x lambdas possible: {} - then work could potentially continue in multiple directions, both enhancing the parsing to handle arguments, captures, return values - as well as going deeper & implementing some of the semantic analysis, etc, at the same time, in small steps.
Just some thoughts - realistically I’m not sure how much I’d be able to contribute to the effort, but thought these ideas might help.
I was
wondering if you're sending this lambda work out incrementally as it
sort of sounds like you're working on one big patch (at least for the
parser stage, for example) when it might be possible to break this up
into some very small chunks which would help development, review, &
might allow more collaborative work
I guess I thought parsing would be a small enough chunk. I've already got most of that done already, but I'll try to break my work into smaller pieces going forward.
For example, I was thinking of starting with parsing of only C++0x
without ObjC support, as per the previous email thread we had going.
I had submitted a patch for parsing lambdas last week with a small amount of disambiguation, and it got a comment that it would not be enough for the general case, so I just went ahead and tried to handle it.
- John