Re: primitives in Io
- View SourceIf primitives had an addSlot() method, you could do:
time = 2 months + 1 day + 25 min
length = 1 foot + 2 in + (1/16) in
Is this really useful? Maybe.
--- In iolanguage@y..., Steve Dekorte <steve@d...> wrote:
> On Sunday, September 29, 2002, at 10:48 PM, QuantumG wrote:
> > On Wed, 25 Sep 2002, Steve Dekorte wrote:
> >> I agree but I didn't see any clean way to do it(I can send a
> >> description if you're interested and familiar with C) . By
> > Yes, please.
> Ok, primitives need to:
> - provide access to C functions
> - [often] have direct access to instances of C data structures from
> within those C functions
> So the question is how to do this.
> One way, taken by languages such as Lua, is to wrap the C data
> structures into special types available in the language(Lua calls
> userdata) and then pass these to the custom function bindings in
> With this model, you can build objects by putting an instance of
> custom type in a slot of an object along with your C function
> as methods in other slots.
> Now every time you call a method, the C function needs to:
> - do extra lookups to find the special data type
> - check to see if it's the right type
> - primitives are extensible in the normal way.
> - primitives require more lookups(much slower)
> - have more checking code(slower and more complex binding code)
> - the C functions need to be wrapped in C function primitives(adds
> overhead when calling)
> - limits number of methods per primitive if you want to use Io's
> perfect hashing mechanism for Objects(a problem for large bindings
> Another way to implement bindings, the one used in Io, is to tack
> methods to the tag for the custom primitive and override the
> primitive's perform method to lookup the direct function pointer
> the method binding, and call it directly with the primitives
> pointer(which is also the data structure). This is much faster,
> less memory and makes writing new primitives much easier to
> but it means the primitives are special and require special
> to inherit from. It's a tradeoff.
> > wasn't aware of the parent behaviour. Is there some way to
> > that
> > a given slot is to be used for autodelegation or is
> > In Self you'd put a star on the end of the name. I always
> > that was a
> > bit of a hack.
> Io uses the same inheritance model as NewtonScript. There are two
> inheritance slots (proto and parent). Lookups follow the proto
> first, the the parent chain.
> > What's wrong with just setting the proto slot of the
> > primitives to point to Object?
> It Object primitive won't allow it's proto slot to be set to
> but an Object. This is for performance reasons. proto slot lookups
> very common and if it's known that lookups will only be on Objects
> lookup code can avoid having to check the type on each lookup.
> slot lookups(which are much less common) will check the type so
> can be used to inherit from non-Object primitives.
- View SourceOn Friday, October 4, 2002, at 10:08 AM, Mike wrote:
> If primitives had an addSlot() method, you could do:That's a cool use of primitive extensions.
> time = 2 months + 1 day + 25 min
> length = 1 foot + 2 in + (1/16) in
> Is this really useful? Maybe.
> Smalltalk reference:
I've thought about it some more, and I'm thinking of adding an
addParent() method for primitives that would allow you to set your own
object as the parent of the primitive. An addSlot() method could be
implemented by creating a parent object if it didn't exist and
inserting the slot. This would provide the same flexibility without
slowing down normal primitive lookups! Thanks (to QuantumG and Mike)
for raising this issue.
- View SourceOn Saturday, October 5, 2002, at 07:15 PM, Steve Dekorte wrote:
> I've thought about it some more, and I'm thinking of adding anActually, that won't work at all. :-[
> addParent() method for primitives that would allow you to set your own
> object as the parent of the primitive. An addSlot() method could be
> implemented by creating a parent object if it didn't exist and
> inserting the slot. This would provide the same flexibility without
> slowing down normal primitive lookups! Thanks (to QuantumG and Mike)
> for raising this issue.
I need to think about it a bit more.
- View SourceOn Tuesday, October 8, 2002, at 08:17 PM, QuantumG wrote:
> Finding a transparent way of doing it would be better. Perhaps aThat's a good idea. I need to give it some more thought.
> primitive could act as it is done now until someone calls the (native)
> addSlot method, at which time it transforms into an object wrapping on
> that primitive, or maybe you just have to handle the primitive lookups
> specially -- but, obviously, being able to override the existing slots
> primitives would be as desirable as being able to add your own slots.