[Feature Request] Provide syntactic sugar to make programming in a functional style easier

[astares]

Fix #11587 - implemented #chain and documented ChainProxy based on sample code from @zeroflag together with (clickable) example and tests

[Ducasse]

I suggest to package this extension in Pharo-contribution like that people have to time to think if we want this. I'm not convinced that we want eating error behavior.

[astares]

It has some benefits. It could help writing code that is easier to follow / understand and avoid too many parenthesis/wrong placing of parenthesis.

If we have this as an external package we could not use it in the standard image. We have several places in the image where it could be useful - if one searches for "(((" or "((((" or more. Like:

@Ducasse Can you please ellaborate a little bit more about your concerns?

[isCzech]

FYI Cuis use doublecolon (::) to achieve a similar effect, i.e. to delimit keyword messages (#groupedBy:select: as opposed to #groupedBy: followed by #select:). The sample code would look like:

 #(apple peach banana)
	groupedBy: #size ::
	select: [:each | each size even] ::
	values
	collect: #asCommaString

Unlike your simple solution this requires modifying the compiler.

I don't like swarms of parentheses either, but I fear this creates portability issues and further divergence between Smalltalk dialects. IMHO at least the cores of these systems should stick with the traditional syntax as much as possible.

[astares]

@isCzech Easy sharing among the dialects (see Chunk files, vs. Monticello vs. FileTree vs. Tonel) as well as full dialect compatibility is more a dream than a reality. Even when you manage to load or port code you will have many differences in classes, protocols and methods already, especially as Pharo fixed, cleaned and modified many classes already. There is also a big difference in tooling.

Squeak, Cuis and other dialects do not follow the direction and paths Pharo is taking. They do not support in full Traits, Slots, Packages, Variables as first class objects and so on. If they would be 100% compatible they would end up in being Pharo. And even a compatibility between Squeak and Cuis is not a reality. Dialects will diverge - different communities with different goals and ideas.

Pharo provides "environments" for classes now - in theory (and if used and continued properly) one can have separate class hierarchies with it later to file in a whole hierarchy and packages of other dialects. Also topics like Pharo Bootstrap could be reused (for instance to bootstrap a clean Squeak image). Sure it would be effort but possible. Only time will tell if someone will invest into such things, because then it will be worth to take care.

Pharo is already different (in compiler, hierarchy, frameworks, ...), this is by intention and it expect that it will be even more different over time.

[isCzech]

@astares , yes I agree with all you say :) My note aimed at the very core where the dialects are still very much alike; specifically, contexts and processes where I've done some work recently in all three of them. Truth is Pharo started diverging even in the VM... Other than in the very core I guess it's a useful extension. I've noticed it's a bit slower which is understandable because it employs the exceptions mechanism. In some core methods, I assume, this could potentially cost some performance points, maybe. I would think twice to use it inside e.g. exception methods :)

[guillep]

Hi @astares I propose that we write a Phep for this in (https://github.com/pharo-project/pheps/) and have a broader discussion in the community. What do you think?

GitHub

GitHub - pharo-project/pheps: Pharo Enhancement Proposals

Pharo Enhancement Proposals. Contribute to pharo-project/pheps development by creating an account on GitHub.

[astares]

Yes - a Phep would be needed, but not from my side. Will focus on more important issues currently. I close the PR.