Smalltalk › Squeak › Squeak - Dev

The Inbox: Compiler-ct.418.mcz

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 12 messages Options
commits-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

The Inbox: Compiler-ct.418.mcz

commits-2
Christoph Thiede uploaded a new version of Compiler to project The Inbox:
http://source.squeak.org/inbox/Compiler-ct.418.mcz

==================== Summary ====================

Name: Compiler-ct.418
Author: ct
Time: 16 February 2020, 3:49:08.315 pm
UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
Ancestors: Compiler-eem.416

Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.

=============== Diff against Compiler-eem.416 ===============

Item was changed:
  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
  evaluateCue: aCue ifFail: failBlock
  "Compiles the cue source into a parse tree, then generates code into
  a method. Finally, the compiled method is invoked from here via withArgs:executeMethod:, hence the system no longer creates Doit method
  litter on errors."
 
  | methodNode method value |
  methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
 
  method := self interactive
  ifTrue: [methodNode generateWithTempNames]
  ifFalse: [methodNode generate].
 
  value := cue receiver
  withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
  executeMethod: method.
+ ^ value!
- ^ value
- !

Item was changed:
  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
  asColorizedSmalltalk80Text
  "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
 
  | printText |
  printText := self printString asText.
+ ^ Smalltalk
+ at: #SHTextStylerST80
+ ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
+ ifAbsent: [printText]!
- ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
- ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
- ifNil: [printText]!


Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

Levente Uzonyi
Hi Christoph,

The idea with Environments was to move away from the SystemDictionary API.
It obviously didn't happen, but there's #classNamed: for class lookup by
name. Actually #classNamed: was there with SystemDictionary too, but it
was and still is underused.

Levente

On Sun, 16 Feb 2020, [hidden email] wrote:

> Christoph Thiede uploaded a new version of Compiler to project The Inbox:
> http://source.squeak.org/inbox/Compiler-ct.418.mcz
>
> ==================== Summary ====================
>
> Name: Compiler-ct.418
> Author: ct
> Time: 16 February 2020, 3:49:08.315 pm
> UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
> Ancestors: Compiler-eem.416
>
> Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>
> =============== Diff against Compiler-eem.416 ===============
>
> Item was changed:
>  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>  evaluateCue: aCue ifFail: failBlock
>   "Compiles the cue source into a parse tree, then generates code into
>   a method. Finally, the compiled method is invoked from here via withArgs:executeMethod:, hence the system no longer creates Doit method
>   litter on errors."
>
>   | methodNode method value |
>   methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>
>   method := self interactive
>   ifTrue: [methodNode generateWithTempNames]
>   ifFalse: [methodNode generate].
>
>   value := cue receiver
>   withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>   executeMethod: method.
> + ^ value!
> - ^ value
> - !
>
> Item was changed:
>  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>  asColorizedSmalltalk80Text
>   "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>
>   | printText |
>   printText := self printString asText.
> + ^ Smalltalk
> + at: #SHTextStylerST80
> + ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
> + ifAbsent: [printText]!
> - ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
> - ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
> - ifNil: [printText]!

Christoph Thiede
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

Christoph Thiede

Hi Levente,


actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains (see Collections-ct.873, Collections-ct.872, Collections-ct.875).


If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".

Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
Gesendet: Sonntag, 16. Februar 2020 22:39:13
An: [hidden email]
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz
 
Hi Christoph,

The idea with Environments was to move away from the SystemDictionary API.
It obviously didn't happen, but there's #classNamed: for class lookup by
name. Actually #classNamed: was there with SystemDictionary too, but it
was and still is underused.

Levente

On Sun, 16 Feb 2020, [hidden email] wrote:

