At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote:
>Since perl6 will/should have a new Configure methodology[1] there
>could be a registry (hate that word) of all available function
>calls[2], developed during the build processes. Then the core would be
>able to infer a 'use' command.
Yes. What I'd like to have is a list of functions, prototypes, return type,
calling type, shared libraries they reside in, and the C name. Whenever the
lexer saw a name on the list it'd automagically mark that shared library
for loading.
So if the list had:
localtime|$|@|op|time.so|localtime
perl would know that the localtime function took a scalar, returned a list,
is called like an opcode, and lives in time.so with a name of localtime. If
(and only if) you used localtime, perl would load in time.so for you. In
the optree (or bytecode stream or whatever) perl would have the
I_cant_believe_its_not_an_opcode opcode with a pointer to the function we
loaded in from time.so.
This way it looks like an opcode, talks like an opcode, looks like an
opcode, but isn't an opcode taking up valuable space. (Not to mention
making the optimizer more complex--the fewer the opcodes the easier its
likely to be)
I've got an RFC started on this.
The list would presumably be added to occasionally when a module is installed
> >>>>> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>
>NT> Moving things to modules (a) does little for the size of Perl, and (b)
>NT> promotes Pythonization of the language (i.e., all programs begin with
>NT> 20 lines of `load this module, load that module, load the other
>NT> module'). Your criteria for moving to a module can't simply be
>NT> whether it's a system call or not, you must use something that takes
>NT> into account the hindrance and the payoff.
>
>--
>Chaim Frenkel Nonlinear Knowledge, Inc.
>[EMAIL PROTECTED] +1-718-236-0183
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
