[Cuis-dev] extending the syntax for blocks and methods
stephen at heaveneverywhere.com
stephen at heaveneverywhere.com
Sun Jul 17 09:05:50 PDT 2022
What I’m talking about is simpler than currying.
In VisualWorks, if you get a MessageNotUnderstood, the VM actually sends the message “messageNotUnderstood” to the receiver, allowing you to override it.
I use this in several places in the Siren music system, among others to activate blocks using a more readable message than value:value:, i.e., add:to: in the example I gave.
It’s very simple and doesn’t change or extend Smalltalk syntax at all.
stp
--
Stephen Travis Pope Ojai, California, USA
http://HeavenEverywhere.com <http://heaveneverywhere.com/> http://FASTLabInc.com <http://fastlabinc.com/>
https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos> http://heaveneverywhere.com/Reflections
--
> On Jul 16, 2022, at 10:52 PM, Benoit St-Jean <bstjean at yahoo.com> wrote:
>
> You mean "currying" as in this?
>
> https://web.archive.org/web/20080106132736/https://blog.3plus4.org/2007/03/23/currying-in-smalltalk/ <https://web.archive.org/web/20080106132736/https://blog.3plus4.org/2007/03/23/currying-in-smalltalk/>
>
>
>
>
> On Sunday, July 17, 2022 at 01:27:57 a.m. EDT, stephen--- via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
>
>
>
> I did a hack a while back in VisualWorks (overriding messageNotUnderstood:) so that blocks would understand any messages sent to them as variations of value:value:.
> If you parse the message that’s not understood, get the number of arguments, and then send the right version of value:value: with the arguments, you can create a block with any number of arguments and use it with any calling method, as in,
>
> | summer sum |
> summer := [ :a :b | a + b].
> sum := summer add: 1 to: 2.
>
>
> stp
>
>
> --
>
> Stephen Travis Pope Ojai, California, USA
> <pastedGraphic.tiff> http://HeavenEverywhere.com <http://heaveneverywhere.com/> http://FASTLabInc.com <http://fastlabinc.com/>
> https://vimeo.com/user19434036/videos <https://vimeo.com/user19434036/videos> http://heaveneverywhere.com/Reflections <http://heaveneverywhere.com/Reflections>
>
> --
>
>
>
>
>> On Jul 16, 2022, at 2:51 AM, Luciano Notarfrancesco via Cuis-dev <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>> Hola!
>> Interesting. Actually methods written like this look more complicated than the original Smalltalk-80 syntax to me, but it’s an interesting idea, maybe looks complicated just because I’m not used to it. Let us know how it goes.
>>
>> Note that in Cuis #: is a valid binary message. I use it, maybe I’m the only one who uses it.
>>
>> Another idea we discussed before was to compile ‘f(x)’ as ‘f value: x’. Note that this is not ambiguous with Smalltalk-80. We could also compile ‘a[i]’ as ‘a at: i’. I’m not sure if it’s worth to complicate the Smalltalk-80 syntax with things like this, tho, I also value simplicity.
>>
>>
>> On Sat, 16 Jul 2022 at 01:39 Francisco Garau via Cuis-dev <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>> Hola Amigos -- just wanted to share with you some ideas I've been thinking about for a while.
>>
>> It all started when someone mentioned the colon in the syntax for block arguments could have whitespace around the argument so that you could write [ : n | n + 1]
>>
>> It makes perfect sense to see the block as an "inlined" method that doesn't require any method-lookup; therefore, the selector is superfluous. But if we accepted the selector inside the block, it could be used as the variable holding the block. So, instead of writing succ := [:n | n + 1] we could write [succ: n | n + 1]
>>
>> Even better if the block evaluation accepts #: as a valid selector. So you could write (succ: 3) = 4 instead of (succ value: 3) = 4.
>>
>> A short example will make this clear.
>>
>> Vanilla Smalltalk
>> succ := [:n | n + 1].
>> (succ value: 3) = 4.
>>
>> Extended Block Syntax
>> [succ: n | n + 1].
>> (succ: 3 ) = 4.
>> "the above is equivalent to"
>> (succ perform: #: with: 3) = 4.
>>
>> Being able to parse blocks with these syntax paves the way to unify the syntax for method definition—for example, a few hypothetical methods from the Point class.
>>
>> "Point class>x:y:"
>> [x: xInteger y: yInteger |
>> ^self basicNew setX: xInteger setY: yInteger].
>>
>> "Point>>abs"
>> [abs |
>> ^x abs @ y abs].
>>
>> "Point>>extent:"
>> [extent: aPoint |
>> ^Rectangle origin: self extent: aPoint]
>>
>> Of course, it gets trickier when blocks have more than one argument..
>>
>> [add: a to: b | a + b].
>> (add_to value: 3 value: 4) = 7. "old style block evaluation"
>> (add: 3 to: 4) = 7.
>>
>> I think building a separate Parser is a sensible approach -- is there a Smalltalk Parser as a separate package that can be tweaked without affecting the running image?
>>
>> Thanks,
>> Francisco
>>
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>> https://lists.cuis.st/mailman/listinfo/cuis-dev <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev <https://lists.cuis.st/mailman/listinfo/cuis-dev>
> <pastedGraphic.tiff>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220717/c76e6c5d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220717/c76e6c5d/attachment-0001.tiff>
More information about the Cuis-dev
mailing list