> Christoph Thiede uploaded a new version of Compiler to project The Inbox:
> http://source.squeak.org/inbox/Compiler-ct.418.mcz
>
> ==================== Summary ====================
>
> Name: Compiler-ct.418
> Author: ct
> Time: 16 February 2020, 3:49:08.315 pm
> UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
> Ancestors: Compiler-eem.416
>
> Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>
> =============== Diff against Compiler-eem.416 ===============
>
> Item was changed:
>  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>  evaluateCue: aCue ifFail: failBlock
>        "Compiles the cue source into a parse tree, then generates code into
>        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>        litter on errors."
>
>        | methodNode method value |
>        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>
>        method := self interactive
>                                ifTrue: [methodNode generateWithTempNames]
>                                ifFalse: [methodNode generate].
>
>        value := cue receiver
>                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>                                executeMethod: method.
> +      ^ value!
> -      ^ value
> - !
>
> Item was changed:
>  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>  asColorizedSmalltalk80Text
>        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>
>        | printText |
>        printText := self printString asText.
> +      ^ Smalltalk
> +              at: #SHTextStylerST80
> +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
> +              ifAbsent: [printText]!
> -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
> -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
> -              ifNil: [printText]!

Carpe Squeak!
Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

Levente Uzonyi
Hi Christoph,

On Sun, 16 Feb 2020, Thiede, Christoph wrote:

>
> Hi Levente,
>
>
> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains
> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).
>
>
> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".

In my opinion, #classNamed: is fine as-is, because when the class is
available, the method will return it, when it's not, you'll get nil. No
other return values are possible.
It also supports metaclass lookup, which is not available via #at:*.

Levente


>
> Best,
> Christoph
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
> Gesendet: Sonntag, 16. Februar 2020 22:39:13
> An: [hidden email]
> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz  
> Hi Christoph,
>
> The idea with Environments was to move away from the SystemDictionary API.
> It obviously didn't happen, but there's #classNamed: for class lookup by
> name. Actually #classNamed: was there with SystemDictionary too, but it
> was and still is underused.
>
> Levente
>
> On Sun, 16 Feb 2020, [hidden email] wrote:
>
> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:
> > http://source.squeak.org/inbox/Compiler-ct.418.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Compiler-ct.418
> > Author: ct
> > Time: 16 February 2020, 3:49:08.315 pm
> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
> > Ancestors: Compiler-eem.416
> >
> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
> >
> > =============== Diff against Compiler-eem.416 ===============
> >
> > Item was changed:
> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
> >  evaluateCue: aCue ifFail: failBlock
> >        "Compiles the cue source into a parse tree, then generates code into
> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
> >        litter on errors."
> >
> >        | methodNode method value |
> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
> >
> >        method := self interactive
> >                                ifTrue: [methodNode generateWithTempNames]
> >                                ifFalse: [methodNode generate].
> >
> >        value := cue receiver
> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
> >                                executeMethod: method.
> > +      ^ value!
> > -      ^ value
> > - !
> >
> > Item was changed:
> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
> >  asColorizedSmalltalk80Text
> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
> >
> >        | printText |
> >        printText := self printString asText.
> > +      ^ Smalltalk
> > +              at: #SHTextStylerST80
> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
> > +              ifAbsent: [printText]!
> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
> > -              ifNil: [printText]!
>
>
>
marcel.taeumel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

marcel.taeumel
In reply to this post by Christoph Thiede
Hi Christoph.

> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths

The terms "at" or "at if present" are quite generic while "class named" reads domain specific. So, #classNamed: can improve code readability. And once you are in that domain, as Levente mentioned, you can then support things such as metaclass lookup using the same interface. :-) That would be awkward (or at least unexpected and surprising) through #at:ifPresent: ...

> If you think it is important to distinguish between classes and globals

Classes are a special kind of global variable. Yes, this domain knowledge should be represented in the interface.

>  maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise"

I don't think that we need that change. Programmers can write quite readable code using #hasClassNamed: and #classNamed:.

Best,
Marcel


Am 17.02.2020 00:17:02 schrieb Thiede, Christoph <[hidden email]>:

Hi Levente,


actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains (see Collections-ct.873, Collections-ct.872, Collections-ct.875).


If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".

Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
Gesendet: Sonntag, 16. Februar 2020 22:39:13
An: [hidden email]
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz
 
Hi Christoph,

The idea with Environments was to move away from the SystemDictionary API.
It obviously didn't happen, but there's #classNamed: for class lookup by
name. Actually #classNamed: was there with SystemDictionary too, but it
was and still is underused.

