Re: A tentative list of vtable functions
At 10:46 PM 8/31/00 +, David L. Nicol wrote: Dan Sugalski wrote: Okay, here's a list of functions I think should go into variable vtables. All the math functions are in here. Can the entries that my type does not use be replaced with other functions that my type does use? That's what overloading does. Functions marked with a * will take an optional type offset so we can handle asking for various permutations of the basic type. These aren't going to be that huge then, with each one taking *void() thismuch[30] or so; why don't we skip the "optional offset" and make subclasses keep their whole own copy? Will 240 bytes per type blow out a modern cache? Nope. When I said optional offset, I meant that the version of perl you were using might or might not have the capability to do this, depending on compile-time options. clarify (where does this type go to resolve uncached method names?) or is that better kept in a global clarifier that keeps it's own mapping. You're confusing perl-level objects with these low-level internals things. This stuff isn't really visible except to people writing new variants on base perl types, so you won't see it unless you're writing overload code. I think the list is too long, for the base type. Could the base type be something that just knows how to return its type name, in order to build types that do not have defined STRING methods? We're shooting for speed here. Any common operation that could be affected by the type of the variable should be represented so a custom function can be called that does exactly what needs to be done. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A tentative list of vtable functions
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Okay, here's a list of functions I think should go into variable vtables. DS Functions marked with a * will take an optional type offset so we can DS handle asking for various permutations of the basic type. DS type DS name What are this used for? DS get_bool Is this allowed to return a non-true/false result? Or is everything true or false? DS get_string * DS get_int * DS get_float * What does the optional type argument do? What about collection types? Why not simply collapse these into a single one with an option argument? What should a get_* do if inappropriate for its type? DS get_value What does this do that the above three do not? DS set_string * DS set_int * DS set_float * DS set_value DS add * DS subtract * DS multiply * DS divide * DS modulus * Where is the argument to be added/subtracted/etc. ? On the stack? DS clone (returns a new copy of the thing in question) Isn't this a deep problem? (Should be near the top of the vtbl DS new (creates a new thing) Why does the thing have to do a new? (move earlier) DS concatenate DS is_equal (true if this thing is equal to the parameter thing) DS is_same (True if this thing is the same thing as the parameter thing) How does THIS figure out how to get THAT to give a usable value? DS logical_or DS logical_and DS logical_not DS bind (For =~) DS repeat (For x) Are these so that operators can be overriden? DS Anyone got anything to add before I throw together the base vtable RFC? Are you going to fully specify the expected input and results in the RFC? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: the C JIT
Ken Fox wrote: Perl is more like lisp with a good syntax -- in other words about as far from C as you can get. I agree 100%. -- John Porter
Re: A tentative list of vtable functions
DS get_bool Is this allowed to return a non-true/false result? Or is everything true or false? Dunno yet. I'm thinking just a true/false value, but... A tri-state bool would be really cool (i.e, true/false/undef). Although I understand that this probably isn't where Perl 6 is going, most embedded systems these days have I/O that can exist in three states (1, 0, or Hi-z). Grant M.
Re: A tentative list of vtable functions
Dan Sugalski wrote: We're shooting for speed here. Any common operation that could be affected by the type of the variable should be represented so a custom function can be called that does exactly what needs to be done. Dan so if I want to make up a type that is strictly a 16-bit integer, I overload everything except the math operations with pointers to errors? That's the direction I'm going (off by myself), to merging C in, and that's why a even more limited base type appeals to me. But of course, with a more limited base type, every call to plus would have to check to see if plus was there before resolving, instead of just hopping over the edge and trusting the top end of the rope to be tied.
Re: A tentative list of vtable functions
Dan Sugalski writes: : Type returns a magic cookie value of some sort (Not sure what sort yet), : name returns a string with the name of the type of the variable. Why can't the type object just stringify to the name of the type? From a language level, I'm inclined to say that any bare identifier that is known to be a type name should be compiled to a type object that stringifies to the name of its type. Then class methods don't have to do an extra symbol table lookup. Larry
Re: A tentative list of vtable functions
Dan Sugalski [EMAIL PROTECTED] writes: is_equal (true if this thing is equal to the parameter thing) is_same (True if this thing is the same thing as the parameter thing) is_equal in what sense? (String, Number, ...) and how is is_same different from just comparing addresses of the things? -- Nick Ing-Simmons
Re: A tentative list of vtable functions
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes: NI Dan Sugalski [EMAIL PROTECTED] writes: is_equal (true if this thing is equal to the parameter thing) is_same (True if this thing is the same thing as the parameter thing) NI is_equal in what sense? (String, Number, ...) NI and how is is_same different from just comparing addresses of the things? Proxies? Wrappers? The proxy might want to answer on behalf of the proxied. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: A tentative list of vtable functions
At 06:07 PM 9/1/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: is_equal (true if this thing is equal to the parameter thing) is_same (True if this thing is the same thing as the parameter thing) is_equal in what sense? (String, Number, ...) I was thinking if you did: $a = $b; then the equal method for $a would return true if passed $b to compare with, regardless of the type. Equality is a rather nebulous thing without context, though. Perhaps this should get a context passed in as a parameter. and how is is_same different from just comparing addresses of the things? We might have aliased variables or something, where two variable pointers which point to two different variable structures are actually the same thing. Threads do this too in the current implementation. (And in the pthreads interface, though neither are a great argument for it...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A tentative list of vtable functions
At 10:23 AM 9/1/00 -0700, Larry Wall wrote: Dan Sugalski writes: : Type returns a magic cookie value of some sort (Not sure what sort yet), : name returns a string with the name of the type of the variable. Why can't the type object just stringify to the name of the type? I'd figured that the type would be an integer, rather than an object, and one that wouldn't necessarily map to just one 'real' variable type. A tied integer, for example, would return an integer type though the name would likely be the package the variable was tied into. From a language level, I'm inclined to say that any bare identifier that is known to be a type name should be compiled to a type object that stringifies to the name of its type. Then class methods don't have to do an extra symbol table lookup. None of this should really be visible from a language level except indirectly. (Through the overload mechanism, perhaps) The name function for most variables would likely just return a constant string and, while there's some speed hit from that instead of just storing it in the variable somewhere, it's not likely to be called often enough to make a difference. For real perl language-level method calls, I'd figure we'd cache a pointer to the package stash in the variable, store the hash value of the method name (if it's a bareword method call) in the opcode and, if the call's on a typed variable, a pointer to the CV for the method. (Ignored if the real variable's not of the type declared in the code) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A tentative list of vtable functions
At 11:49 AM 9/1/00 -0500, David L. Nicol wrote: Dan Sugalski wrote: We're shooting for speed here. Any common operation that could be affected by the type of the variable should be represented so a custom function can be called that does exactly what needs to be done. Dan so if I want to make up a type that is strictly a 16-bit integer, I overload everything except the math operations with pointers to errors? That's the direction I'm going (off by myself), to merging C in, and that's why a even more limited base type appeals to me. No, you provide functions that do the right thing. If you have a 16-bit integer scalar, you should still return a floating point value or string representation, or a 32-bit (or native sized, at least) integer if asked. But of course, with a more limited base type, every call to plus would have to check to see if plus was there before resolving, instead of just hopping over the edge and trusting the top end of the rope to be tied. No, we hop over the edge. It's not unreasonable for perl to expect internal consistency. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A tentative list of vtable functions
On Fri, 01 Sep 2000, Dan Sugalski wrote: I'm not sure. They're there mainly for guaranteed unfiltered access to the variable's guts, and I'm not sure what things will need that. I use direct, raw access in prototyping when dipping back into C for "heavy" data manipulations - bit stream analysis, signals processing, etc. Since I'm usually doing a lot of buffer manipulations, I don't want all the scalar overhead that comes into play. Of course, one could argue that that's a completely different subject - we're talking about calls within perl itself. Extraction of the raw data could just as well happen underneath without an interface of any kind. But I'd like to bring a lot of that work back up into perl proper, which, unfortunately, often results in the code running two to three hundred times slower than native C. (It's only prototyping, keep in mind, but I'd like run-times to at least be the same day. :-) I've been trying (off and on) for a couple of months to hack an interface to a lightweight buffer from within Perl, to at least allow some of the cruder constructs without *too* much overlap. In the end, though, it still comes down to pointers, arrays of pointers, or pointer offsets. All of which were still scalars, so it didn't buy too much. Furthermore, what is "guaranteed unfiltered access", and how can it be used? For a Perl 5 string, for instance, would it be the entire allocated buffer, or the space from the beginning pointer to the end of the string? Are you going to be able to manipulate this raw data in the raw, or are you still going to have to go through perl to work on it? My reason for asking is that the more of the perl core that relies on specific representations of data, the more complexity there is in porting to other architectures. Fair enough. It may turn out to be unnecessary, in which case we'll toss it, or if not we'll just make sure to force some reasonable requirements on it so porting's easier. I think, through line disciplines or string tags or what-have-you, that some data should be allowed to be tagged as raw - perhaps to prevent any automatic promotion, for instance - but actually needing that raw data underneath is rather incestuous. If something relies on that data so much, it knows where to find it. -- Bryan C. Warnock ([EMAIL PROTECTED])
