On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
Should the network opcodes even be loaded as standard? C<socket> et al
aren't
actually that useful on Perl 5 without all the constants in the Socket
module,
so in practical terms a redesigned Perl 5 would do better to remove
all the
socket specific keywords and make them functions exported by the Socket
module. Should parrot go the same way?
A pasm include, such as the signal.pasm(even though signals don't work
yet), would suffice and is generated at compile time. Parsing .h files
with anything but a c preprocessor would cause problems. Writing PMC's
is almost a given, and the PMC's could even provide convenience methods
that would do common things(like open a socket to foo.com:80). If
it/they extend ParrotIO, the possibility of buffered networking would
be possible(although I doubt many would want it on by default). But
for all the defines, a pasm include would be needed.
Should the IO system provide symbolic lookup on AF_* and PF_*
constants.
IIRC at least one of these groups is OS dependant, as demonstrated by
Solaris
and SunOS differed on the values they used. It would be "useful" if
this
lookup could be flagged to happen in some way at bytecode load time.
With the pasm include method, the problem is they're mainly just
preprocessing. There's currently no way for the include to put a flag
in the resulting bytecode, unless platform specific pasm includes
include some code that'll do something like that(most likely requiring
a new opcode, 'pbcplatform "darwin"' for instance), and whenever the
pasm file is included, it gets ran, and when the pbc is saved that
state can be stored in a pbc header. Sounds really complicated and
troublesome.
(Or maybe I want the moon on a stick alone with a "JIT this lazy
constant"
routine. Which probably does generalise, if functions can be marked as
"cacheable" and the JIT can see a cacheable function taking only
constants,
and hence constant fold it)
Nicholas Clark