Levente

On Sun, 16 Feb 2020, [hidden email] wrote:

> Christoph Thiede uploaded a new version of Compiler to project The Inbox:
> http://source.squeak.org/inbox/Compiler-ct.418.mcz
>
> ==================== Summary ====================
>
> Name: Compiler-ct.418
> Author: ct
> Time: 16 February 2020, 3:49:08.315 pm
> UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
> Ancestors: Compiler-eem.416
>
> Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>
> =============== Diff against Compiler-eem.416 ===============
>
> Item was changed:
>  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>  evaluateCue: aCue ifFail: failBlock
>        "Compiles the cue source into a parse tree, then generates code into
>        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>        litter on errors."
>
>        | methodNode method value |
>        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>
>        method := self interactive
>                                ifTrue: [methodNode generateWithTempNames]
>                                ifFalse: [methodNode generate].
>
>        value := cue receiver
>                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>                                executeMethod: method.
> +      ^ value!
> -      ^ value
> - !
>
> Item was changed:
>  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>  asColorizedSmalltalk80Text
>        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>
>        | printText |
>        printText := self printString asText.
> +      ^ Smalltalk
> +              at: #SHTextStylerST80
> +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
> +              ifAbsent: [printText]!
> -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
> -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
> -              ifNil: [printText]!


Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

Eliot Miranda-2
In reply to this post by commits-2
BTW...

> On Feb 16, 2020, at 6:49 AM, [hidden email] wrote:
>
> Christoph Thiede uploaded a new version of Compiler to project The Inbox:
> http://source.squeak.org/inbox/Compiler-ct.418.mcz
>
> ==================== Summary ====================
>
> Name: Compiler-ct.418
> Author: ct
> Time: 16 February 2020, 3:49:08.315 pm
> UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
> Ancestors: Compiler-eem.416
>
> Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>
> =============== Diff against Compiler-eem.416 ===============
>
> Item was changed:
>  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>  evaluateCue: aCue ifFail: failBlock
>      "Compiles the cue source into a parse tree, then generates code into
>      a method. Finally, the compiled method is invoked from here via    withArgs:executeMethod:, hence the system no longer creates Doit method
>      litter on errors."
>
>      | methodNode method value |
>      methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>
>      method := self interactive
>                  ifTrue: [methodNode generateWithTempNames]
>                  ifFalse: [methodNode generate].
>
>      value := cue receiver
>                  withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>                  executeMethod: method.
> +    ^ value!
> -    ^ value
> - !

<3  these drive me nutz :-)

IMO the UIs around compilation should strip trailing white space

> Item was changed:
>  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>  asColorizedSmalltalk80Text
>      "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>
>      | printText |
>      printText := self printString asText.
> +    ^ Smalltalk
> +        at: #SHTextStylerST80
> +        ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
> +        ifAbsent: [printText]!
> -    ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
> -        ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
> -        ifNil: [printText]!
>
>

Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: The Inbox: Compiler-ct.418.mcz

Eliot Miranda-2
In reply to this post by Levente Uzonyi


> On Feb 16, 2020, at 3:31 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Christoph,
>
>> On Sun, 16 Feb 2020, Thiede, Christoph wrote:
>>
>> Hi Levente,
>> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains
>> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).
>> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".
>
> In my opinion, #classNamed: is fine as-is, because when the class is available, the method will return it, when it's not, you'll get nil. No other return values are possible.
> It also supports metaclass lookup, which is not available via #at:*.

+1

