On Sat, Dec 16, 2000 at 02:27:24AM -0500, Dan Sugalski wrote:
> Okay, it's time to try again, and this time I think it's best to skip the
> specifics of parameters and suchlike things.
>
> How do we want the parser/lexer/tokenizer piece to work, and what sorts of
> hooks do we want to provide to folks to wedge things in? (Keeping in mind
> the input is source, and the output is a syntax tree)
Everyone is quiet.
I'm assuming we're all sort of thinking that input is certainly
(I will have failed to mention some things)
* human readable programming language source (perl5, perl6, whatever else)
* bytecode (which could be done as in perl5.6 with something like
use Byteloader;......)
and the above can come from
* memory (C's zero terminated strings, blocks with lengths, other things
native to other languages
* files (by filename, file/socket handle, C FILE*, C++ istream, IO
system appropriate to the language you're embedding in)
Something I though of:
If you're trying to write an interactive perl inputer - either a perl shell
or just the command prompt on the debugger it would be useful if you
could tell the parser that the chunk of source you're giving it may be
incomplete.
So that the you have something like
foo$ print "Hello world
and 'print "Hello world' is passed to the parser/lexer/tokenizer, which
accepts this input (rather than faulting that the closing " was missing
and then returns to the caller that the innermost thing it's waiting on
is a '"', so that the shell/debugger whatever could change its prompt
to tell the user what's up (bit like some Unix shells and the mysql
command line tool). So at this point you'd now see
foo"
as a prompt.
I don't think you can do that with eval in perl5, can you?
If not, it represents something new the parser will have to be able to
communicate with the outside world.
Nicholas Clark
