On Fri, Sep 4, 2009 at 11:53 AM, Dan Ingalls<Dan at squeakland.org> wrote:

> I need to think about this some more and, more importantly, look at and write some code.  We do a lot of point and rectangle arithmetic which needs returns, as in
>
>        var loc = m.bounds().center().plus(delta)
> <==>
>        loc = m bounds center addPt: delta
>
> How would you go about this?

I'm not sure I see the problem... let me clear up a possible point of
confusion.  It's not that methods don't have a return value, it's that
methods, like blocks, always return the value of their last statement
(instead of having explicit returns with ^ ).  Or am I missing what
you're asking?

> ...and while we're on the topic of point arithmetic, it drives me nuts that JS won't let you add infix methods.  You can put them in the dictionary, but you can't call them.  What I've thought of is to use St's aggregated infix for non-number users of '+', so 'a + b' translates to  'a + b' for numbers and, eg, 'a &+ b' translates to 'a plus b' for points, dates and the like.
>
> That at least gives us...
>
>        loc = m bounds center &+ delta
>
> I've thought of using '.' for this case, because it is so much less intrusive, as...
>
>        loc = m bounds center .+ delta

FWIW: in clamato,

         a + b

becomes

         a.$plus(b)

It sounds like you're trying to map smalltalk selectors to existing,
equivalent javascript method names, whereas I'm intentionally mangling
them (foo:bar: becomes _foo_bar_) to avoid clashes with any methods
that might already be there.  This means you need to explicitly wrap
any Javascript methods you might want to use in primitives.

> That said, though, are you open to a possible collaboration to put a bit more attention on making it the best it can be without making it significantly more complicated.

Absolutely.  I would be delighted to have more collaboration on this
(and honored, Dan, to have yours) - though of course I also reserve
the right to ignore any and all suggestions :)

> I'm still interested in my Lively April Fools prank, and it *could* have huge synergy with what you are doing if we agreed on the language.  You might find that an entire Lively Kernel running in Clamato was a nice reservoir to draw on.

Sure.  I don't know too much about what Lively requires of its
classes, but it can't be too hard to make this work.  Though I should
note that I personally am more interested in a DOM-based UI than in
canvas or SVG (the DOM is, of course, much more limiting, but it's
also more familiar to most users and that's important for adoption).

> Have you integrated this development environment with a repository (haven't gone through your code yet)?  We're very happy with our browser hookup that works with a local version of our repository by live WevDAV hookup.

Yes, we do what's probably the same thing - every time you save a
method, a new version of the file is saved over WebDAV.

Avi