>
> Levente
>
>
>> Best,
>> Christoph
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
>> Gesendet: Sonntag, 16. Februar 2020 22:39:13
>> An: [hidden email]
>> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz  
>> Hi Christoph,
>> The idea with Environments was to move away from the SystemDictionary API.
>> It obviously didn't happen, but there's #classNamed: for class lookup by
>> name. Actually #classNamed: was there with SystemDictionary too, but it
>> was and still is underused.
>> Levente
>> On Sun, 16 Feb 2020, [hidden email] wrote:
>> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:
>> > http://source.squeak.org/inbox/Compiler-ct.418.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Compiler-ct.418
>> > Author: ct
>> > Time: 16 February 2020, 3:49:08.315 pm
>> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
>> > Ancestors: Compiler-eem.416
>> >
>> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>> >
>> > =============== Diff against Compiler-eem.416 ===============
>> >
>> > Item was changed:
>> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>> >  evaluateCue: aCue ifFail: failBlock
>> >        "Compiles the cue source into a parse tree, then generates code into
>> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>> >        litter on errors."
>> >
>> >        | methodNode method value |
>> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>> >
>> >        method := self interactive
>> >                                ifTrue: [methodNode generateWithTempNames]
>> >                                ifFalse: [methodNode generate].
>> >
>> >        value := cue receiver
>> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>> >                                executeMethod: method.
>> > +      ^ value!
>> > -      ^ value
>> > - !
>> >
>> > Item was changed:
>> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>> >  asColorizedSmalltalk80Text
>> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>> >
>> >        | printText |
>> >        printText := self printString asText.
>> > +      ^ Smalltalk
>> > +              at: #SHTextStylerST80
>> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
>> > +              ifAbsent: [printText]!
>> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
>> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
>> > -              ifNil: [printText]!
>

Christoph Thiede
Reply | Threaded
Open this post in threaded view
♦
♦
|

Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)

Christoph Thiede

> > +    ^ value!
> > -    ^ value
> > - !
> 
> <3  these drive me nutz :-)
> 
> IMO the UIs around compilation should strip trailing white space

+1, we seem to do the same with leading whitespaces already.

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 19. Februar 2020 11:58 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz
 


> On Feb 16, 2020, at 3:31 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Christoph,
>
>> On Sun, 16 Feb 2020, Thiede, Christoph wrote:
>>
>> Hi Levente,
>> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains
>> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).
>> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".
>
> In my opinion, #classNamed: is fine as-is, because when the class is available, the method will return it, when it's not, you'll get nil. No other return values are possible.
> It also supports metaclass lookup, which is not available via #at:*.

+1

>
> Levente
>
>
>> Best,
>> Christoph
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
>> Gesendet: Sonntag, 16. Februar 2020 22:39:13
>> An: [hidden email]
>> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz 
>> Hi Christoph,
>> The idea with Environments was to move away from the SystemDictionary API.
>> It obviously didn't happen, but there's #classNamed: for class lookup by
>> name. Actually #classNamed: was there with SystemDictionary too, but it
>> was and still is underused.
>> Levente
>> On Sun, 16 Feb 2020, [hidden email] wrote:
>> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:
>> > http://source.squeak.org/inbox/Compiler-ct.418.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Compiler-ct.418
>> > Author: ct
>> > Time: 16 February 2020, 3:49:08.315 pm
>> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
>> > Ancestors: Compiler-eem.416
>> >
>> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>> >
>> > =============== Diff against Compiler-eem.416 ===============
>> >
>> > Item was changed:
>> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>> >  evaluateCue: aCue ifFail: failBlock
>> >        "Compiles the cue source into a parse tree, then generates code into
>> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>> >        litter on errors."
>> >
>> >        | methodNode method value |
>> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>> >
>> >        method := self interactive
>> >                                ifTrue: [methodNode generateWithTempNames]
>> >                                ifFalse: [methodNode generate].
>> >
>> >        value := cue receiver
>> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>> >                                executeMethod: method.
>> > +      ^ value!
>> > -      ^ value
>> > - !
>> >
>> > Item was changed:
>> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>> >  asColorizedSmalltalk80Text
>> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>> >
>> >        | printText |
>> >        printText := self printString asText.
>> > +      ^ Smalltalk
>> > +              at: #SHTextStylerST80
>> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
>> > +              ifAbsent: [printText]!
>> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
>> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
>> > -              ifNil: [printText]!
>



Carpe Squeak!
Chris Muller-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)

Chris Muller-3
-1.  You mean you're not using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... 

Formatting and saving should remain two separate gestures, commingling them would be surprising and frustrating, IMO...


