September 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Christopher Fuhrman

Crazy idea inspired by Spanish: Â¿even? On Sat, Sep 14, 2019 at 04:38 ducasse <stepharo(a)netcourrier.com> wrote: > > > On 13 Sep 2019, at 20:52, Tim Mackinnon <tim(a)testit.works> wrote: > > > I agree with Benâs reaction below , however the point that ? ! could be > repurposed for something if they werenât special characters is a good one. > Maybe there are other usages we are missing, and thatâs the point I guess. > > > Exactly. > I think that it would be nice to think a bit. > I like the idea that I do not have to read the code to understand if a > method is a predicate. > > odd? > even? > > Stef > > > Tim > > Sent from my iPhone > > On 13 Sep 2019, at 17:41, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com> wrote: > >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or >> somehow required? If simply convention, then we should start with renaming >> testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" >> > > Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. > > > > flag2 := anInteger isEven. âbetter" >> > > Agreed. It reads well. > > > > flag3 := anInteger even?. âhow much better?â >> > > For me, this doesn't read as well as flag2, but even though there is some > redundancy, for me a combination reads well... > flag3a := anInteger isEven? > Perhaps if "?"==>Boolean was a strong convention then there could be a > check when the value is returned rather than when it is used (or would that > complicate other things?) > > > > flag4 := #(1 2 3) includes?: 2. âhow much better?â >> > > My first impression is "yuck!", but then I think... "maybe" if there was a > definite benefit (i.e. optimization) from strong guarantees about the > return value being Boolean. > > > >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or >> isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >> > > btw, some alternatives... > doBlockBracketsLineUp - reads well but "do" is already a loaded word > areBlockBracketsLinedUp - reads well with the past-tense phrasing > > cheers -ben > > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Sept. 14, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by ducasse

> On 13 Sep 2019, at 20:52, Tim Mackinnon <tim(a)testit.works> wrote: > > > I agree with Benâs reaction below , however the point that ? ! could be repurposed for something if they werenât special characters is a good one. Maybe there are other usages we are missing, and thatâs the point I guess. Exactly. I think that it would be nice to think a bit. I like the idea that I do not have to read the code to understand if a method is a predicate. odd? even? Stef > > Tim > > Sent from my iPhone > > On 13 Sep 2019, at 17:41, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >> >> >> On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net <mailto:Smalltalk@JGFoster.net>> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" >> >> Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. >> >> >> > flag2 := anInteger isEven. âbetter" >> >> Agreed. It reads well. >> >> >> > flag3 := anInteger even?. âhow much better?â >> >> For me, this doesn't read as well as flag2, but even though there is some redundancy, for me a combination reads well... >> flag3a := anInteger isEven? >> Perhaps if "?"==>Boolean was a strong convention then there could be a check when the value is returned rather than when it is used (or would that complicate other things?) >> >> >> > flag4 := #(1 2 3) includes?: 2. âhow much better?â >> >> My first impression is "yuck!", but then I think... "maybe" if there was a definite benefit (i.e. optimization) from strong guarantees about the return value being Boolean. >> >> >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >> >> btw, some alternatives... >> doBlockBracketsLineUp - reads well but "do" is already a loaded word >> areBlockBracketsLinedUp - reads well with the past-tense phrasing >> >> cheers -ben

Sept. 14, 2019

Help on Iceberg

by Hilaire

Hi, I have been experimenting the contributing process for fixes. But I am doing wrongly some steps. If I understand correctly after push a pull request (PR) I should do a checkout of Pharo8. This last process I did not do it. I tried yesterday but 1. Not clear from where in the UI and from which repo 2. I tried one guessed scenario and it was refused. Idea? See: https://github.com/pharo-project/pharo/pull/4580#issuecomment-531322034 Now I should probably start with a fresh P8, but I don't want to loose my previous fixes (I guess should be on my own repo) Hilaire -- Dr. Geo http://drgeo.eu

Sept. 14, 2019

[Pharo 8.0] Build #735: 4537-Integrate-MiniBeacon

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

There is a new Pharo build available! The status of the build #735 was: FAILURE. The Pull Request #4588 was integrated: "4537-Integrate-MiniBeacon" Pull request url: https://github.com/pharo-project/pharo/pull/4588 Issue Url: https://github.com/pharo-project/pharo/issues/4537 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Tim Mackinnon

