Dan Sugalski:
# At 3:16 PM -0700 5/18/02, Brent Dax wrote:
# >Dan Sugalski:
# ># At 1:14 PM -0700 5/15/02, Brent Dax wrote:
# ># >Dan Sugalski:
# ># ># At 12:51 AM -0700 5/15/02, Brent Dax wrote:
# ># ># >-Parrot becomes Parrot_Interp
# ># ># >-Parrot_String is gone and the string_funcs.h
# functions are # no
# ># >longer # >externally visible. -A few structures have been renamed.
# ># ># >-config.h has been rearranged so that INTVAL, etc. are now
# ># ># aliases for
# ># ># >Parrot_Int, etc.
# ># ># >-A few things that were accidentally made external no
# longer are.
# ># >#
# ># ># This isn't a problem with config.h. config.h should
# *never* be used
# ># ># by anyone embedding Parrot, either directly or indirectly.
# ># >
# ># >Why not? Some parts of Parrot's embedding system have to be
# ># set up by
# ># >Configure.
# >#
# ># And those parts should go in embed.h. The bare minimum amount of
# ># stuff should go in there--the definitions of INTVAL,
# NUMVAL, Buffer,
# ># STRING (maybe), and the exported functions. A later phase of the
# ># build could probably set this up as well, as it'd have
# access to more
# ># information.
# >
# >I'm trying to keep the number of dynamically-generated files to a
# >minimum.
#
# Why?
1. When you generate a file dynamically, that means it isn't in CVS--the
template is.
2. There's a potential for confusion when people want to make changes to
the core.
3. Eventually Configure will have to be written in PASM, and I'd like to
keep things as simple as possible for that.
# >We don't lose anything by defining a small part of config.h
# >that's external, and we gain a static embed.h.
#
# There's too much risk of leakage. Once things leak, they can't easily
# be retracted. I'd rather not have them leak in the first place.
If someone uses a symbol that isn't documented as external and we
retract it, that's their problem. Remember that no matter how much we
try to keep external interfaces well-defined, all they have to do is
#include "parrot/parrot.h" and they get everything anyway. I'm not
saying that we should make everything public and just say "only use
this"--I'm saying that we shouldn't make our lives more difficult to
prevent naughty behavior unless that's an explicit goal.
# ># Stuff like PMC definitions shouldn't go in it. PMC * should be
# ># typedef'd to void * in the embedding header.
# >
# >What I do is declare things like
# >
# > struct parrot_pmc_t;
# > typedef struct parrot_pmc_t* Parrot_PMC;
# >
# >So we don't get warnings about type mismatches when we
# compile embed.c.
#
# That works.
#
# >Actually, Parrot_PMC won't be in embed.h directly--it'll be
# in extern.h,
# >which defines the interface between the outside world and PMCs and
# >STRINGs. (I'm planning for extenders to use the same
# interface, which
# >is why it's in a separate header. embed.h will probably include
# >extern.h, so it'll be transparent to the user.)
#
# Keeping the interfaces separate is good, and keeping them compatible
# is also good. Works for me.
#
# ># ># >I first noticed the problems with computed-goto when I
# ># found the #
# ># >>following line in test_main.c: # >
# ># ># > #ifdef HAVE_COMPUTED_GOTO
# ># ># >
# ># ># >See the problem?
# ># >#
# ># ># Yes. test_main.c should never have to know about computed
# ># goto cores
# ># ># or whatnot. The define's likely something generally
# passed on the
# ># ># command line to all the parrot core bits,
# ># >
# ># >True. Still, the idea of a define like this not being fixed
# ># somewhere
# ># >scares me a bit. If someone tries to send us a copy of
# ># their config.h
# ># >so we can debug a problem, we can't tell if they have
# cgoto enabled.
# >#
# ># That's definitely a problem. That #define should be in
# config.h, and
# ># *is* a problem.
# >
# >Actually, the JIT does the same thing, so it's not
# *entirely* his fault.
#
# I'm not looking to place blame--I don't really care that much, and
# blame doesn't really buy us anything. I'd just rather it not happen,
# and get fixed when it does.
Yeah.
# ># >Actually, it should know that Parrot may support a
# ># computed-goto core
# ># >and the flag to enable it is X. It shouldn't have to know if this
# ># >particular copy of Parrot is built with that capability.
# ># (It probably
# ># >should be able to detect it, however, so that it can handle
# ># cases like
# ># >the one in test_main's -h handler.)
# >#
# ># 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 don't think it should warn unless we give them a way to reject the
cgoto choice. (Besides, I was speaking of current behavior, not correct
behavior. ;^) )
--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
