2017-11-07 12:09 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:


2017-11-07 11:36 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:


2017-11-07 11:24 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-11-07 9:23 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
I have other ideas yet.

The selector undefinedFirst is good, but the implementation not so.
I don't like the UndefinedSortFunction: too specific, compose oddly...

In the PR, collatedBy: is the way to tell how we sort properties (if you have a better name, go, it's bikesheding day)

������ "sort by size of name"
������ (people sorted: (#name collatedBy: #size))
�������������� =�� (people sorted: [:p| p name size])

It is nice idea but it should be not bound to sort functions. Because this feature is useful for other block based messages:
people collect: #name >> #size
people select: #name >> #size >> #even
(I use >> as example).��
Generally it is about functional programming. Would be nice to have this in image because it will simplify scripting a lot.��
I remember nice set of blog posts from Vassili Bykov about such kind of things��http://blog.3plus4.org/2007/03/.


This code has a cost, however.

First, it's rather slow (hidden #perform: in there).

Second, I had a first hand experience that it is making it significantly more complex to understand for newcomers (implying that it creates additional, special semantics compared to basic smalltalk). I know that there is no special semantic involved, but it looks as if to practitionners of other programming languages and their complex semantics.

I do like the SortFunctions idea (and its extension), but it's important IMHO to not make it too cryptic.
��
Regards,

Thierry

Hi Thierry
I ear those objections.
Concerning the cost, i wonder what Clement thinks about it.
Repeated perform: could benefit from PIC too, and adaptive inlining.

Hi Nicolas,

I agree it could be optimised away. For now, it is slow. And there is so much for Clement to optimise for.
��

Concerning syntactic sugar (even if it's pure Smalltalk) I have same cicrconspection
In the case of #name >> #size it's like we are creating another language for the basic mechanisms we already have (send messages)
What we try to achieve here is in fact the reify the send, what is not really in the base Smalltalk.
For a more functional style, we would rapidly need currying anyway so even more syntactic sugar...

Yes, that would be my worry. There is a value in keeping simple consistent semantics... especially because there is no one else still maintaining that focus (apart from STEPS that is) and that we are under constant pressure from other languages to add stuff.
��
On the other hand, PetitParser is nice too.

?
��

For SortFunction, I think we all agree that there's no debate, procedural style is so ugly

������ people sorted: [:a :b |
�������������� a name
���������������������� ifNil:
������������������������������ [ b name
���������������������������� �� ���� ifNil: [a age > b age]
���������������������������� �� ���� ifNotNil: [true "a first"]]
���������������������� ifNotNil:
������������������������������ [ b name
���������������������������� �� ���� ifNil: [false "b first"]
���������������������������� �� ���� ifNotNil: [a name = b name
���������������������������������������������� ifTrue: [a age > b age]
���������������������������������������������� ifFalse: [a name < b name]]]

compared to:

������ people sorted: #name ascending undifiedFirst , #age descending

or even

������ people sorted: (#name collatedWith: #isNil) , #age descending

I find that exemple interesting because the obvious solution to the procedural style is to create a nice, correct People>>#>, which is of great value for the overall code understanding. So, is it a good idea to make it easier not to write a proper #>?

10 years ago now, we designed a DSL above our parallel language, with the same kind of tradeoffs you described there. We ended up discarding it, because we had to maintain the full procedural code for the cases we couldn't cover. Discarding it was a wise decision.

Now, if you explained me something like that:

people nilFirst ascending

Then I'd be more convinced. Or even

people sorted nilFirst ascending (if one would prefer restricting the implementations of #nilFirst).

Could the symbol use be a smell of not putting the right responsabilities into the People class?

Thierry
��
������������������������������
����������