Re: Assignment Operators

Jeremy Tregunna <[email protected]> Thu, 17 May 2012 08:21:11 -0600
Newsgroups gmane.comp.lang.io
Message-ID <[email protected]>
On Thursday, 17 May, 2012 at 12:19 AM, Kevin Edwards wrote:
>   
> On 5/16/2012 4:16 PM, Jeremy Tregunna wrote: 
> > Think of this psuedo-c code:
> > 
> > (&foo).set(1); 
> > 
> > This above code would be seen as this: Get the address of some fictitious "foo" variable, and then set its value to 1. "foo" need not be in scope; if it's not, it would pick a location and return that. This works best in cases where you expose the underlying structure of your slot table in a meaningful way. You can make that intermediary an object, and return that from the 'address of' operator. 
> So, Io's `target setSlot(name, value)` would become `target &name set(value)` where the `&` combines the target and the literal "name" into a Slot object with the usual get, set, delete, etc. methods.  Is that right?  :-)
While I haven't settled on a syntax for it (or rather, API calls as assignment will be relegated to runtime), it's reasonable to assume it'll look something like:

target name: value # If we special case our single argument syntax extension

or

target set: name to: value

Where the above would be parsed as such:

target set(name) to(value)

In the first case, we'd special case name: value to act as a setter in the case when the message name isn't found. I'm not a fan of this approach, though I like the syntax, because we will allow overriding of the message receive phase of dispatch at a future point, which means users could change the way this works under the hood, surprising users. Not normally something I'm concerned with, in a case of assignment, it's a big concern of mine, since all we have is state, so binding state to names is something we do a lot.
> This idiom could almost be generalized for partial evaluation and keyword arguments.  Are you heading in that direction?
Not by design, but partial evaluation does interest me for one operating mode of my frontend. However, keyword arguments do not interest me at all, and are something I really don't want. If you want to use multiple single arg messages to simulate keyword sends, then by all means, that's entirely up to you and your program. I won't' like it, but I don't think that matters much to the average user. :)
> Kevin
Regards,

Jeremy Tregunna