I agree with Benâs reaction below , however the point that ? ! could be repurposed for something if they werenât special characters is a good one. Maybe there are other usages we are missing, and thatâs the point I guess. Tim Sent from my iPhone > On 13 Sep 2019, at 17:41, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com> wrote: >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" > > Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. > > >> > flag2 := anInteger isEven. âbetter" > > Agreed. It reads well. > > >> > flag3 := anInteger even?. âhow much better?â > > For me, this doesn't read as well as flag2, but even though there is some redundancy, for me a combination reads well... > flag3a := anInteger isEven? > Perhaps if "?"==>Boolean was a strong convention then there could be a check when the value is returned rather than when it is used (or would that complicate other things?) > > >> > flag4 := #(1 2 3) includes?: 2. âhow much better?â > > My first impression is "yuck!", but then I think... "maybe" if there was a definite benefit (i.e. optimization) from strong guarantees about the return value being Boolean. > > >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better. > > btw, some alternatives... > doBlockBracketsLineUp - reads well but "do" is already a loaded word > areBlockBracketsLinedUp - reads well with the past-tense phrasing > > cheers -ben

Sept. 13, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Ben Coman

On Wed, 11 Sep 2019 at 15:10, ducasse <stepharo(a)netcourrier.com> wrote: > > > > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: > > > > Would use of ? and ! in unary/keyword selectors be convention or somehow > required? If simply convention, then we should start with renaming testing > methods to be named is* or has*. > > flag1 := anInteger even. ânot good" > Agreed. That could "almost" be construed as converting a 3 to a 2 or 4. > flag2 := anInteger isEven. âbetter" > Agreed. It reads well. > flag3 := anInteger even?. âhow much better?â > For me, this doesn't read as well as flag2, but even though there is some redundancy, for me a combination reads well... flag3a := anInteger isEven? Perhaps if "?"==>Boolean was a strong convention then there could be a check when the value is returned rather than when it is used (or would that complicate other things?) > flag4 := #(1 2 3) includes?: 2. âhow much better?â > My first impression is "yuck!", but then I think... "maybe" if there was a definite benefit (i.e. optimization) from strong guarantees about the return value being Boolean. > > I think that I would use ? mainly for unary message > > Now Iâm sure that if you look carefully some people use > > include > for the action > includes > for the tests > > I took include as an example and this is super not intention revealing. > > >> lineUpBlockBrackets > > lineUpBlockBrackets? > Now I will rewrite them all as shouldLineUpBlockBrackets or > isLineUpBlockBrackets and to me for unary message ? makes it a lot better. > btw, some alternatives... doBlockBracketsLineUp - reads well but "do" is already a loaded word areBlockBracketsLinedUp - reads well with the past-tense phrasing cheers -ben

Sept. 13, 2019

[Pharo 8.0] Build #734: FIxesIssue4364

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

There is a new Pharo build available! The status of the build #734 was: FAILURE. The Pull Request #4570 was integrated: "FIxesIssue4364" Pull request url: https://github.com/pharo-project/pharo/pull/4570 Issue Url: https://github.com/pharo-project/pharo/issues/FIxesIssue4364 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2019

[Pharo 8.0] Build #733: Update-Spec2-and-Commander-2

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

There is a new Pharo build available! The status of the build #733 was: FAILURE. The Pull Request #4589 was integrated: "Update-Spec2-and-Commander-2" Pull request url: https://github.com/pharo-project/pharo/pull/4589 Issue Url: https://github.com/pharo-project/pharo/issues/Update Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by ducasse

