Loading ...
Sorry, an error occurred while loading the content.

Re: primitives in Io

Expand Messages
  • Mike
    If 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.
    Message 1 of 6 , Oct 4, 2002
    View Source
    • 0 Attachment
      If 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.

      Smalltalk reference:
      http://groups.google.com/groups?
      q=smalltalk+unit+feet+inches&hl=en&lr=&ie=UTF-8&oe=UTF-
      8&selm=36D1F5AE.3B0%40erols.com&rnum=1

      Mike

      --- 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
      detailed
      > >> description if you're interested and familiar with C) . By
      clean, I
      > >
      > > 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
      these
      > userdata) and then pass these to the custom function bindings in
      some
      > way.
      >
      > With this model, you can build objects by putting an instance of
      your
      > custom type in a slot of an object along with your C function
      bindings
      > 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
      >
      > Advantages:
      > - primitives are extensible in the normal way.
      >
      > Disadvantages:
      > - 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
      more
      > 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
      like
      > OpenGL)
      >
      > Another way to implement bindings, the one used in Io, is to tack
      the
      > methods to the tag for the custom primitive and override the
      > primitive's perform method to lookup the direct function pointer
      for
      > the method binding, and call it directly with the primitives
      > pointer(which is also the data structure). This is much faster,
      uses
      > less memory and makes writing new primitives much easier to
      understand
      > but it means the primitives are special and require special
      techniques
      > to inherit from. It's a tradeoff.
      >
      > > wasn't aware of the parent behaviour. Is there some way to
      signal
      > > that
      > > a given slot is to be used for autodelegation or is
      parent "special"?
      > > In Self you'd put a star on the end of the name. I always
      thought
      > > 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
      chain
      > 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
      anything
      > but an Object. This is for performance reasons. proto slot lookups
      are
      > very common and if it's known that lookups will only be on Objects
      the
      > lookup code can avoid having to check the type on each lookup.
      Parent
      > slot lookups(which are much less common) will check the type so
      they
      > can be used to inherit from non-Object primitives.
      >
      > Cheers,
      > Steve
    • Steve Dekorte
      ... That s a cool use of primitive extensions. I ve thought about it some more, and I m thinking of adding an addParent() method for primitives that would
      Message 2 of 6 , Oct 5, 2002
      View Source
      • 0 Attachment
        On Friday, October 4, 2002, at 10:08 AM, Mike wrote:
        > If 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.
        >
        > Smalltalk reference:
        > http://groups.google.com/groups?
        > q=smalltalk+unit+feet+inches&hl=en&lr=&ie=UTF-8&oe=UTF-
        > 8&selm=36D1F5AE.3B0%40erols.com&rnum=1

        That's a cool use of primitive extensions.

        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.

        Cheers,
        Steve
      • Steve Dekorte
        ... Actually, that won t work at all. :-[ I need to think about it a bit more. Steve
        Message 3 of 6 , Oct 5, 2002
        View Source
        • 0 Attachment
          On Saturday, October 5, 2002, at 07:15 PM, Steve Dekorte wrote:
          > 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.

          Actually, that won't work at all. :-[
          I need to think about it a bit more.

          Steve
        • Steve Dekorte
          ... That s a good idea. I need to give it some more thought. Cheers, Steve
          Message 4 of 6 , Oct 28, 2002
          View Source
          • 0 Attachment
            On Tuesday, October 8, 2002, at 08:17 PM, QuantumG wrote:
            > Finding a transparent way of doing it would be better. Perhaps a
            > 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
            > of
            > primitives would be as desirable as being able to add your own slots.

            That's a good idea. I need to give it some more thought.

            Cheers,
            Steve
          Your message has been successfully submitted and would be delivered to recipients shortly.