[m-rev.] comments: non-blocking lex

Michael Day mikeday at bigpond.net.au
Mon Oct 15 13:04:52 AEST 2001


> Isn't this what spawn is for?

Sorry I forgot to say that the whole point of this was for situations in
which you do not wish to use multiple threads. (Or do not wish to use a
thread per lexer, at any rate).

> I'd be reluctant to complicate the interface to lex when a reasonable
> alternative solution already exists.

It is a complication, but not a huge one (one additional predicate). I
would prefer a solution in which you have either a blocking or
non-blocking lexer, depending on whether you create it with a blocking or
non-blocking read predicate, which is arguably safer or at least makes
more explicit the intention of the caller. But the patch for that would be
significantly more complicated and probably just involve duplicating most
of the interface, which doesn't seem worth it.

> I've never been that happy with lex__manipulate_source/3.  It is useful
> when lexing IO streams, but for strings etc. it's not entirely clear to
> me what the manipulating predicate should see.  Right now, for strings,
> you see the entire string as provided to lex__start/2.  Perhaps it would
> make more sense to just see the remainder of the string that has not been
> parsed by the lexer.  However, the solution should also work for lists
> etc.  Perhaps a typeclass based solution would be better.

It's ambiguous because lex duplicates some functionality itself with the
buf type that maintains a buffer and an offset. If lex was restricted to
lexing stream type things (io streams, lists, string streams when we have
them) then I think the interface could be made more consistent.

Michael

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list