> On 13 Sep 2019, at 14:11, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Some examples of testing methods verb prefixes I use: > > shouldXxx (#shouldOverwrite) > isXxx (#isEmpty #isNil > hasXxx (#hasContents) > canXxx (#canDeleteProperty) > > didXxx (#didRemoveFiles) > willXxx (#willCreateNewAssets) this is for the following ones that I do not like that the only difference between an action and a question is an s > usesXxx (#usesDirectTransfer) > containsXxx (#containsPlots) > definesXxx (#definesGlobals) > > I'm in favor of having more symbols available as binary selectors, but > I don't see the use of ? and ! as unary selectors other than the > technical challenge of making the change, with the added burden of > breaking compatibility. > > In a perfect world no testing is required and everything is solved by > delegation, but we all know that sometimes the added complexity is not > worth it. :) If only For the pretty printer we have around 30 different parameters. I do not imagine my self having 30 classes to which I would delegate something. > > Regards, > > Esteban A. Maringolo > > On Fri, Sep 13, 2019 at 9:00 AM Tim Mackinnon <tim(a)testit.works> wrote: >> >> +1 for #shouldXxx I recall I use it a lot too, and #isXxx where that reads better but am struggling for examples. >> >> Tim >> >> Sent from my iPhone >> >> On 13 Sep 2019, at 02:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> >> On Wed, Sep 11, 2019 at 4:10 AM ducasse <stepharo(a)netcourrier.com> wrote: >>> >>> >>> >>>> On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: >>>> >>>> Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*. >>>> flag1 := anInteger even. ânot good" >>>> flag2 := anInteger isEven. âbetter" >>>> flag3 := anInteger even?. âhow much better?â >>>> flag4 := #(1 2 3) includes?: 2. âhow much better?â >>> >>> I think that I would use ? mainly for unary message >>> >>> Now Iâm sure that if you look carefully some people use >>> >>> include >>> for the action >>> includes >>> for the tests >>> >>> I took include as an example and this is super not intention revealing. >>> >>>>> lineUpBlockBrackets >>> >>> lineUpBlockBrackets? >>> Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >>> >> >> Hi Stef, >> >> I have been facing this ambiguity a lot too. And my workaround, most of the times, was also to prefer the "question" method with #should. #is just doesn't sound right in my cases, but #should does sound good in most of them. I would still like to find a better one, but for the moment, in my recent years, I am stuck with #should. >> >> -- >> Mariano Martinez Peck >> Email: marianopeck(a)gmail.com >> Twitter: @MartinezPeck >> LinkedIn: www.linkedin.com/in/mariano-martinez-peck >> Blog: https://marianopeck.wordpress.com/ >

Sept. 13, 2019

Re: [Pharo-dev] Floating-point numbers with non-decimal radix

by Nicolas Cellier

Very nice argumentation Jim :) Note this: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/022815.ht… Is there any urge to fix that? Given that hardly any source will use float with alternate radix (but maybe some Sunit TestCase), isn't it a more a theoretical than practical problem? Le mar. 10 sept. 2019 Ã 16:03, James Foster <Smalltalk(a)jgfoster.net> a Ã©crit : > Jim, > > Youâve done an excellent job of summarizing the issues and providing > strong arguments. > > For my part, while consistency is important, simplicity is also important. > To that end, a new syntax would need to bring a lot of value to justify the > additional cognitive load. So unless you can get `^` to act as the exponent > prefix, Iâd be skeptical of a new syntax. For me, the idea that an Integer > (and not a Float) can have a radix is sufficient and consistent. > > James > > On Sep 9, 2019, at 3:13 PM, Jim Sawyer <jas(a)cruzio.com> wrote: > > > --- > Regarding the specification of floating point numbers with radix ~= 10, > and in particular the question raised by James Foster(Gemstone). > > Summarizing the comments from James Foster, Nicolas Collier, Prof Stef Ducasse; > followed by some arguments with a lot of hand waving, > in order to agree with and support what Nicolas said at the outset: > this deserves a new syntax. > > --- > > Question: How should it work? > > > The literal 16rFF is 255 (aSmallInteger). > Pharo permits lowercase hexadecimal digits, > so the literal 16rff is also taken to be 255. > > The literal 1.23e3 is 1230.0 (aSmallDouble in GemStone). > Pharo also permits floating point numbers to have a radix, > so that e.g. both 2r1.111e3 and 2r1111 are taken to be 15. > > This makes certain grammars for numbers ambiguous, because > upon encountering either an $E or an $e during the parse > of a number, we find two possible interpretations: > > Is this a hexadecimal digit > or an exponent marker? > > > James identified four possible solutions: > > > 1) Distinguish by letter case > > uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. > > 2) Allow exponents on base ten numbers only > > 3) Distinguish by range > > radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] > > 4) Develop a new syntax for floats that does not use either the letter $e or the letter $E to mark an exponent > > > Many implementations of Smalltalk use solution #1, > whereas Pharo currently uses solution #3. > > > The result is that any number expressed in other dialects > will port to Pharo without issue, while certain expressions for > numbers that are recognized in Pharo become ambiguous > when ported to other dialects. > > The most practical âfixâ is for Pharo to adopt > the more âpopularâ solution. > > > <tl;dr><outcry> > > Even so, I submit that this is not the right thing to do. > But only because it is a hack, on top of a hack, on top of a > design error that went unnoticed for far too long, and really > ought to be corrected, for a number of reasons, viz.: > > 1) The root cause of the problem is an ambiguous grammar. > > 2) This ambiguity is unique to Smalltalk. It does not occur in any other language, as far as I know. > > 3) The source of the ambiguity is the design decision which > introduced a consistent syntax for expressing numbers in > different bases by directly specifying the desired radix, > instead of choosing from the very limited sets of special cases > provided by other languages.. > > One is usually limited to binary, octal, decimal, and hexadecimal, > with a unique syntactic form required for expression in each base. > We get Bâ01â for binary, \001 for octal, #01 or %01 for hex, > and the unadorned 1, left for (the most privileged) decimal form. > > Introducing a consistent form for specifying alternate bases > was itself a great design decision. > > At the same time, however, a change was introduced which impacted > some very long standing properties of numeric representations, and > the effect of that change was perhaps not fully considered. > > As we go about the task of correcting such a latent error, we should > take enough time to more fully consider the particulars that brought us here. > > > 4) Smalltalk is a spectacularly consistent design and a spectacularly consistent > language to work in. Increasing the consistency of such a language is arguably > the right thing to do at every opportunity. This is not always the most popular thing > to doâbut it is usually the most honorable. > And the most useful, in the long term. > Practically speaking. > > > 5) Of the four solutions (or cases), we can arguably eliminate three. > > > 1) Distinguish by letter case uppercase $E is a hexadecimal digit > lowercase $e is a marker signifying an exponent. 2) Allow exponents on base ten numbers only 3) Distinguish by range radix >= 15 > ifTrue: [$e is the hexadecimal digit ] > ifFalse: [$e is a marker signifying exponent] 4) Develop a new syntax for floats that does not use either the letter $e or the letter $E to mark an exponent > In other domains and languages, numerical values are specified with digits only. > In such contexts, using a letter as a syntactic marker is reasonable. > > Once we adopt the specifiable-radix form (radix)r(rigits) > in which numerical values are expressed using digits AND letters, it becomes far less reasonable to use letters as a marker. > > > Case (1) : > > Differentiation based on the case of letters is fine where the use of > letters is pervasive and capitalization is itself generically meaningful, > e.g. certain shorthand notations used in regular expressions > (%h signifying a match of any lowercase hexadecimal, with > %H signifying a match of any uppercase hexadecimal). > > Whereas using capitalization to distinguish âa valueâ from âa syntactic marke' > is a very poor use of character classes, of pixels, and of synaptic gaps, because > the association is made without mnemonic support of any kind. Such ârulesâ > require rote memorization, i.e. perfect match of an arbitrary fact. The hidden > assumption--that any âskillâ involved is both ubiquitous and evenly distributedâ > is, alas, unfounded. > > > Case (2) > > Disallowing exponents for all bases other than 10 is a) inconsistent > b) contrary to the point of consistently specifying the desired radix. > c) lazy > > > Case (3): > > Differentiating meaning based on a particular range of values > makes for a great explanation of the âdiscoveredâ effect, but is somewhat > frightening to consider using *on purpose*. If we were to adopt anything of this ilk, > a better crossover of ranges would be > > radix <= 10 Values are confined to the set of digits (ascii 16r30-16r39) > and $E are exponent markers. See also $s, $d, and $q. > > radix >= 11 Letters are required for use as extended values > as determined by the radix. > We cannot imagine using non-letter characters for this case. > Therefore, no exponents for bases above 10. > > > This leaves us with solution (4), create a new syntax for marking the exponent. > Because the other solutions are hacks. Practicalâsure. But hacks, nonetheless. Abominable. > > > 7) As Nicolas pointed out, this issue deserves a new syntax. > > The moment we adopted the specifiable-radix solution, > we needed to also abandon the use of the letter $e for marking exponents. > > Now is our chance to make it right. > > </tl;dr></outcry> > > Ideas? > > > > -Jim Sawyer > > > > > ------------------------------ > [image: AVG logo] <https://www.avg.com/internet-security> > > This email has been checked for viruses by AVG antivirus software. > www.avg.com <https://www.avg.com/internet-security> > > >

Sept. 13, 2019