[Cuis-dev] Language constructs

[Nicolas Cellier]

For myself, I find the { } syntax very short and useful. I use it a lot
even if it reduces a bit portability.
Also note that the construct is supported by dedicated byteCodes.

I like the Float64Array extension #[ 1.0 3.5 ], maybe it should be
generalized in Squeak/Pharo.
But we should also optimize the class with same set as primitives as
FloatArray, which is IMO even more useful.

Note the alternative to backticks that can be used in Squeak: ^[ 0 at 0 ] once.
It does not require a new syntax, just an elegant trick.
But it costs 3 message send and 2 Dictionary lookup at runtime though...
With pre-existing Dolphin ##( 0 at 0 ) we now have at least 2 syntaxes and 3
ways to achieve the same effect in Smalltalk, which is not ideal...

I would vote for immutability of all literals including backticks. That's
the least surprising.
Otherwise, if you mutate the literal, then the code shows a non
corresponding value, which is misleading.
The first time I was bitten with this was in st80 in the late eighties...
I discovered that I could write (WriteStream on: 'some literal') which was
much shorter than (WriteStream on String new; nextPutAll: 'same literal';
yourself).
But WriteStream did use a become: under the hood when writing past the
destination size, and as a newbie, it tooks me some time to understand why
my nicer code would not give the expected result twice :)

Le ven. 1 mai 2020 à 17:20, Erik Stel via Cuis-dev <cuis-dev at lists.cuis.st>
a écrit :

> Hi,
>
> I’m also in a bit of a limbo with respect to immutable. From the
> perspective of Ken’s explanation it sounds like a no-brainer: yes want
> this. From the ‘change everything’ in Smalltalk style, nothing should be
> really immutable. Sure, you could try to prevent certain things from
> changing by preventing the regular object interface from making chances,
> but what if I’m inside a debugger or an inspector and want to fiddle with
> instances I have at hand? Especially with collection like instances. And
> yes, you could probably create a new instance that would contain the same
> elements except for the one you want to change (and do a become: like
> magic), but I think other code might fail because of expecting immutable
> behaviour (copies in other processes not getting updated or what not). (And
> contrary to this, I’m happy Numbers and Symbols, etc are immutable, but I
> think the discussion was more aimed at other objects becoming immutable.
> Like arrays, but probably other ‘custom’ objects as well.)
>
> Just to be clear: I’m not trying to criticise everything. I do try to
> challenge myself in thinking if things are okay the way they are and try to
> find reasoning (with your help at the moment ;-) for it.
>
> I really like these discussions to get a better understanding of both
> history and current situation and our wants and needs.
>
> Thx everyone for chiming in!
> Erik
>
> > On 1 May 2020, at 16:58, Juan Vuletich <juan at jvuletich.org> wrote:
> >
> > On 5/1/2020 11:21 AM, ken.dickey--- via Cuis-dev wrote:
> >> On 2020-05-01 00:45, Erik Stel via Cuis-dev 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?
> >>>
> >>> 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.
> >>
> >> Erik,
> >>
> >> I think that array literals are quite useful.  As we move toward
> multi-core VMs, marking out constant data and using functional data
> structures (e.g. ropes), lockless queueing, and so forth are  becoming more
> important.  Also, more interactions with GPUs favors cheap copies --
> constants allow for that.  Simplifies the deep semantics.
> >
> > WRT this, I think that _all_ literals should be immutable.
> >
> >> Not sure of the `#history`.
> >
> > Went in detail in another message.
> >
> >> Oh, BTW, we should add something to the #syntax section of the Terse
> Guide on :: ; `` et al.
> >
> > :+1:
> >
> >> Cheers,
> >> -KenD
> >
> > 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
> >
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200501/203606d2/attachment.htm>