November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

I have new question. Why we really need threeWayCompareTo:? DefaultSortFunction can implement it using standard comparison methods. 2017-11-05 0:37 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi all, > I started a discussion with Denis in a pull request > https://github.com/pharo-project/pharo/pull/430 > But since it's going beyond simple code review, it probably has a better > place here. > > First, I want to say thanks for enriching this original work of Travis > Griggs. > http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html > http://objology.blogspot.fr/2010/11/tag-sortfunctions.html > <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> > > Of course, I'm never satisfied. > So I don't really appreciate the rewrite of space ship operator <=> into a > more heavy threeWayCompareTo: > > In my eyes, it's so obvious that <=> means < or = or > in the context of > SortFunction > And also that the order matches the signs > < = > > -1 0 1 > IOW result will be -1 if receiver is <, 0 if equal, +1 if superior > > #threeWayCompareTo: does not tell as well. > But maybe It's a question of taste and I don't have the same eyes as Pharo > people? > To me it's also a question of respect to the original author, don't change > a good selector for the sake of changing. > > Apart this detail, I wanted to speak about SortByPropertyFunction. > SortByProperty is super usefull for composing / chaining like this: > > population sortBy: #name ascending , #age descending. > > But currently, SortByPropertyFunction is allways using the default > hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) > > Imagine that my properties are neither String nor Magnitude, or they are, > but I want a different collation policy, because in French $Ã© must not be > sorted too far from $e. > > It could be written quite simply with: > > c sortBy: #name collatedInFrench ascending , #age descending > > With current implementation, collatedInFrench would have to use a block > (thru a CollatorBlockFunction which is a proxy to the block in a > SortFunction disguise): > > Symbol>>collatedInFrench > "interpret self as a property" > ^[:a :b | FrenchCollator collate: (self value: a) with: (self > value: b)] > > But IMO SortByPropertyFunction should better feed a reified > CollatorFunction, or said differently a SortFunction, as Denis said. > > Symbol>>collatedInFrench > ^FrenchCollator new onProperty: self > > SortFunction>>onProperty: aValuable > ^SortByPropertyFunction sortProperty: aValuable with: self > > What do you think? > > Nicolas > >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 13:50 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > 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. >>> >> >> That's why SortFunction is now abstract class. If you want some complex >> logic you are able to create custom function class which will incapsulate >> it and make it reusable. >> > > Then we agree: a good choice is having a proper place (sort function > object, a method in simple cases) to implement that business logic if it is > not obvious. > > >> I already mentioned possible SortMethodFunction. It takes care about >> binary method order which should be always on top of ascending list. It >> would be ugly to implement it in block or with composition of selectors. >> And I don't think that method should define #> >> > > On a short analysis, I could give you half a dozen valid orderings for > SortMethodFunction... You've chosen one, put it as the master one, and gave > it a general name 'Ordering of Methods'. You could have written it as #>, > the way you're doing it. > Sorry Thierry that it is not obvious: given name is an example. Of course it is better to have explicit name. > > Regards, > > Thierry > > >> >> >>> >>> 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 >>> >>> >>>> >>>> >>>> >>> >>> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

2017-11-07 13:47 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> 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). >> > > I think we can easily support it. But of course it will work only for > objects which understand #threeWayCompareTo:. Now it looks like > > #(one nil two) sorted: #yourself ascending undefinedFirst. > > And I prefer this version instead of extending collection with new sorting > messages. > My position is that we have few messages (which are not business logic related) for sorting, so they could easily extend collection (and #yourself here is just noise). Now, you want to keep that mix of business logic + ordering, hence the syntax you're choosing. Thierry

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

2017-11-07 13:37 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> 2017-11-07 12:09 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> 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. >> > > One note: we are not discussing here the possible new language or system > core feature. It should be in separate package with clear intention in the > name (like FunctionalProgramming). So it can provide nice handy message for > their domain. > Hum, I've already seen that sort of package for Squeak. Or at least I know someone who codes like that in Squeak. > >> >>> 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 #>? >> > > It will not help because desired order depends on concrete use case. > Different reports can represent people in completely different order. > And do you think that any object should implement comparison? > No, but that hiding it into a mix of business domain specific messages mixed up with general sorting arguments somewhere at the point of sorting people is bad software design. > > >> >> 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. >> > > That's why SortFunction is now abstract class. If you want some complex > logic you are able to create custom function class which will incapsulate > it and make it reusable. > Then we agree: a good choice is having a proper place (sort function object, a method in simple cases) to implement that business logic if it is not obvious. > I already mentioned possible SortMethodFunction. It takes care about > binary method order which should be always on top of ascending list. It > would be ugly to implement it in block or with composition of selectors. > And I don't think that method should define #> > On a short analysis, I could give you half a dozen valid orderings for SortMethodFunction... You've chosen one, put it as the master one, and gave it a general name 'Ordering of Methods'. You could have written it as #>, the way you're doing it. Regards, Thierry > > >> >> 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 >> >> >>> >>> >>> >> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > 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). > I think we can easily support it. But of course it will work only for objects which understand #threeWayCompareTo:. Now it looks like #(one nil two) sorted: #yourself ascending undefinedFirst. And I prefer this version instead of extending collection with new sorting messages.

Nov. 7, 2017

[Pharo 7.0-dev] Build #264: 20644-Load-Bitmap-DejaVu-fonts-from-data-files-instead-of-a-Fuel-file

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #264 was: SUCCESS. The Pull Request #439 was integrated: "20644-Load-Bitmap-DejaVu-fonts-from-data-files-instead-of-a-Fuel-file" Pull request url: https://github.com/pharo-project/pharo/pull/439 Issue Url: https://pharo.fogbugz.com/f/cases/20644 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 2017-11-07 12:09 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> 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. > One note: we are not discussing here the possible new language or system core feature. It should be in separate package with clear intention in the name (like FunctionalProgramming). So it can provide nice handy message for their domain. > >> 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 #>? > It will not help because desired order depends on concrete use case. Different reports can represent people in completely different order. And do you think that any object should implement comparison? > > 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. > That's why SortFunction is now abstract class. If you want some complex logic you are able to create custom function class which will incapsulate it and make it reusable. I already mentioned possible SortMethodFunction. It takes care about binary method order which should be always on top of ascending list. It would be ugly to implement it in block or with composition of selectors. And I don't think that method should define #> > > 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 > > >> >> >> > >

Nov. 7, 2017

[ANN] Next Pharo Techtalk: Nov 21

by Marcus Denker

Pharo TechTalk: Discord Demo - 21 Nov 2017, 5:00 PM - 7:00 PM (UTC+01:00) - https://association.pharo.org/event-2642665 The December tech talk will be the 19/12. We are still looking for a topic (if not, it will just be an open discussion). List of all events: https://association.pharo.org/events Marcus

Nov. 7, 2017

[Pharo 7.0-dev] Build #263: Care on dirty package OpalTools

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #263 was: FAILURE. The Pull Request #437 was integrated: "Care on dirty package OpalTools" Pull request url: https://github.com/pharo-project/pharo/pull/437 Issue Url: https://pharo.fogbugz.com/f/cases/20642 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

2017-11-07 12:09 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-11-07 11:36 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> >> 2017-11-07 11:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> >>> 2017-11-07 9:23 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >>> l.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 > > >

Nov. 7, 2017