Jeff Clites <[EMAIL PROTECTED]> wrote:
My main point is that you can't do conditional library loading. This code will try to load the "doesnt_exist" library, and I don't think it should:
branch HERE loadlib P1, "doesnt_exist" HERE: end
It's not because the branch fails--it's because the library is loaded before the script starts running.
It depends. When you run it immediately, you are right: The library is loaded at compile time. When you compile it as .pbc and run it, the lib isn't loaded ar runtime. *But*, when writing that stuff, one prelim was, that the compiler sees all libs in the same sequence as runtime does. So above code (or your second example) is illegal.
Okay for now then. But long-term it seems pretty obvious that this will be too restrictive. Here are some specific problems:
1) For non-parrot libs (like the ncurses lib. used in Dan's example), it's not necessary to load them at parse-time. It's a waste in terms of performance, but also not all libraries can be unloaded on all platforms, and some libraries will cause behavior changes that aren't intended to take effect until later. This is an argument for the distinction we used to have with different ops to load different types of libraries. We may have been a bit hasty in unifying them all.
2) A program may act differently when run from source v. run from .pbc, because different libraries may be loaded.
3) You can't do conditional loading of the form "if some condition is met, load library A which implements the PMC I need, else load a different library B which implements it". For instance, you might want to choose at runtime between loading a debug and a non-debug version of some library. Currently I'd imagine that we'd end up loading both at compile-time, which it's probably guaranteed to not work correctly.
This brings me back to my original question of whether the parser should think ".Foo" is a macro at all, or if rather that's not legal macro syntax.
This doesn't change the problem per se.
It does in that the current parser behavior blocks finding out what the real issue is.
Also, it's still a legitimate question, so for the third time I'll ask if ".Foo" is valid macro syntax? If not, then the current parser behavior is misleading. I'm of the opinion that it should not be valid macro syntax--that ".Foo()" should be necessary instead, because otherwise the grammar is ambiguous.
JEff
