[Cuis-dev] Language constructs

[Juan Vuletich]

On 5/1/2020 5:19 AM, Phil B via Cuis-dev wrote:
> Erik,
>
> On Fri, May 1, 2020 at 3:46 AM Erik Stel via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
>     Maybe I wasn’t clear (because it was part of another topic, see
>     below) or tread on a sensitive subject, but I’m still eager to
>     hear the reasoning for having backticks (which are not in Squeak
>     nor Pharo) from the simplicity point of view. Would anyone care to
>     elaborate?
>
>
> Years ago I noticed that we had a lot of pointless dynamism in the 
> image especially since moving to local coordinates (i.e. we had 0 at 0 
> all over the image.)  In an attempt to *not* extend the language,  I 
> proposed Point class>>zero for effectively a singleton 0 at 0 instance.  
> Juan surprised me and effectively said 'I don't like that, let's go 
> this way instead' (i.e. backticks).  It was a pretty elegant and 
> minimal solution so I didn't have a problem with it at the time and it 
> has definitely grown on me.  While addressing 0 at 0 was the initial 
> motivation, it is useful anywhere you want to create ad hoc literals.  
> I use it a ton and only wish we went a little further and had a full 
> macro system in Smalltalk ;-)

Just in case, let me tell why I prefer the backticks to the Point zero 
singleton.
- Point zero only works for Points. And just for one specific value: 
0 at 0.  Backticks work with any object.
- Point zero saves memory, but not message sends. Backticks saves both.
- The ratio complexity/uses (if that can be meaningfully defined) is 
much lower for backticks.

Still, they are not exactly the same. Point zero would allow having a 
single zero point for all the system (like Symbols). Backticks require 
having one instance of 0 at 0 on each method.

It's all about tradeoffs.

>
> As far as compatibility with Squeak and Pharo... well that's extremely 
> problematic IMO.  Pharo changes things all the time (and not always 
> for the better) seemingly based on the weather.  So any attempt to 
> keep in sync with it would mean breaking Cuis whether or not we 
> thought the change was a good idea.  Squeak has the opposite problem: 
> it doesn't change much at all.  To some, this is an asset, to me it's 
> a liability: I don't mind working with an obscure/fringe language, I 
> do mind working with a dead language.  To me, Smalltalk-80 was great 
> 40 years ago but should not be the final stop in language evolution.
>
>
>     I am also eager to know what others think about language
>     constructs such as #(), {} and `` for daily usage. And I mean this
>     in the sense ‘Do you use these often? Could you live without
>     them?’. I do understand how they can be used and what their
>     meaning is ;-). And I can also lookup their current use in the
>     default image, but that does not answer how you/we use them in our
>     (application) code.
>
>
> I tend to use {} more than #(), but I do use both of those as well.  
> My only gripe is that all of the damned brackets have been used up by 
> Smalltalk (as most other languages do as well)... I really would have 
> liked to have at least one set of brackets that were available for 
> 'user-defined' purposes but, oh well.
>
>
>     Kind regards,
>     Erik
>
>
> Thanks,
> Phil

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200501/fe6a0436/attachment-0001.htm>