I'm beginning to have doubts about String mutability. Fortunately the only actually mutating method at the moment is append, which is redundant with add but for the mutability, so I might just tear that out.
Required parentheses on functions are pretty unfortunate. I'm mainly trying to avoid the situation in Ruby where trying to access functions as first-class objects requires all sorts of weird syntactic overhead. Possibly I could have some kind of prefix operator, so (say) &obj.method would return the function object, and obj.method would call it?
I agree about the ':' 'do/end' ugliness. Originally blocks were delimited by braces, but I think the Ruby-style delimiters look nicer. Frankly I'd prefer to get rid of the ':', but for single-expression functions that looks pretty awful. I could do Haskell-style '=' (Haskell of course being where the 'function-body-is-single-expression' thing came from), but
fn foo(x) = do
...
end
is also pretty weird-looking; kind of like Scala's function definitions, which I find really abrasive for reasons I can't fully explain.
Binding 'self' is also basically a compromise. Originally it was stored in the method, but that required copying each type's methods (and each parents' methods) into an object on instantiation, which was a pretty much unacceptable performance hit. My thinking is that, whenever you'd want to pass a method 'obj.method', it's equally possible to pass 'fn (x): obj.method(x)'.
I need to rework the 'try...catch' statements in any case; their current semantics are incredibly horrible (it wraps, then immediately calls, the try body in a temporary lambda). Maybe I will just incorporate them into blocks— thanks for the idea!
Originally it was stored in the method, but that required copying each type's methods (and each parents' methods) into an object on instantiation, which was a pretty much unacceptable performance hit.
I think more a typical solution is to dynamically bind `self` like you do now on normal method calls. But when a reference to a method is stored, you bind `self` to the original receiver at that point in time.
Comments
Not at all— any feedback is appreciated :)
I'm beginning to have doubts about String mutability. Fortunately the only actually mutating method at the moment is append, which is redundant with add but for the mutability, so I might just tear that out.
Required parentheses on functions are pretty unfortunate. I'm mainly trying to avoid the situation in Ruby where trying to access functions as first-class objects requires all sorts of weird syntactic overhead. Possibly I could have some kind of prefix operator, so (say) &obj.method would return the function object, and obj.method would call it?
I agree about the ':' 'do/end' ugliness. Originally blocks were delimited by braces, but I think the Ruby-style delimiters look nicer. Frankly I'd prefer to get rid of the ':', but for single-expression functions that looks pretty awful. I could do Haskell-style '=' (Haskell of course being where the 'function-body-is-single-expression' thing came from), but
is also pretty weird-looking; kind of like Scala's function definitions, which I find really abrasive for reasons I can't fully explain.Binding 'self' is also basically a compromise. Originally it was stored in the method, but that required copying each type's methods (and each parents' methods) into an object on instantiation, which was a pretty much unacceptable performance hit. My thinking is that, whenever you'd want to pass a method 'obj.method', it's equally possible to pass 'fn (x): obj.method(x)'.
I need to rework the 'try...catch' statements in any case; their current semantics are incredibly horrible (it wraps, then immediately calls, the try body in a temporary lambda). Maybe I will just incorporate them into blocks— thanks for the idea!
I think more a typical solution is to dynamically bind `self` like you do now on normal method calls. But when a reference to a method is stored, you bind `self` to the original receiver at that point in time.
Basically, you treat it like a closure.