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

Re: [Io] 1 := 2

Expand Messages
  • Jeremy Tregunna
    ... If anything, 1 := 2 should work right: Io message(1 := 2) == setSlot( 1 , 2) Right now, this does nothing; doesn t set the slot. However, if you:
    Message 1 of 19 , Apr 1 12:01 AM
    View Source
    • 0 Attachment

      On 1-Apr-06, at 2:53 AM, Jason Grossman wrote:

      If it raises an exception, that could only be because the objects 
      called "1" and "2" are required to be literals; and, what's more, 
      literals that can't be equal to each other.  And that's unnecessary 
      complexity.  I can easily imagine wanting those slots not to be 
      literals, or wanting them to be equal.

      If anything, 1 := 2 should work right:

      Io> message(1 := 2)
      ==> setSlot("1", 2)

      Right now, this does nothing; doesn't set the slot. However, if you: setSlot("1", 2); then getSlot("1"); it would work as expected. I'd vote for this instead of raising an exception. (Though admittingly, I don't find the current behaviour undesirable.)

      Jason


      --

      Jeremy Tregunna

      jtregunna@...


      "Once the rocket goes up, who cares where it comes down? That's not my department."

      -- Wernher von Braun



    • Jeremy Tregunna
      Sorry to reply to myself, but I just checked with the old parser; the behaviour I describe below worked with the old parser, is broke with the new parser. ...
      Message 2 of 19 , Apr 1 12:04 AM
      View Source
      • 0 Attachment
        Sorry to reply to myself, but I just checked with the old parser; the behaviour I describe below worked with the old parser, is broke with the new parser.

        On 1-Apr-06, at 3:01 AM, Jeremy Tregunna wrote:


        On 1-Apr-06, at 2:53 AM, Jason Grossman wrote:

        If it raises an exception, that could only be because the objects 
        called "1" and "2" are required to be literals; and, what's more, 
        literals that can't be equal to each other.  And that's unnecessary 
        complexity.  I can easily imagine wanting those slots not to be 
        literals, or wanting them to be equal.

        If anything, 1 := 2 should work right:

        Io> message(1 := 2)
        ==> setSlot("1", 2)

        Right now, this does nothing; doesn't set the slot. However, if you: setSlot("1", 2); then getSlot("1"); it would work as expected. I'd vote for this instead of raising an exception. (Though admittingly, I don't find the current behaviour undesirable.)

        Jason

        --
        Jeremy Tregunna

        "Once the rocket goes up, who cares where it comes down? That's not my department."
        -- Wernher von Braun




        YAHOO! GROUPS LINKS




        !DSPAM:442e3317503088455286553!


        --

        Jeremy Tregunna

        jtregunna@...


        "Once the rocket goes up, who cares where it comes down? That's not my department."

        -- Wernher von Braun



      • Quag
        Hi Jer, ... I confirm that there is a bug with the new parser which prevents 1 := 2 from working correctly. I ve added the following to my bugs list on
        Message 3 of 19 , Apr 1 12:14 AM
        View Source
        • 0 Attachment
          Hi Jer,

          On 4/1/06, Jeremy Tregunna <jtregunna@...> wrote:
          > Sorry to reply to myself, but I just checked with the old parser; the
          > behaviour I describe below worked with the old parser, is broke with the new
          > parser.

          I confirm that there is a bug with the new parser which prevents 1 :=
          2 from working correctly. I've added the following to my bugs list on
          http://www.quag.geek.nz/io/parser-manifesto.html

          CachedResult is not cleared on the "1" message when it is reused as
          the "setSlot" message.
          Io> 1 := 2
          ==> 1
          Io> getSlot("1")
          ==> nil

          Io> setSlot("1", 2)
          ==> 2
          Io> getSlot("1")
          ==> 2


          > On 1-Apr-06, at 3:01 AM, Jeremy Tregunna wrote:
          >
          >
          >
          > On 1-Apr-06, at 2:53 AM, Jason Grossman wrote:
          > If it raises an exception, that could only be because the objects
          > called "1" and "2" are required to be literals; and, what's more,
          > literals that can't be equal to each other. And that's unnecessary
          > complexity. I can easily imagine wanting those slots not to be
          > literals, or wanting them to be equal.
          >
          > If anything, 1 := 2 should work right:
          >
          > Io> message(1 := 2)==> setSlot("1", 2)
          >
          > Right now, this does nothing; doesn't set the slot. However, if you:
          > setSlot("1", 2); then getSlot("1"); it would work as expected. I'd vote for
          > this instead of raising an exception. (Though admittingly, I don't find the
          > current behaviour undesirable.)
          >
          > Jason
          >
          >
          > --
          > Jeremy Tregunna
          > jtregunna@...
          >
          > "Once the rocket goes up, who cares where it comes down? That's not my
          > department."
          > -- Wernher von Braun
          >
          >
          >
          > ________________________________
          > YAHOO! GROUPS LINKS
          >
          >
          > Visit your group "iolanguage" on the web.
          >
          > To unsubscribe from this group, send an email to:
          > iolanguage-unsubscribe@yahoogroups.com
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          >
          > ________________________________
          >
          >
          > !DSPAM:442e3317503088455286553!
          >
          >
          >
          >
          >
          >
          > --
          >
          > Jeremy Tregunna
          >
          > jtregunna@...
          >
          >
          > "Once the rocket goes up, who cares where it comes down? That's not my
          > department."
          >
          > -- Wernher von Braun
          >
          >
          >
          >
          > ________________________________
          > YAHOO! GROUPS LINKS
          >
          >
          > Visit your group "iolanguage" on the web.
          >
          > To unsubscribe from this group, send an email to:
          > iolanguage-unsubscribe@yahoogroups.com
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          >
          > ________________________________
          >
        • Mike Austin
          ... I don t know, it s kind of strange that obj 10 := 20 treats 10 as a string, where everywhere else it would be a number. 10 is not an identifier, it s a
          Message 4 of 19 , Apr 1 12:35 AM
          View Source
          • 0 Attachment
            Jeremy Tregunna wrote:
            >
            > On 1-Apr-06, at 2:39 AM, Mike Austin wrote:
            >
            >> Then why is the following forbidden, when it's the same as "10 := 20"?
            >> (with 2006-02-14):
            >>
            >> Io> setSlot(10, 20)
            >> Exception: argument 0 to method 'setSlot' must be a Sequence, not a
            >> 'Number'
            >
            > This is forbidden because setSlot() expects a string as its first argument.
            >
            > 10 := 20 is converted to:
            >
            > setSlot("10", 20)
            >
            >> I see where you are coming from with regards to complexity and all
            >> that, but it is really a type error. The expression "1 = 2" is trying to assign
            >> the slot "1" with the value 2. Slots are named entities.. it doesn't make any
            >> sense to give it something other than a symbol/string, and I think giving an
            >> error such as with setSlot() is the right thing to do.
            >
            > Except that it is perfectly legal Io.

            I don't know, it's kind of strange that obj 10 := 20 treats 10 as a string,
            where everywhere else it would be a number. 10 is not an identifier, it's a
            literal, and it just feels inconsistent. For example, the BNF for := might
            look something like this:

            <identifier> ":=" <expression>

            No where else can you use 10 as an identifier. Thats a very specific rule, the
            opposite of generality. So in the attempt of being more general, it actually
            is not. That's my case, and I'm sticking to it :)


            Mike
          • Erik Max Francis
            ... I agree. At the very least, `a := b` is supposed to be equivalent to `setSlot(a, b)`. If they both fail, but fail in different ways, that s pretty
            Message 5 of 19 , Apr 1 12:39 AM
            View Source
            • 0 Attachment
              Mike Austin wrote:

              > I don't know, it's kind of strange that obj 10 := 20 treats 10 as a string,
              > where everywhere else it would be a number. 10 is not an identifier, it's a
              > literal, and it just feels inconsistent. For example, the BNF for := might
              > look something like this:
              >
              > <identifier> ":=" <expression>
              >
              > No where else can you use 10 as an identifier. Thats a very specific rule, the
              > opposite of generality. So in the attempt of being more general, it actually
              > is not. That's my case, and I'm sticking to it :)

              I agree. At the very least, `a := b` is supposed to be equivalent to
              `setSlot(a, b)`. If they both fail, but fail in different ways, that's
              pretty confusing.

              --
              Erik Max Francis && max@... && http://www.alcyone.com/max/
              San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
              A father is a thousand schoolmasters.
              -- Louis Nizer
            • Jason Grossman
              ... Seems to me that it treats 10 as an object and 10 as a string which is the name of the object. Jason
              Message 6 of 19 , Apr 1 12:59 AM
              View Source
              • 0 Attachment
                On 01/04/2006, at 7:35 pm, Mike Austin wrote:

                > I don't know, it's kind of strange that obj 10 := 20 treats 10 as
                > a string

                Seems to me that it treats 10 as an object and "10" as a string which
                is the name of the object.

                Jason
              • Mike Austin
                ... So then in `obj foo := 20`, foo is an object with the name foo ? I don t think of foo as an object, just the name of a slot, a binding. Then there s
                Message 7 of 19 , Apr 1 1:47 AM
                View Source
                • 0 Attachment
                  Jason Grossman wrote:
                  > On 01/04/2006, at 7:35 pm, Mike Austin wrote:
                  >
                  >> I don't know, it's kind of strange that obj 10 := 20 treats 10 as
                  >> a string
                  >
                  > Seems to me that it treats 10 as an object and "10" as a string which
                  > is the name of the object.
                  >
                  > Jason

                  So then in `obj foo := 20`, foo is an object with the name "foo"? I don't
                  think of foo as an object, just the name of a slot, a binding.

                  Then there's other semantic peculiarities:

                  obj := Object clone
                  obj x := 20
                  obj 5 := 20
                  obj x
                  ==> 20
                  obj 5
                  ==> 5

                  Why wouldn't this work on the same principal as := ?

                  It's not a big issue, like you have said, but I do think it's an inconsistency.


                  Mike
                • Quag
                  Hi Erik, ... I believe you meant that a := b is supposed to be equivalent to setSlot( a , b) . As I said in my response to Jer, it is a bug in the new
                  Message 8 of 19 , Apr 1 2:04 AM
                  View Source
                  • 0 Attachment
                    Hi Erik,

                    On 4/1/06, Erik Max Francis <max-gmane@...> wrote:
                    > Mike Austin wrote:
                    >
                    > I agree. At the very least, `a := b` is supposed to be equivalent to
                    > `setSlot(a, b)`. If they both fail, but fail in different ways, that's
                    > pretty confusing.

                    I believe you meant that 'a := b' is supposed to be equivalent to
                    'setSlot("a", b)'.

                    As I said in my response to Jer, it is a bug in the new parser which
                    means this is not the case when literal values are used for a. The
                    issue is to do with messages not being cleaned off properly before
                    they are reused during the operator message transformations.

                    The bug can be demonstated in the interpretor.

                    # Make sure 1 := 2 is parsed correctly.

                    Io> message(1 := 2)
                    ==> setSlot("1", 2)

                    # Check what happens when 1 := 2 is run.

                    Io> 1 := 2
                    ==> 1 # wait a minute... why did that return 1?!
                    Oh, yes the cached result of setSlot is still 1 due to the bug.
                    Because the setSlot message has a cached result, the setSlot message
                    will never be sent to the local scope. Instead the cached result is
                    returned immediately.
                    Io> getSlot("1")
                    ==> nil

                    # Now check using the resulting message setSlot("1", 2)

                    Io> setSlot("1", 2)
                    ==> 2 # returns 2 as expected.
                    Io> getSlot("1")
                    ==> 2

                    # Different results even though they should be the same.

                    Jonathan.
                  • Jeremy Tregunna
                    ... No, that s not how a := b is supposed to be handled. a := b is supposed to be handled like: setSlot( a , b). ... -- Jeremy Tregunna
                    Message 9 of 19 , Apr 1 2:04 AM
                    View Source
                    • 0 Attachment

                      On 1-Apr-06, at 3:39 AM, Erik Max Francis wrote:

                      Mike Austin wrote:

                      > I don't know, it's kind of strange that  obj 10 := 20  treats 10 as a string,
                      > where everywhere else it would be a number.  10 is not an identifier, it's a
                      > literal, and it just feels inconsistent.  For example, the BNF for := might
                      > look something like this:
                      >
                      > <identifier> ":=" <expression>
                      >
                      > No where else can you use 10 as an identifier.  Thats a very specific rule, the
                      > opposite of generality.  So in the attempt of being more general, it actually
                      > is not.  That's my case, and I'm sticking to it :)

                      I agree.  At the very least, `a := b` is supposed to be equivalent to
                      `setSlot(a, b)`.  If they both fail, but fail in different ways, that's
                      pretty confusing.

                      No, that's not how "a := b" is supposed to be handled. "a := b" is supposed to be handled like: setSlot("a", b).

                      Erik Max Francis


                      --

                      Jeremy Tregunna

                      jtregunna@...


                      "Once the rocket goes up, who cares where it comes down? That's not my department."

                      -- Wernher von Braun



                    • Jeremy Tregunna
                      ... You ll note that the following creates a slow called foo (including the quotes): Io foo := bar == bar Io getSlot( foo ) == bar This is
                      Message 10 of 19 , Apr 1 2:11 AM
                      View Source
                      • 0 Attachment

                        On 1-Apr-06, at 3:35 AM, Mike Austin wrote:

                        I don't know, it's kind of strange that  obj 10 := 20  treats 10 as a string,
                        where everywhere else it would be a number.

                        You'll note that the following creates a slow called "foo" (including the quotes):

                        Io> "foo" := "bar"
                        ==> "bar"
                        Io> getSlot("\"foo\"")
                        ==> "bar"

                        This is the case for anything directly to the left of a := (that is, the first message to the left). Consider setSlot() implemented in Io like:

                        setSlot := method(
                          name := call argAt(0) name
                          body := call argAt(1)
                          /* call a primitive method which actually does the setting */
                        )

                        That's my case, and I'm sticking to it :)

                        Not a case I'd want to stand on in court. :)

                        Mike


                        --

                        Jeremy Tregunna

                        jtregunna@...


                        "Once the rocket goes up, who cares where it comes down? That's not my department."

                        -- Wernher von Braun



                      • Erik Max Francis
                        ... Good point, my bad. Still, if `a := b` is supposed to be equivalent to `setSlot( a := b)` -- that is to say, the identifier `a` is intended to be
                        Message 11 of 19 , Apr 1 2:13 AM
                        View Source
                        • 0 Attachment
                          Quag wrote:

                          > I believe you meant that 'a := b' is supposed to be equivalent to
                          > 'setSlot("a", b)'.

                          Good point, my bad. Still, if `a := b` is supposed to be equivalent to
                          `setSlot("a" := b)` -- that is to say, the identifier `a` is intended to
                          be replaced with a string literal, I think it makes a lot more sense for
                          there to be a complaint that it doesn't seem to be doing what it usually
                          does when it comes to literals that don't valid "identifiers." In
                          effect this is an exposed implementation detail that is not obvious; I
                          really don't see the point in preserving it.

                          --
                          Erik Max Francis && max@... && http://www.alcyone.com/max/
                          San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
                          Democritus may have come from Abdera, but he was no dummy.
                          -- Carl Sagan
                        • Quag
                          Hi Erik, ... Io has a weird take on identifiers. An Identifier in Io is something which can be used as a slot name. Slot names must be strings, so identifiers
                          Message 12 of 19 , Apr 1 2:52 AM
                          View Source
                          • 0 Attachment
                            Hi Erik,

                            On 4/1/06, Erik Max Francis <max-gmane@...> wrote:
                            > Quag wrote:
                            >
                            > > I believe you meant that 'a := b' is supposed to be equivalent to
                            > > 'setSlot("a", b)'.
                            >
                            > Good point, my bad. Still, if `a := b` is supposed to be equivalent to
                            > `setSlot("a" := b)` -- that is to say, the identifier `a` is intended to
                            > be replaced with a string literal, I think it makes a lot more sense for
                            > there to be a complaint that it doesn't seem to be doing what it usually
                            > does when it comes to literals that don't valid "identifiers." In
                            > effect this is an exposed implementation detail that is not obvious; I
                            > really don't see the point in preserving it.

                            Io has a weird take on identifiers. An Identifier in Io is something
                            which can be used as a slot name. Slot names must be strings, so
                            identifiers can be any string. The parser places a few additional
                            constraints on identifiers containing white space and characters like
                            , ; ( ). Which loosens the definition of identifiers to be all strings
                            which don't contain white space, or any of the characters in ",:()".

                            Numbers, strings and operators are viewed as special identifiers. They
                            are still identifiers but they sometimes have speical data attached or
                            automatically trigger message rearranging during parse.

                            Io's unusual take on identifiers is due to how it treats everything as
                            a message send. The name of the message (the identifier) is a string.
                            Even if the parser doesn't allow a way to create a particular string,
                            it is still valid to dynamically create a message which uses such a
                            string. Objects have no problem responding to messages containing
                            names (identifiers) which contain spaces, ",;()", operators, number
                            literals or string literals.

                            If you want me to elaborate on this topic let me know.

                            Jonathan.
                          • Erik Max Francis
                            ... This still doesn t explain why `a := b` and `setSlot( a , b)` behave differently even though they re supposed to be identical. -- Erik Max Francis &&
                            Message 13 of 19 , Apr 1 11:50 AM
                            View Source
                            • 0 Attachment
                              Quag wrote:

                              > Io's unusual take on identifiers is due to how it treats everything as
                              > a message send. The name of the message (the identifier) is a string.
                              > Even if the parser doesn't allow a way to create a particular string,
                              > it is still valid to dynamically create a message which uses such a
                              > string. Objects have no problem responding to messages containing
                              > names (identifiers) which contain spaces, ",;()", operators, number
                              > literals or string literals.

                              This still doesn't explain why `a := b` and `setSlot("a", b)` behave
                              differently even though they're supposed to be identical.

                              --
                              Erik Max Francis && max@... && http://www.alcyone.com/max/
                              San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
                              I dream things that never were and say, "Why not?"
                              -- Robert F. Kennedy (after George Bernard Shaw)
                            • Brian Mitchell
                              ... The reason you are seeing the := value bug in the current parser is because of two things: 1) When Io encounters a literal in code it will create
                              Message 14 of 19 , Apr 1 12:08 PM
                              View Source
                              • 0 Attachment
                                On 4/1/06, Erik Max Francis <max-gmane@...> wrote:
                                > This still doesn't explain why `a := b` and `setSlot("a", b)` behave
                                > differently even though they're supposed to be identical.

                                The reason you are seeing the <literal> := value bug in the current
                                parser is because of two things:

                                1) When Io encounters a literal in code it will create a message but
                                along with that it will set the cached result to the literal's
                                immediately apparent value.

                                2) The current parser reuses messages while performing the :=
                                transformation. While this is normally an ok procedure, the cached
                                result is still set. This will result in it returning the cached
                                result but not actually perform the now "setSlot" message.

                                Part 2 is what is being considered buggy. Hopefully all non-ambiguous
                                identifiers and literals will be supported in the future. We might
                                even be able to generalize the parsing behavior to allow almost any
                                lhs to := as long as it does not have a space, "()", "=",or other
                                special patterns in it but that is probably far future from our
                                current capability.

                                I hope that helps.

                                Brian.
                              Your message has been successfully submitted and would be delivered to recipients shortly.