Hi, Vojtech,
Vojtech Horky on 2012-08-06:
> 2012/8/4 Sean Bartell <[email protected]>:
> > I've implemented conditions and repetition in Bithenge[0]. There are
> > more examples in the test files[1].
> I have two more comments and one question.
>
> First, if you specify an unknown field in a switch (run with hex:00)
> transform main = struct {
> switch (.non_existent) {
> 1: { };
> else: { };
> }
> };
> Bithenge would enter some endless recursion and eventually die.
The problem is that in order to find ".non_existent", Bithenge tries to
figure out whether the "switch" generates ".non_existent", which means
it has to find ".non_existent". I've added this to the future feature
list, even though it's more of a bug than a feature.
> Next, I have a suggestion on error reporting. Right now, any error is
> reported via its number only. If you have an error in your script
> (logical, not syntactical), printing stops somewhere in the middle
> with "invalid value" or similar, giving almost no hint what is the
> root cause.
> Do you think you can improve that somehow? Either by defining more
> fine-grained error codes or returning bigger context or ...?
I think the solution would be to put some sort of error information in
the bithenge_scope_t. I've also added this to the future feature list.
> Last thing - do you think it would be possible to support recursive
> structures? At least a simple variant that a structure can reference
> itself? I am not sure that it is possible at all with current design
> but it might be a natural way of describing some data...
> What I have in mind is this:
> transform recursive = struct {
> .have_next <- nonzero_boolean <- uint8;
> .data <- whatever;
> if (.have_next) {
> .next <- recursive;
> }
> }
Well, this case could be handled with do...while:
transform recursive = do {
struct {
.have_next <- nonzero_boolean <- uint8;
.data <- whatever;
}
} while (.have_next);
Other cases would still need recursion, and it wouldn't be too hard to
implement, so I've added it to the future feature list.
Thanks,
Sean
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel