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

Re: [langsmiths] object/closure/method/block

Expand Messages
  • Marcin 'Qrczak' Kowalczyk
    ... I m not sure what do you mean by the below. I guess you are applying some very specific properties of some language (maybe Self? I don t know it enough to
    Message 1 of 16 , Dec 1, 2002
    • 0 Attachment
      Sat, 30 Nov 2002 17:06:50 -0800, Steve Dekorte <steve@...> pisze:

      > Does this seem like a reasonable break down of these types?:

      I'm not sure what do you mean by the below. I guess you are applying
      some very specific properties of some language (maybe Self? I don't
      know it enough to judge). In other object models it will be very
      different.

      For example in my language an object = type tag + behavior + a bit of
      magic for some types. Behavior is a function from a list of objects
      to a side effect producing an object or raising an exception.

      Type is a tag which helps to interpret its behavior, to predict how
      it will behave.

      But most often you don't send messages to data objects. Interfaces
      are provided in the form of functions, many of them are generics
      (i.e. dispatching the actual implementation on types of arguments).

      There is no subclassing as understood in most OO languages. You can
      probably implement it, but I'm afraid it won't fit into the design.
      There is declared subtyping for dispatching purposes.

      Functions defined in modules or locally, as well as anonymous closures,
      have type Function, and their behavior executes their bodies. A module
      or record accepts a single argument which must be a symbol, it returns
      the given field; some fields can also be changed in place or understand
      other messages.

      There is no "parent" concept. Scoping is lexical. "obj.field" is a sugar
      for applying obj to the symbol 'field', but most other identifiers mean
      an object bound in an outer scope.

      > - Object (a key/value hash)
      > - on activation: returns self
      > - parent scope: prototype from which created

      I can't relate this to my language.

      > - Closure (a key/value hash)
      > - on activation: returns result of a behavior
      > - parent scope: hash in which created?

      A closure refers to objects bound to its free variables, but it's
      a private implementation detail how they are attached to the closure.
      The public interface of a function is just its behavior.

      > - Block (a key/value hash)
      > - on activation: clone self and returns result of a behavior on the clone
      > - parent scope: hash in which created

      I don't even know what do you mean a block (if not a closure).

      > - Method (a key/value hash)
      > - on activation: clone self and returns result of a behavior on the clone
      > - parent scope: hash in which activated

      What is a method in my language? A generic function? A particular
      specialization of a generic function? A field which is a function?

      > Is the typical scope of a closure the same as that of a block?

      What do you mean by the scope of an object (be it a closure or another)?
      Identifiers have scopes, objects don't (in garbage-collected languages,
      i.e. almost all).

      --
      __("< Marcin Kowalczyk
      \__/ qrczak@...
      ^^ http://qrnik.knm.org.pl/~qrczak/
    • James McCartney
      ... I don t understand this. I didn t understand it when I read your sources either. In Self, an object s parent(s) is/are the same parent(s) that the
      Message 2 of 16 , Dec 1, 2002
      • 0 Attachment
        On Saturday, November 30, 2002, at 05:06 PM, Steve Dekorte wrote:

        > - Object (a key/value hash)
        > - on activation: returns self
        > - parent scope: prototype from which created

        I don't understand this. I didn't understand it when I read your
        sources either. In Self, an object's parent(s) is/are the same
        parent(s) that the prototype it was cloned from had. Why should an
        object's parent BE the prototype?

        >
        > - Closure (a key/value hash)
        > - on activation: returns result of a behavior
        > - parent scope: hash in which created?
        >
        > - Block (a key/value hash)
        > - on activation: clone self and returns result of a behavior on the
        > clone
        > - parent scope: hash in which created

        >
        > - Method (a key/value hash)
        > - on activation: clone self and returns result of a behavior on the
        > clone
        > - parent scope: hash in which activated
        >

        Why should a block and a closure be different? A block is just a
        possible optimization on the more general closure. A user should not
        see a difference. I agree with Brian Rice that hashing is just
        implementation and does not need to be part of the analysis. Lua is a
        language where functions and methods are unified. But at a cost of
        having to make a syntactic distinction when calling a method as opposed
        to accessing a data member (obj:method vs obj.data), which I think is a
        no-no for an OO language.

        --
        --- james mccartney
      • Steve Dekorte
        ... A poor choice of words on my part. By that I just meant a key to value mapping. A mapping of a symbol in the source code, say a local variable, to some
        Message 3 of 16 , Dec 1, 2002
        • 0 Attachment
          On Saturday, November 30, 2002, at 08:13 PM, Brian T Rice wrote:
          > What does a key/value hash have anything to do with any of these?

          A poor choice of words on my part. By that I just meant a key to value
          mapping. A mapping of a symbol in the source code, say a local
          variable, to some value, regardless of how the mapping is done(some
          offset in memory if static maybe, a hash table look up if dynamic,
          whatever)

          >> Does this seem like a reasonable break down of these types?:
          >> - Object (a key/value hash)
          >> - on activation: returns self
          >> - parent scope: prototype from which created
          >
          > Why is a prototype a parent?

          That's how inheritance works.

          > This also assumes that there's some notion of activation for every
          > object.

          Right. Io already does this.

          > How do you propose to unify this with, erm, one or all of the three
          > mentioned below?

          Which part wasn't clear?

          > Do objects take positional or keyword arguments? If so,
          > why?

          I'm not sure how this is relevant unless your point is that there is
          extra information about how to process a call that needs to be stored
          somewhere. That information would be stored in one of the
          closure/method/block slots.

          > And how do these differ from slot-specifiers?

          What are slot-specifiers?

          > Also, the notion of an initializer method which is commonly associated
          > with
          > objects-as-activations (in, say, Beta) doesn't really work well without
          > classes, which you don't mention.

          Specifically, what problem do you see?

          Cheers,
          Steve
          OSX freeware and shareware: http://www.dekorte.com/downloads.html
        • Steve Dekorte
          ... It doesn t have to be, but that s the convention I use. ... Blocks don t maintain state between calls. Closures do. Cheers, Steve OSX freeware and
          Message 4 of 16 , Dec 1, 2002
          • 0 Attachment
            On Sunday, December 1, 2002, at 10:31 AM, James McCartney wrote:
            > On Saturday, November 30, 2002, at 05:06 PM, Steve Dekorte wrote:
            >> - Object (a key/value hash)
            >> - on activation: returns self
            >> - parent scope: prototype from which created
            >
            > I don't understand this. I didn't understand it when I read your
            > sources either. In Self, an object's parent(s) is/are the same
            > parent(s) that the prototype it was cloned from had. Why should an
            > object's parent BE the prototype?

            It doesn't have to be, but that's the convention I use.

            > Why should a block and a closure be different?

            Blocks don't maintain state between calls. Closures do.

            Cheers,
            Steve
            OSX freeware and shareware: http://www.dekorte.com/downloads.html
          • Brian T Rice
            ... It s a concept, not something you can take as a convention. If you take copy-on-write semantics, then it makes sense, or embedding-based prototypes, but
            Message 5 of 16 , Dec 1, 2002
            • 0 Attachment
              On Sun, 1 Dec 2002, Steve Dekorte wrote:
              > On Sunday, December 1, 2002, at 10:31 AM, James McCartney wrote:
              > > On Saturday, November 30, 2002, at 05:06 PM, Steve Dekorte wrote:
              > >> - Object (a key/value hash)
              > >> - on activation: returns self
              > >> - parent scope: prototype from which created
              > >
              > > I don't understand this. I didn't understand it when I read your
              > > sources either. In Self, an object's parent(s) is/are the same
              > > parent(s) that the prototype it was cloned from had. Why should an
              > > object's parent BE the prototype?
              >
              > It doesn't have to be, but that's the convention I use.

              It's a concept, not something you can take as a convention. If you take
              copy-on-write semantics, then it makes sense, or embedding-based
              prototypes, but otherwise this makes no sense, since you'd inherit state
              without defining your own. Prototypes are supposed to be cloned or copied,
              not inherited from.

              > > Why should a block and a closure be different?
              >
              > Blocks don't maintain state between calls. Closures do.

              Where the hell did you get that idea? What language does this, and what
              commonly-known text defines closures to do this?

              --
              Brian T. Rice
              LOGOS Research and Development
              mailto:water@...
              http://tunes.org/~water/
            • Steve Dekorte
              ... I don t see why not. If you didn t inherit from them, how would you see class variables? ... Paul Graham s adder example of a closure in LISP does this.
              Message 6 of 16 , Dec 1, 2002
              • 0 Attachment
                On Sunday, December 1, 2002, at 02:02 PM, Brian T Rice wrote:
                >> It doesn't have to be, but that's the convention I use.
                >
                > It's a concept, not something you can take as a convention. If you take
                > copy-on-write semantics, then it makes sense, or embedding-based
                > prototypes, but otherwise this makes no sense, since you'd inherit
                > state
                > without defining your own. Prototypes are supposed to be cloned or
                > copied,
                > not inherited from.

                I don't see why not. If you didn't inherit from them, how would you see
                "class" variables?

                >>> [Closures maintain state between calls]
                > Where the hell did you get that idea? What language does this, and what
                > commonly-known text defines closures to do this?

                Paul Graham's adder example of a closure in LISP does this.
                ( http://www.paulgraham.com/icad.html )

                Cheers,
                Steve
                OSX freeware and shareware: http://www.dekorte.com/downloads.html
              • Brian T Rice
                ... Um, by putting them in the shared parents, the traits objects? Of course most things used as class variables are really just package-specific variables,
                Message 7 of 16 , Dec 1, 2002
                • 0 Attachment
                  On Sun, 1 Dec 2002, Steve Dekorte wrote:

                  > On Sunday, December 1, 2002, at 02:02 PM, Brian T Rice wrote:
                  > >> It doesn't have to be, but that's the convention I use.
                  > >
                  > > It's a concept, not something you can take as a convention. If you take
                  > > copy-on-write semantics, then it makes sense, or embedding-based
                  > > prototypes, but otherwise this makes no sense, since you'd inherit
                  > > state
                  > > without defining your own. Prototypes are supposed to be cloned or
                  > > copied,
                  > > not inherited from.
                  >
                  > I don't see why not. If you didn't inherit from them, how would you see
                  > "class" variables?

                  Um, by putting them in the shared parents, the traits objects? Of course
                  most things used as "class variables" are really just package-specific
                  variables, so even this doesn't have to be used very often. An alternative
                  is just to put them in a particular namespace object, possibly inherited
                  by the package's objects.

                  > >>> [Closures maintain state between calls]
                  > > Where the hell did you get that idea? What language does this, and what
                  > > commonly-known text defines closures to do this?
                  >
                  > Paul Graham's adder example of a closure in LISP does this.
                  > ( http://www.paulgraham.com/icad.html )

                  Oh, of course. I had forgotten about that. However, I usually dislike that
                  use of closures; I guess that's my unfair prejudice. My apologies.

                  --
                  Brian T. Rice
                  LOGOS Research and Development
                  mailto:water@...
                  http://tunes.org/~water/
                • ryan daum
                  ... This is only one of many possible implementations of a prototype inheriting language, and one which borrows terminology and strategy from Self. IMHO,
                  Message 8 of 16 , Dec 1, 2002
                  • 0 Attachment
                    On Sun, 1 Dec 2002, Brian T Rice wrote:

                    > Um, by putting them in the shared parents, the traits objects? Of course
                    > most things used as "class variables" are really just package-specific
                    > variables, so even this doesn't have to be used very often. An alternative
                    > is just to put them in a particular namespace object, possibly inherited
                    > by the package's objects.

                    This is only one of many possible implementations of a prototype
                    inheriting language, and one which borrows terminology and strategy from
                    Self. IMHO, traits objects are not necessary and a chain of behaviour
                    inheritance can be created by dispatching through only a parents slot.
                    Certainly my copy of Cardelli's "A Theory of Objects" doesn't even talk
                    about traits when talking about minimalist prototype inheriting models.

                    I don't agree with some of the specifics of Steve's described model ( I
                    think variable scope is of a different type of namespace entirely from
                    slot scope ) or his use of the term "hash" instead of "association", but I
                    don't see any particular reason to treat his model as some sort of dark
                    heresy.

                    Ryan

                    ____________________________________________________________________________
                    "Look in the mirror and don't be tempted to equate transient domination
                    with either intrinsic superiority or prospects for extended survival."
                    - Stephen J Gould
                    ____ ryan daum ____________________________________ ryan@... _________
                  • Brian T Rice
                    ... Traits objects were only an example of what could be a parent object. In this case, even you are objecting to presentation and not the concept itself. ...
                    Message 9 of 16 , Dec 1, 2002
                    • 0 Attachment
                      On Sun, 1 Dec 2002, ryan daum wrote:

                      > On Sun, 1 Dec 2002, Brian T Rice wrote:
                      >
                      > > Um, by putting them in the shared parents, the traits objects? Of course
                      > > most things used as "class variables" are really just package-specific
                      > > variables, so even this doesn't have to be used very often. An alternative
                      > > is just to put them in a particular namespace object, possibly inherited
                      > > by the package's objects.
                      >
                      > This is only one of many possible implementations of a prototype
                      > inheriting language, and one which borrows terminology and strategy from
                      > Self. IMHO, traits objects are not necessary and a chain of behaviour
                      > inheritance can be created by dispatching through only a parents slot.
                      > Certainly my copy of Cardelli's "A Theory of Objects" doesn't even talk
                      > about traits when talking about minimalist prototype inheriting models.

                      Traits objects were only an example of what could be a parent object. In
                      this case, even you are objecting to presentation and not the concept
                      itself.

                      > I don't agree with some of the specifics of Steve's described model ( I
                      > think variable scope is of a different type of namespace entirely from
                      > slot scope ) or his use of the term "hash" instead of "association", but I
                      > don't see any particular reason to treat his model as some sort of dark
                      > heresy.
                      >
                      > Ryan

                      It's annoying because Steve has met many times with David Ungar et al in
                      person, so it would be much better if his mode of presentation were to
                      explicitly state his context in the matter. I don't object to the idea, I
                      object to the lack of explicit context and background information.

                      I do not lionize the Self language or environment model, but it is a point
                      of reference which I believed was somehow an implicit context when none
                      else is given here, and indeed *none* was given. I have a couple of
                      Mini-CD's left of what Steve was handing out, which are mostly filled with
                      videos of Self, aside from the sundry language implementations, so what am
                      I supposed to think? :)

                      Finally, the language I am working on differs from Self in important ways,
                      and may continue to differ even more as it evolves. (Yes, we have language
                      changes in mind which we are not beyond adopting even with hundreds of
                      lines of code to adjust.)

                      Can we stop talking about objects vs. closures now?

                      --
                      Brian T. Rice
                      LOGOS Research and Development
                      mailto:water@...
                      http://tunes.org/~water/
                    • James McCartney
                      As I understand it, the embedding based model described by Cardelli implements the inheritance of shared parts by using explicit aliasing of slots to other
                      Message 10 of 16 , Dec 1, 2002
                      • 0 Attachment
                        As I understand it, the embedding based model described by Cardelli
                        implements the inheritance of shared parts by using explicit aliasing
                        of slots to other objects. Omega I beleive also does a kind of
                        inheritance where shared data is defined by the prototype, but I don't
                        think in either of these two models there is an explicit parent link to
                        the prototype.

                        On Sunday, December 1, 2002, at 03:07 PM, ryan daum wrote:

                        > This is only one of many possible implementations of a prototype
                        > inheriting language, and one which borrows terminology and strategy
                        > from
                        > Self. IMHO, traits objects are not necessary and a chain of behaviour
                        > inheritance can be created by dispatching through only a parents slot.
                        > Certainly my copy of Cardelli's "A Theory of Objects" doesn't even talk
                        > about traits when talking about minimalist prototype inheriting models.
                        >
                        --
                        --- james mccartney james@... <http://www.audiosynth.com>
                        SuperCollider - a real time synthesis programming language for the
                        PowerMac.
                        <ftp://www.audiosynth.com/pub/updates/SC2.2.16.sea.hqx>
                      • James McCartney
                        yes, but the compiler can determine this and choose the appropriate implementation. The user should not have to bother with which is which. ... -- ...
                        Message 11 of 16 , Dec 1, 2002
                        • 0 Attachment
                          yes, but the compiler can determine this and choose the appropriate
                          implementation. The user should not have to bother with which is which.

                          On Sunday, December 1, 2002, at 01:55 PM, Steve Dekorte wrote:

                          >> Why should a block and a closure be different?
                          >
                          > Blocks don't maintain state between calls. Closures do.


                          --
                          --- james mccartney james@... <http://www.audiosynth.com>
                          SuperCollider - a real time synthesis programming language for the
                          PowerMac.
                          <ftp://www.audiosynth.com/pub/updates/SC2.2.16.sea.hqx>
                        • ryan daum
                          ... We re getting all turned around here -- my point was not to claim that a parent link was the canonical way of handling dispatch in prototype inheriting
                          Message 12 of 16 , Dec 1, 2002
                          • 0 Attachment
                            On Sun, 1 Dec 2002, James McCartney wrote:

                            > As I understand it, the embedding based model described by Cardelli
                            > implements the inheritance of shared parts by using explicit aliasing
                            > of slots to other objects. Omega I beleive also does a kind of
                            > inheritance where shared data is defined by the prototype, but I don't
                            > think in either of these two models there is an explicit parent link to
                            > the prototype.

                            We're getting all turned around here -- my point was not to claim that a
                            parent link was the canonical way of handling dispatch in prototype
                            inheriting languages but to argue that the counter-argument (that one
                            should use traits or something else and that there is some devilry
                            involved in using a parents linkage) to it wasn't terribly valid. I used
                            the Cardelli reference to point that out.

                            What we're trying to do is represent an alternative way of doing the
                            taxonomy of behaviours for objects, through prototypes or some other kind
                            of dispatch. I would hope a diversity of "sundry" implementations would
                            be encouraged and then we see what fails and look at that.

                            Anyways, I didn't like the tone of the discussion (and other arguments
                            I've seen in the past on this list) which seemed to amount to bitterness
                            along the lines of "I've made the Kool-Aid and now nobody is drinking it."

                            So you know, whatever, let a thousand flowers bloom. Etc.

                            Ryan



                            >
                            > On Sunday, December 1, 2002, at 03:07 PM, ryan daum wrote:
                            >
                            > > This is only one of many possible implementations of a prototype
                            > > inheriting language, and one which borrows terminology and strategy
                            > > from
                            > > Self. IMHO, traits objects are not necessary and a chain of behaviour
                            > > inheritance can be created by dispatching through only a parents slot.
                            > > Certainly my copy of Cardelli's "A Theory of Objects" doesn't even talk
                            > > about traits when talking about minimalist prototype inheriting models.
                            > >
                            > --
                            > --- james mccartney james@... <http://www.audiosynth.com>
                            > SuperCollider - a real time synthesis programming language for the
                            > PowerMac.
                            > <ftp://www.audiosynth.com/pub/updates/SC2.2.16.sea.hqx>
                            >
                            >
                            >
                            > To unsubscribe from this group, send an email to:
                            > langsmiths-unsubscribe@yahoogroups.com
                            >
                            >
                            >
                            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                            >
                            >

                            ____________________________________________________________________________
                            "Look in the mirror and don't be tempted to equate transient domination
                            with either intrinsic superiority or prospects for extended survival."
                            - Stephen J Gould
                            ____ ryan daum ____________________________________ ryan@... _________
                          • Marcin 'Qrczak' Kowalczyk
                            ... Closures don t maintain state. Variables maintain state and closures can reference variables. I know what closures are but I don t know if you mean the
                            Message 13 of 16 , Dec 2, 2002
                            • 0 Attachment
                              Sun, 1 Dec 2002 14:24:59 -0800, Steve Dekorte <steve@...> pisze:

                              >>>> [Closures maintain state between calls]
                              >> Where the hell did you get that idea? What language does this, and what
                              >> commonly-known text defines closures to do this?
                              >
                              > Paul Graham's adder example of a closure in LISP does this.
                              > ( http://www.paulgraham.com/icad.html )

                              Closures don't maintain state. Variables maintain state and closures
                              can reference variables.

                              I know what closures are but I don't know if you mean the same, and
                              what do you mean by blocks. I don't see a place for two concepts here.

                              There is one, very simple conceptually thing, which is called
                              a function in functional languages, a block in Smalltalk, a function
                              or function closure in theory, and just a closure in slang.

                              The syntax of such a beast consists of formal parameters and an
                              expression (or perhaps a sequence of statements if the language must
                              distinguish them for some reason). The expression can reference any
                              variables visible at that place. The construct returns an object.

                              The object can be applied to arguments (perhaps via a distinguished
                              method if the language doesn't have the concept of application of an
                              object to objects but does have invoking a method), which evaluates
                              the expression with formal parameters bound to supplied arguments
                              and returns its value.

                              If an object is referenced by a closure, it keeps it alive. If the
                              object is a mutable variable, then the closure has access to its state
                              and all closures refer to the same variable - creation of a closure
                              doesn't clone any objects. If a variable is created within the closure,
                              each closure has a separate copy of course. All that is pretty natural,
                              I don't see any other sensible option.

                              Now, does it describe your closures or blocks?

                              I've heard that in ancient Smalltalks closures were broken: local
                              variable declarations in a closure were silently moved into the method
                              inside which the closure were written. Apart from that, they worked
                              as expected. Did I miss anything?

                              --
                              __("< Marcin Kowalczyk
                              \__/ qrczak@...
                              ^^ http://qrnik.knm.org.pl/~qrczak/
                            • Steven Shaw
                              ... Are these blocks Smalltalk-like blocks and the closures lisp-like closures? I was getting the feeling that they are the same thing. Is it possible to
                              Message 14 of 16 , Dec 2, 2002
                              • 0 Attachment
                                > >> Why should a block and a closure be different?
                                > >
                                > > Blocks don't maintain state between calls. Closures do.

                                Are these blocks Smalltalk-like blocks and the closures lisp-like closures?
                                I was getting the feeling that they are the same thing.

                                Is it possible to return a Smalltalk-block like you can a function in Lisp?

                                Can you access variables other the arguments in a Smalltalk block?

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