A provocative naming idea for "setter" methods

[Brian Rice]

On Sep 20, 2005, at 4:11 AM, Lendvai Attila wrote:

> I would vote for this: (probably easier for the parser and the eye)
>
> myObject =x 3.
> window =top 200.

Hm, and interesting alternative to x=, and it would also NOT require  
a lexer change:

Slate 14> =x 4.
The following condition was signaled:
The method #'=x' was not found for the following arguments:
{lobby. 4}

So, there's less effort needed to accommodate this, but it looks  
slightly less natural than x=. However, it's easier to see that this  
is not a comparison, so that's also good.

This seems to have the most going for it, assuming others agree. But  
we should also evaluate whether x= should be a valid binary selector  
vs. unary.

Note that x? is valid as a unary selector, but we prefer isX for that  
idiom even if single-argument queries could use that.

> but otherwise I like the idea and the will to address issues like  
> this.
> In general I prefer to clearly see (even better if formally
> annotated/askable) code properties like side-effect-free, etc.

That's a good point.

> Of course when a graphical code editor will be working directly on the
> Syntax nodes, these issues will have much better solutions.

Substitute "could" for "will", since we'll still need to put effort  
and thought into it there. :) But substantially you are right.

> - 101
>
> PS: where is Olli, who was working on the unicode support? it still
> needs to be bootstrapped...

That's something I've forgotten! :( I'll ask him on email whether he  
still has time. Otherwise, his code should still mostly work and can  
probably be managed at least in a maintenance and upgrade mode.

--
-Brian