On Wed, Feb 19, 2020 at 5:25 AM Thiede, Christoph <[hidden email]> wrote:

> > +    ^ value!
> > -    ^ value
> > - !
> 
> <3  these drive me nutz :-)
> 
> IMO the UIs around compilation should strip trailing white space

+1, we seem to do the same with leading whitespaces already.

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 19. Februar 2020 11:58 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz
 


> On Feb 16, 2020, at 3:31 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Christoph,
>
>> On Sun, 16 Feb 2020, Thiede, Christoph wrote:
>>
>> Hi Levente,
>> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains
>> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).
>> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".
>
> In my opinion, #classNamed: is fine as-is, because when the class is available, the method will return it, when it's not, you'll get nil. No other return values are possible.
> It also supports metaclass lookup, which is not available via #at:*.

+1

>
> Levente
>
>
>> Best,
>> Christoph
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
>> Gesendet: Sonntag, 16. Februar 2020 22:39:13
>> An: [hidden email]
>> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz 
>> Hi Christoph,
>> The idea with Environments was to move away from the SystemDictionary API.
>> It obviously didn't happen, but there's #classNamed: for class lookup by
>> name. Actually #classNamed: was there with SystemDictionary too, but it
>> was and still is underused.
>> Levente
>> On Sun, 16 Feb 2020, [hidden email] wrote:
>> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:
>> > http://source.squeak.org/inbox/Compiler-ct.418.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Compiler-ct.418
>> > Author: ct
>> > Time: 16 February 2020, 3:49:08.315 pm
>> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
>> > Ancestors: Compiler-eem.416
>> >
>> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>> >
>> > =============== Diff against Compiler-eem.416 ===============
>> >
>> > Item was changed:
>> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>> >  evaluateCue: aCue ifFail: failBlock
>> >        "Compiles the cue source into a parse tree, then generates code into
>> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>> >        litter on errors."
>> >
>> >        | methodNode method value |
>> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>> >
>> >        method := self interactive
>> >                                ifTrue: [methodNode generateWithTempNames]
>> >                                ifFalse: [methodNode generate].
>> >
>> >        value := cue receiver
>> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>> >                                executeMethod: method.
>> > +      ^ value!
>> > -      ^ value
>> > - !
>> >
>> > Item was changed:
>> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>> >  asColorizedSmalltalk80Text
>> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>> >
>> >        | printText |
>> >        printText := self printString asText.
>> > +      ^ Smalltalk
>> > +              at: #SHTextStylerST80
>> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
>> > +              ifAbsent: [printText]!
>> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
>> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
>> > -              ifNil: [printText]!
>




Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)

Eliot Miranda-2


On Wed, Feb 19, 2020 at 11:10 AM Chris Muller <[hidden email]> wrote:
-1.  You mean you're not using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... 

I've yet to find a pretty printer I can live with.  They all fuck up my code.  No pretty printer deals with comments split across lines properly.  There are too many edge cases.  Comments need to be formatted (see Behavior>>instSpec for an example).  Pretty printers appear to be god solutions in theory, but in practice they're half-assed.  Code highlighting, on the other hand, rocks. (Christoph, I can't wait to use requestCode:, very cool idea).


Formatting and saving should remain two separate gestures, commingling them would be surprising and frustrating, IMO...

I'm not suggesting commingling them.  All i'm suggesting is stripping trailing white-space on passing code to compile:classified: et al (and *not* in compile:classified:). 



On Wed, Feb 19, 2020 at 5:25 AM Thiede, Christoph <[hidden email]> wrote:

> > +    ^ value!
> > -    ^ value
> > - !
> 
> <3  these drive me nutz :-)
> 
> IMO the UIs around compilation should strip trailing white space

+1, we seem to do the same with leading whitespaces already.

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 19. Februar 2020 11:58 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz
 


> On Feb 16, 2020, at 3:31 PM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Christoph,
>
>> On Sun, 16 Feb 2020, Thiede, Christoph wrote:
>>
>> Hi Levente,
>> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains
>> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).
>> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".
>
> In my opinion, #classNamed: is fine as-is, because when the class is available, the method will return it, when it's not, you'll get nil. No other return values are possible.
> It also supports metaclass lookup, which is not available via #at:*.

