Melvin Smith:
# At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote:
# >># Flag handling, or at least feature enabling, should
# probably be done
# >># by core code. We should provide a set_feature() function
# >>
# >>Right now we have something like this:
# >>
# >> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL);
# >>
# >>I'm not sure how Parrot reacts to that if computed goto isn't
# >>available on this platform, though.
# >
# >It should pitch a warning and then ignore the computed goto choice.
# >It's
# >not a fatal error, after all.
#
# I hold a different opinion, and that is, production release
# of Parrot should choose the cores at config time, and make
# the fastest (non-JIT) core the default, assuming it is stable.
#
# I don't see a reason to even provide a flag PARROT_CGOTO_FLAG
# and a runtime switch.
#
# If computed goto is there, and it is the fastest core, it
# should be THE core, the same goes for prederef if computed
# goto isn't available.
The current system was put into place so that we could do comparitive
benchmarks between cgoto and other cores even on systems with cgoto
enabled.
Having said that, I think that the default should be to use the fastest
non-JIT core, but there should be optional flags to force Parrot to use
a specific core.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
