2017-11-07 12:09 GMT+01:00 Nicolas Cellier < [email protected]>:
> > > 2017-11-07 11:36 GMT+01:00 Thierry Goubier <[email protected]>: > >> >> >> 2017-11-07 11:24 GMT+01:00 Denis Kudriashov <[email protected]>: >> >>> >>> 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 > > >