+1

>
> Levente
>
>
>> Best,
>> Christoph
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
>> Gesendet: Sonntag, 16. Februar 2020 22:39:13
>> An: [hidden email]
>> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz 
>> Hi Christoph,
>> The idea with Environments was to move away from the SystemDictionary API.
>> It obviously didn't happen, but there's #classNamed: for class lookup by
>> name. Actually #classNamed: was there with SystemDictionary too, but it
>> was and still is underused.
>> Levente
>> On Sun, 16 Feb 2020, [hidden email] wrote:
>> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:
>> > http://source.squeak.org/inbox/Compiler-ct.418.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Compiler-ct.418
>> > Author: ct
>> > Time: 16 February 2020, 3:49:08.315 pm
>> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0
>> > Ancestors: Compiler-eem.416
>> >
>> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.
>> >
>> > =============== Diff against Compiler-eem.416 ===============
>> >
>> > Item was changed:
>> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----
>> >  evaluateCue: aCue ifFail: failBlock
>> >        "Compiles the cue source into a parse tree, then generates code into
>> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method
>> >        litter on errors."
>> >
>> >        | methodNode method value |
>> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].
>> >
>> >        method := self interactive
>> >                                ifTrue: [methodNode generateWithTempNames]
>> >                                ifFalse: [methodNode generate].
>> >
>> >        value := cue receiver
>> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])
>> >                                executeMethod: method.
>> > +      ^ value!
>> > -      ^ value
>> > - !
>> >
>> > Item was changed:
>> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----
>> >  asColorizedSmalltalk80Text
>> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."
>> >
>> >        | printText |
>> >        printText := self printString asText.
>> > +      ^ Smalltalk
>> > +              at: #SHTextStylerST80
>> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]
>> > +              ifAbsent: [printText]!
>> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])
>> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]
>> > -              ifNil: [printText]!
>





--
_,,,^..^,,,_
best, Eliot
Chris Muller-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)

Chris Muller-4
Eliot,

On Wed, Feb 19, 2020 at 1:53 PM Eliot Miranda <[hidden email]> wrote:


On Wed, Feb 19, 2020 at 11:10 AM Chris Muller <[hidden email]> wrote:
-1.  You mean you're not using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... 

I've yet to find a pretty printer I can live with.  They all fuck up my code. 

Since I know you like Rectangular Block, I thought you'd like mine which I keep in the inbox.  It's not perfect, but very good, IMO, have you tried it?
 
No pretty printer deals with comments split across lines properly. 

Mine does exactly the right thing which is to **not touch their contents**.
 
There are too many edge cases.  Comments need to be formatted (see Behavior>>instSpec for an example).  Pretty printers appear to be god solutions in theory, but in practice they're half-assed. 

Some strong words...
 
Code highlighting, on the other hand, rocks. (Christoph, I can't wait to use requestCode:, very cool idea).

Is that the same as syntax highlighting?
 


Formatting and saving should remain two separate gestures, commingling them would be surprising and frustrating, IMO...

I'm not suggesting commingling them.  All i'm suggesting is stripping trailing white-space on passing code to compile:classified: et al (and *not* in compile:classified:). 

I don't put blank lines at the end, but I want to be able to, if I want to.  Formatting should remain a separate gesture from saving.  Please don't silently save my code differently than what I thought I saved.

Please simply change your pretty-printer to do NOTHING else than that.  Then it won't be "half-assed" anynmore, yes?   :)
_______
Re: multiline comments, I strongly prefer multiline comments to be a single uniform paragraph and not a series of 'formatted' lines.  If you don't care for your comments to wrap fully back to the left margin, how about we handle it by the rendering of CodeHolder, and not making your comments difficult to write, edit, and certainly harder to read when whatever margin you chose is too wide for the viewer (causing half-line wraps every other line), or rather narrow which forces them to scroll further vertically unnecessarily.  Inserting a bunch of successive spaces and/or tabs just to make paragraphs really complexifies comments.

 - Chris
Christoph Thiede
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)

