Re: The external interface for the parser piece
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote: int perl6_parse(PerlInterp *interp, void *source, int flags, void *extra_pointer); Count me in with the people who prefer: int perl6_parse(PerlInterp *interp, PerlIO *io); I understand the desire to reduce the number of API bits the external user needs to know about, but I think that the non-PerlIO API will lead to more complexity than it removes. Assuming the non-PerlIO interface is used, however, I believe there is a problem with the PERL_GENERATED_SOURCE option. ANSI/ISO C does not guarantee that a function pointer may be stored in a void*. I would suggest that Perl's external APIs, at the very least, should conform to standard C. - Damien
Re: Backtracking through the source
On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote: My only worry is, how do we reconcile this with the idea of Perl having an easily modifiable grammar and being a good environment for little-language stuff? That's a good question, and it depends on what Larry's thinking of for little languages. Smacking the perl parser around enough to handle, say, something C or Pythonish shouldn't be a huge hassle. Making it handle something Lisp-like, though, is another matter entirely. I think my worry was more general than that: if we've got a big monolithic parsebeast which is making lots of Perlish decisions, at what levels do we allow the user to modify that? Do they get to replace the whole thing and implement their own tokeniser, lexer and parser, or can we find a way to apply "hooks" to replaceable components? -- "Dogs believe they are human. Cats believe they are God."
Re: Backtracking through the source
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: I categorically do *NOT* want perl6-internals to turn into a basic course in compiler design, purely for the benefit of those who know nothing at all about what they're trying to achieve. I'd like Perl 6 to be a masterwork, and masterworks require master craftsmen. If you want to partake in compiler design, it makes more than a little sense to find out how to do so. Guh, I shouldn't have said that, because I know exactly what'll happen now: people will accuse me of being elitist and reactionary and trying to shut people out who want to help. Outside my room, some constructors are building a school. I'd like to help. I'd like to take part in the building; it'll be great! We'll have lots of classrooms, and a playground, and I think there should be an armoury, because all good schools have an armoury. Oh, that's military bases; but that doesn't matter, it should have one anyway. But for some reason, the constructors don't think much of my plans. They're saying something about the need for "foundations" or something or other that I can't understand. Look, it's not my fault I have no knowledge of engineering! I *really* want to help, and they're trying to exclude me. Horrible, elitist bastards! Are they? Are they being elitist? Of course not. Are they trying to exclude me? *No*. By my own lack of knowledge and utility, *I* *exclude* *myself*, and no amount of wanting to help makes up for that. Think about it. -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: Backtracking through the source
On Thu, 30 Nov 2000, Simon Cozens wrote: On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: I categorically do *NOT* want perl6-internals to turn into a basic course in compiler design, purely for the benefit of those who know nothing at all about what they're trying to achieve. I'd like Perl 6 to be a masterwork, and masterworks require master craftsmen. If you want to partake in compiler design, it makes more than a little sense to find out how to do so. Guh, I shouldn't have said that, because I know exactly what'll happen now: people will accuse me of being elitist and reactionary and trying to shut people out who want to help. You don't want the compiler design to be a 'hands-on experiment' for us inexperienced folk? That's not elitist, that's pragmatic. You don't want this to be a learning experience - (corrections, observations, answers) - to the same? *That's* elitist. -- Bryan C. Warnock RABA Technologies
Re: The external interface for the parser piece
Nicholas Clark [EMAIL PROTECTED] writes: We're trying to make this an easy embedding API. Yes, and we are in danger of "premature optimization" of the _interface_. What we need to start with is a list of "what we need to know" - they may as well be separate parameters at this point - then we can decide how best to group them and provide wrapper(s) that call the zillion parameter version. If there turns out to be only one sensible wrapper then it can become _the_ interface. -- Nick Ing-Simmons [EMAIL PROTECTED] Via, but not speaking for: Texas Instruments Ltd.
Re: Opcodes (was Re: The external interface for the parser piece)
At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
$a=1; $b =3; $c = $a + $b
If they don't exist already, then something like:
newscalar a, num, 1.2
newscalar b, int, 3
newscalar c, num, 0
add t3, a, b
and $c ends up a num?
why that line "newscalar c, num, 0" ?
It looks to me like add needs to be polymorphic and work out the best
compromise for the type of scalar to create based on the integer/num/
complex/oddball types of its two operands.
I think the "add t3, a, b" was a typo, and should be "add c, a, b"
Another way of looking at it, assuming that the Perl6 interpreter is
stack-based, not register-based, is that the sequence would get converted
into something like this:
push num 1.3 ;; literal can be precomputed at compile time
dup
newscaler a;; get value from top of stack
push int 3;; literal can be precomputed at compile time
dup
newscaler b
push a
push b
add
newscaler c
The "add" op would, in C code, do something like:
void add() {
P6Scaler *addend;
P6Scaler *adder;
addend = pop(); adder = pop();
push addend-vtable-add(addend, adder);
}
it would be up to the addend-vtable-add() to figure out how to do the
actual addition, and what type to return.
But that probably doesn't help much. Let me throw together something more
detailed and we'll see where we go from there.
Hopefully it will cover the above case too.
Nicholas Clark
Re: Opcodes (was Re: The external interface for the parser piece)
At 05:59 PM 11/30/00 +, Nicholas Clark wrote: On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote: (Moved over to -internals, since it's not really a parser API thing) At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote: Presumably. But why are you then still talking about "the IV slot in a scalar"...? I'm slow today. Show me how $a = 1.2; $b = 3; $c = $a + $b; is going to work, what kind of opcodes do you see being used? (for the purposes of this exercise, you may not assume the optimizer doing $c = (1.2+3) behind the curtains :-) $a=1; $b =3; $c = $a + $b No, that's naughty--it's much more interesting if the scalars are different types. If they don't exist already, then something like: newscalar a, num, 1.2 newscalar b, int, 3 newscalar c, num, 0 add t3, a, b and $c ends up a num? When the add line is fixed, yup. :) This is assuming the optimizer can spend enough time and see enough of the code to know that we're adding an int and num, so that $c must be a num. If not, the newscalar line would be: newscalar c, generic, NULL to set it to be a generic empty scalar. why that line "newscalar c, num, 0" ? It looks to me like add needs to be polymorphic and work out the best compromise for the type of scalar to create based on the integer/num/ complex/oddball types of its two operands. Yup. What add does is based on the types of the two operands. In the more odd cases, I assume it's type stuff will be based on the left-hand operand, but I wouldn't bet the farm on that yet, as that's a Larry call. [Oh. but I'm blinkered in this because I'm attempting to make pp_add in perl5 do this sort of thing, so I may be missing a better way of doing it] vtables make it a lot nicer. Whether they make it faster is still up in the air... :) But that probably doesn't help much. Let me throw together something more detailed and we'll see where we go from there. Hopefully it will cover the above case too. What, the "what if one of the operands is really bizarre" case? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Opcodes (was Re: The external interface for the parser piece)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
The "add" op would, in C code, do something like:
void add() {
P6Scaler *addend;
P6Scaler *adder;
addend = pop(); adder = pop();
push addend-vtable-add(addend, adder);
}
it would be up to the addend-vtable-add() to figure out how to do the
actual addition, and what type to return.
DS Yup. I think it'll be a little more complex than that in the call,
DS something like:
addend- vtable-(add[typeof adder])(adder);
DS The extra level of indirection may hurt in the general case, but I think
DS it's a win to call the "add an int scalar to me" function rather than have
DS a generic "add this scalar to me" function that figures out the type of the
DS scalar passed and then Does The Right Thing. I hope. (Yeah, I'm betting
DS that the extra indirect will be cheaper than the extra code. But I'm not
DS writing that in stone until we can do some benchmarking)
Is all that really necessary? Why not a non-vtbl function that knows how
to add numeric types?
I would have wanted to limit the vtbl to self manipulation functions.
Set, get, convert, etc. Cross object operations would/should be
outside the realm of the object. (It seems like trying to lift yourself
by the bootstraps.)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
