- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

2017-11-07 11:55 GMT+01:00 Denis Kudriashov <dionisiydk(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. >> > > That's why I said it is not related to SortFunction. > Generally we rarely use symbol for #collect:/#select: in production. But > it is supper handy for scripting/debugging/inspecting. I use it all the > time. > Hum, among users of # symbol instead of blocks, they do leave it in production. Or they have a different concept of "production" than I do. > Also performance in that case can be covered by Sista. > Sure. > Another problem: it complicates debugging because it is not easy to step > into selector in that case. With block we just press "Through" button and > we are done. But I am sure we can improve it too. Our debugger is in our > hands. > Yes, this is a concern. > > Another advantage of symbol based functions: there is not potential memory > leak here. In case of block we always have reference to outer context. So > it is dangerous to use blocks in caches for example. > Clean blocks are easy to check for. Thierry > > >> Regards, >> >> Thierry >> > >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

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. 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... 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

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 9:23 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)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... > > If we defined <=> in Boolean (orWhatEverTheLongSelectorYouPr > eferBecausePharoHasTheFreedomToHaveOwnTaste:) > in order to have true sorted first, then we can generalize. > > "sort by absolute value, but put the negative first" > numbers sorted: #negative sortedFirst, #abs > > sortedFirst in this case would be a synonym for ascending (or > asSortFunction). > Alternatively, if we don't want <=> in Boolean because it's not natural > (the fact that we need a synonym is a clue) > then we can have sortedFirst answering a specialized BooleanSortFunction. > I like this idea. And I think it is better to add threeWayCompare: to Boolean because it allows to avoid extra selector: #negative ascending, #abs #isNil descending, #name >From the other side it will force remembering convention for boolean order. So maybe it should be explicit: #negative trueFirst, #abs #isNil trueLast, #name

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

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. > That's why I said it is not related to SortFunction. Generally we rarely use symbol for #collect:/#select: in production. But it is supper handy for scripting/debugging/inspecting. I use it all the time. Also performance in that case can be covered by Sista. Another problem: it complicates debugging because it is not easy to step into selector in that case. With block we just press "Through" button and we are done. But I am sure we can improve it too. Our debugger is in our hands. Another advantage of symbol based functions: there is not potential memory leak here. In case of block we always have reference to outer context. So it is dangerous to use blocks in caches for example. > Regards, > > Thierry >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-07 11:37 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 07.11.2017 um 11:24 schrieb 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/. > > And it is really valuable for databases. The query tree can be transformed > into the query language of another system like a database. > > Norbert > > I was thinking of the same chevron selector or maybe a pipe |, but I find that >> better indicates that result is directed to next block/function/processing unit. Of course it sounds much like a DSL.

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Norbert Hartl

> Am 07.11.2017 um 11:24 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-11-07 9:23 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto: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/ <http://blog.3plus4.org/2007/03/>. > And it is really valuable for databases. The query tree can be transformed into the query language of another system like a database. Norbert

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

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

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

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/.

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-07 10:30 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > On Mon, Nov 6, 2017 at 9:52 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > Travis has just seeded the very simple and light library with chaining: >> > >> > points sorted: #x ascending , #y descending. >> > >> > Denis then added possibility to sort properties even if undefined, a >> common >> > case: >> > >> > people sorted: #name ascending undefinedFirst , #age descending >> > >> > And he started to use subclasses with the intention to enrich the >> library I >> > presume. >> > But current implementation does not use composition. >> > It adds an instance variable undefinedDirection to PropertySortFunction >> and >> > specific behavior. >> > > Just little note. I not introduced anything new. In original Pharo version > all this states were part of single SortFunction. And for example direction > and undefinedDirection were used only in the mode with one arg block or > selector. > So I just split it by subclasses for existing uses cases. > Exactly, the inst var were from original author Travis Griggs. The fact that you split the classes put us on the way to rethink the whole library, The addition of undefinedDirection is just what lighted my own bulb on. I absolutely don't want to denigrate this work, on the contrary. Thanks for initiating the refactoring

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

> > On Mon, Nov 6, 2017 at 9:52 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Travis has just seeded the very simple and light library with chaining: > > > > points sorted: #x ascending , #y descending. > > > > Denis then added possibility to sort properties even if undefined, a > common > > case: > > > > people sorted: #name ascending undefinedFirst , #age descending > > > > And he started to use subclasses with the intention to enrich the > library I > > presume. > > But current implementation does not use composition. > > It adds an instance variable undefinedDirection to PropertySortFunction > and > > specific behavior. > Just little note. I not introduced anything new. In original Pharo version all this states were part of single SortFunction. And for example direction and undefinedDirection were used only in the mode with one arg block or selector. So I just split it by subclasses for existing uses cases.

Nov. 7, 2017