Christoph Thiede

Hi all,


> using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... 


How can I reproduce this?

> I've yet to find a pretty printer I can live with.  They all fuck up my code. 

Without ever having worked a long time with any pretty printer, I venture to claim that there cannot be a perfect pretty printer, at least not for Smalltalk: IMHO, the right way to indent a method, to decide how long a line should be, depends on many circumstances. How long are the lines in the rest of the class or module? If I write a method for etoys, I will probably put a short #ifTrue:ifFalse: statement into one line, because it fits the overall code appearance of etoys. However, if I write a similar method for Metacello, which consists of many wonderful short methods, I will likely spread the same statement over three, if not five lines. It depends on the context. Plus, I would rather compress secondary edge cases a bit more than the primary core logic. A pretty printer cannot know these things without a semantical analysis, I suppose.

> I don't put blank lines at the end, but I want to be able to, if I want to.  Formatting should remain a separate gesture from saving.  Please don't silently save my code differently than what I thought I saved.

+1. Another argument for not forcing to change the code by compiler is that otherwise, it would be tricky to restore older versions of a method which then needs to be recompiled?

> Re: multiline comments, I strongly prefer multiline comments to be a single uniform paragraph and not a series of 'formatted' lines.  If you don't care for your comments to wrap fully back to the left margin, how about we handle it by the rendering of CodeHolder, and not making your comments difficult to write, edit, and certainly harder to read when whatever margin you chose is too wide for the viewer (causing half-line wraps every other line), or rather narrow which forces them to scroll further vertically unnecessarily.  Inserting a bunch of successive spaces and/or tabs just to make paragraphs really complexifies comments.

+1000! ;-) It is really inaesthetic to read a method displayed like this:

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Donnerstag, 20. Februar 2020 01:00:06
An: Eliot Miranda
Cc: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Compiling whitespaces (was: The Inbox: Compiler-ct.418.mcz)
 
Eliot,

On Wed, Feb 19, 2020 at 1:53 PM Eliot Miranda <[hidden email]> wrote:


On Wed, Feb 19, 2020 at 11:10 AM Chris Muller <[hidden email]> wrote:
-1.  You mean you're not using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... 

I've yet to find a pretty printer I can live with.  They all fuck up my code. 

Since I know you like Rectangular Block, I thought you'd like mine which I keep in the inbox.  It's not perfect, but very good, IMO, have you tried it?
 
No pretty printer deals with comments split across lines properly. 

Mine does exactly the right thing which is to **not touch their contents**.
 
There are too many edge cases.  Comments need to be formatted (see Behavior>>instSpec for an example).  Pretty printers appear to be god solutions in theory, but in practice they're half-assed. 

Some strong words...
 
Code highlighting, on the other hand, rocks. (Christoph, I can't wait to use requestCode:, very cool idea).

Is that the same as syntax highlighting?
 


Formatting and saving should remain two separate gestures, commingling them would be surprising and frustrating, IMO...

I'm not suggesting commingling them.  All i'm suggesting is stripping trailing white-space on passing code to compile:classified: et al (and *not* in compile:classified:). 

I don't put blank lines at the end, but I want to be able to, if I want to.  Formatting should remain a separate gesture from saving.  Please don't silently save my code differently than what I thought I saved.

Please simply change your pretty-printer to do NOTHING else than that.  Then it won't be "half-assed" anynmore, yes?   :)
_______
Re: multiline comments, I strongly prefer multiline comments to be a single uniform paragraph and not a series of 'formatted' lines.  If you don't care for your comments to wrap fully back to the left margin, how about we handle it by the rendering of CodeHolder, and not making your comments difficult to write, edit, and certainly harder to read when whatever margin you chose is too wide for the viewer (causing half-line wraps every other line), or rather narrow which forces them to scroll further vertically unnecessarily.  Inserting a bunch of successive spaces and/or tabs just to make paragraphs really complexifies comments.

 - Chris


Carpe Squeak!
Free forum by Nabble Edit this page