Smalltalk › Pharo › Pharo Smalltalk Developers

Transform sends to ANSI standard?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

hernanmd

Transform sends to ANSI standard?

Hi folks,
I am rewriting packages to be compatible or more portable between
Smalltalks. Code Critics gives the following information on my packages:

- #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the
ANSI string protocol.

- #cr and #lf are not part of the ANSI stream protocol.

- The ANSI standard does not support #asInteger and #asString on Object.

- Some collection methods are not ANSI compatible: #pairsDo:,
#collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
#keysSortedSafely, #new:withAll:, etc.

Does anyone have an idea on how to transform those sends to be ANSI
compatible?

Best regards,

Hernán

Benoit St-Jean-4

Re: Transform sends to ANSI standard?

On 25/09/2012 2:31 PM, Hernán Morales Durand wrote:

>
> Hi folks,
> I am rewriting packages to be compatible or more portable between
> Smalltalks. Code Critics gives the following information on my packages:
>
> - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the
> ANSI string protocol.
>
> - #cr and #lf are not part of the ANSI stream protocol.
>
> - The ANSI standard does not support #asInteger and #asString on Object.
>
> - Some collection methods are not ANSI compatible: #pairsDo:,
> #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
> #keysSortedSafely, #new:withAll:, etc.
>
> Does anyone have an idea on how to transform those sends to be ANSI
> compatible?

Hi Hernan,

I don't think being ANSI-compatible should be a goal in any case. You
won't find any Smalltalk flavor (commercial or Open Source) that is
fully ANSI-compatible. All vendors have their
extensions/exceptions/versions. Just have a look at Glorp to convince
yourself of differences between Smalltalk implementations!

But if your goal is portability, I'd say you should start by having your
code compatible with VAST, VW, Dolphin & Squeak. You'll probably cover
most of other Smalltalks variants by doing so. The ANSI standard was
never, to my knowledge, 100% fully respected by any Smalltalk vendor.
Most of them tried to but none of them implemented it with 100%
compliance. In other words, just do your best at satisfying
compatibility with the most vendors.

This one uses Xtreams, the other one Nautilus browser or Zinc, the other
one starts Array indices at 1, this other one does this, the other one
does that, one uses Smalltalk while the other uses SmalltalkImage, etc.

Unfortunately, we're not in the Java world. You'll eventually need a
Bundle/Application/Project/Package named "Portability" just like
everyone else...

Igor Stasenko

Re: Transform sends to ANSI standard?

.. and you can always create own extension methods
#cr -> #carriageReturn
etc

but as Benoit said, even if you do it, this won't make your code
automagically portable across all smalltalk dialects.
You will still need portability package per each dialect, otherwise
you'll have to implement own streams, collections etc.

--
Best regards,
Igor Stasenko.

Levente Uzonyi-2

Re: Transform sends to ANSI standard?

In reply to this post by hernanmd

On Tue, 25 Sep 2012, Hernán Morales Durand wrote:

>
> Hi folks,
> I am rewriting packages to be compatible or more portable between Smalltalks.
> Code Critics gives the following information on my packages:
>
> - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the ANSI
> string protocol.
>
> - #cr and #lf are not part of the ANSI stream protocol.
>
> - The ANSI standard does not support #asInteger and #asString on Object.
>
> - Some collection methods are not ANSI compatible: #pairsDo:,
> #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
> #keysSortedSafely, #new:withAll:, etc.
>
> Does anyone have an idea on how to transform those sends to be ANSI
> compatible?

Is there an ANSI compatible Smalltalk implementation out there? I doubt
it. If I were you, then I'd use a compatibility layer like Sport or
Grease, instead of relying on the ANSI standard.

But to answer your question: you should check how these methods are
implemented and check if the implementation is ANSI compatible or not. In
most cases they are:

string cr ==> Character cr asString

#lf same as above

stream cr ==> stream nextPut: Character cr

#lf, #space, #tab similar to #cr

stream crlf ==> stream nextPut: Character cr; nextPut: Character lf

#findTokens: ==> no ANSI compatible method. If the argument is a single
character, then you can create a stream on the collection and use #upTo:
to find the parts.

collection collect: aBlock thenDo: anotherBlock ==> (collection collect: aBlock) do: anotherBlock

collection detectSum: aBlock ==> collection inject: 0 into: [ :sum :each | sum + (aBlock value: each) ]

#valuesDo: ==> use #do: or #keysAndValuesDo: instead

#keysSortedSafely ==> sorting is not part of the ANSI standard, only
SortedCollection is, so you can use something like: collection keys
asSortedCollection: [ :a :b | <copy the contents of the sort block here from #keysSortedSafely> ]

Array new: x withAll: y ==> (Array new: x) atAllPut: y

Levente

P.S.: My problem with the ANSI standard is that it seems more like
something that documents the common things in Smalltalks at the time of
its creation instead of a complete and future-proof base API.

>
> Best regards,
>
> Hernán
>
>
>

Hannes Hirzel

Re: [squeak-dev] Re: Transform sends to ANSI standard?

On 9/26/12, Levente Uzonyi <[hidden email]> wrote:

> On Tue, 25 Sep 2012, Hernán Morales Durand wrote:
>
>>
>> Hi folks,
>> I am rewriting packages to be compatible or more portable between
>> Smalltalks.
>> Code Critics gives the following information on my packages:
>>
>> - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the
>> ANSI
>> string protocol.
>>
>> - #cr and #lf are not part of the ANSI stream protocol.
>>
>> - The ANSI standard does not support #asInteger and #asString on Object.
>>
>> - Some collection methods are not ANSI compatible: #pairsDo:,
>> #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
>> #keysSortedSafely, #new:withAll:, etc.
>>
>> Does anyone have an idea on how to transform those sends to be ANSI
>> compatible?
>
> Is there an ANSI compatible Smalltalk implementation out there? I doubt
> it. If I were you, then I'd use a compatibility layer like Sport or
> Grease, instead of relying on the ANSI standard.
>
> But to answer your question: you should check how these methods are
> implemented and check if the implementation is ANSI compatible or not. In
> most cases they are:
>
> string cr ==> Character cr asString
>
> #lf same as above
>
> stream cr ==> stream nextPut: Character cr
>
> #lf, #space, #tab similar to #cr
>
> stream crlf ==> stream nextPut: Character cr; nextPut: Character lf
>
> #findTokens: ==> no ANSI compatible method. If the argument is a single
> character, then you can create a stream on the collection and use #upTo:
> to find the parts.
>
> collection collect: aBlock thenDo: anotherBlock ==> (collection collect:
> aBlock) do: anotherBlock
>
> collection detectSum: aBlock ==> collection inject: 0 into: [ :sum :each |
> sum + (aBlock value: each) ]
>
> #valuesDo: ==> use #do: or #keysAndValuesDo: instead
>
> #keysSortedSafely ==> sorting is not part of the ANSI standard, only
> SortedCollection is, so you can use something like: collection keys
> asSortedCollection: [ :a :b | <copy the contents of the sort block here from
> #keysSortedSafely> ]
>
> Array new: x withAll: y ==> (Array new: x) atAllPut: y
>
>
> Levente
>
> P.S.: My problem with the ANSI standard is that it seems more like
> something that documents the common things in Smalltalks at the time of
> its creation instead of a complete and future-proof base API.

+1, in the 90ties.

The ANSI standard is not maintained.
http://www.smalltalk.org/versions/ANSIStandardSmalltalk.html

--Hannes

>
>>
>> Best regards,
>>
>> Hernán
>>
>>
>>

hernanmd

Re: Transform sends to ANSI standard?

In reply to this post by Benoit St-Jean-4

On 25/09/2012 19:35, Benoit St-Jean wrote:

> On 25/09/2012 2:31 PM, Hernán Morales Durand wrote:
>>
>> Hi folks,
>> I am rewriting packages to be compatible or more portable between
>> Smalltalks. Code Critics gives the following information on my packages:
>>
>> - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the
>> ANSI string protocol.
>>
>> - #cr and #lf are not part of the ANSI stream protocol.
>>
>> - The ANSI standard does not support #asInteger and #asString on Object.
>>
>> - Some collection methods are not ANSI compatible: #pairsDo:,
>> #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
>> #keysSortedSafely, #new:withAll:, etc.
>>
>> Does anyone have an idea on how to transform those sends to be ANSI
>> compatible?
>
> Hi Hernan,
>
> I don't think being ANSI-compatible should be a goal in any case. You
> won't find any Smalltalk flavor (commercial or Open Source) that is
> fully ANSI-compatible. All vendors have their
> extensions/exceptions/versions. Just have a look at Glorp to convince
> yourself of differences between Smalltalk implementations!
>
> But if your goal is portability, I'd say you should start by having your
> code compatible with VAST, VW, Dolphin & Squeak. You'll probably cover
> most of other Smalltalks variants by doing so. The ANSI standard was
> never, to my knowledge, 100% fully respected by any Smalltalk vendor.
> Most of them tried to but none of them implemented it with 100%
> compliance. In other words, just do your best at satisfying
> compatibility with the most vendors.

Hi Benoit,

Just for the record :) I've worked with a custom implementation of
Smalltalk which was 100% tested ANSI-compatible. It was in 2004 and
unfortunately the project never saw the light except for our customer.
However I wasn't in the team responsible for the ANSI compliance, but
for the testing. It was called "Chachara Smalltalk" and it has some
interesting features at that time: No object table, compacting
generational GC with variable # of generations, C++ VM with reified ST
meta-model, etc. You may see a screenshot in the attachment, that proves
nothing, but sometimes it's nice to see screenshots.

>
> This one uses Xtreams, the other one Nautilus browser or Zinc, the other
> one starts Array indices at 1, this other one does this, the other one
> does that, one uses Smalltalk while the other uses SmalltalkImage, etc.
>

Yes, but the goal of the standard is to provide an ideal protocol of
behaviors. Globals are only defined if they conform a protocol. UI,
Database and Graphics were unspecified until Smalltalk implementations
converge... which could be never.

> Unfortunately, we're not in the Java world. You'll eventually need a
> Bundle/Application/Project/Package named "Portability" just like
> everyone else...
>

I'm afraid so... I wonder what's the status of Grease. Any Seasider reading?

Cheers,

Hernán

ChacharaSmalltalk1.jpg (427K) Download Attachment

hernanmd

Re: [squeak-dev] Re: Transform sends to ANSI standard?

In reply to this post by Levente Uzonyi-2

Hi Levente,

On 26/09/2012 2:25, Levente Uzonyi wrote:

> On Tue, 25 Sep 2012, Hernán Morales Durand wrote:
>
>>
>> Hi folks,
>> I am rewriting packages to be compatible or more portable between
>> Smalltalks. Code Critics gives the following information on my packages:
>>
>> - #cr, #crlf, #lf, #space, #tab, #findTokens:, ... are not part of the
>> ANSI string protocol.
>>
>> - #cr and #lf are not part of the ANSI stream protocol.
>>
>> - The ANSI standard does not support #asInteger and #asString on Object.
>>
>> - Some collection methods are not ANSI compatible: #pairsDo:,
>> #collect:thenDo:, #reject:thenDo:, #detectSum:, #valuesDo:,
>> #keysSortedSafely, #new:withAll:, etc.
>>
>> Does anyone have an idea on how to transform those sends to be ANSI
>> compatible?
>
> Is there an ANSI compatible Smalltalk implementation out there? I doubt
> it. If I were you, then I'd use a compatibility layer like Sport or
> Grease, instead of relying on the ANSI standard.
>

Yes, for compatiblity I'm currently using Grease as much as I can. Read
my reply to Benoit about the ANSI Smalltalk.

> But to answer your question: you should check how these methods are
> implemented and check if the implementation is ANSI compatible or not.
> In most cases they are:
>
> string cr ==> Character cr asString
>
> #lf same as above
>
> stream cr ==> stream nextPut: Character cr
>
> #lf, #space, #tab similar to #cr
>
> stream crlf ==> stream nextPut: Character cr; nextPut: Character lf
>
> #findTokens: ==> no ANSI compatible method. If the argument is a single
> character, then you can create a stream on the collection and use #upTo:
> to find the parts.
>
> collection collect: aBlock thenDo: anotherBlock ==> (collection collect:
> aBlock) do: anotherBlock
>
> collection detectSum: aBlock ==> collection inject: 0 into: [ :sum :each
> | sum + (aBlock value: each) ]
>
> #valuesDo: ==> use #do: or #keysAndValuesDo: instead
>
> #keysSortedSafely ==> sorting is not part of the ANSI standard, only
> SortedCollection is, so you can use something like: collection keys
> asSortedCollection: [ :a :b | <copy the contents of the sort block here
> from #keysSortedSafely> ]
>
> Array new: x withAll: y ==> (Array new: x) atAllPut: y
>
>

This was what I wanted. Thanks for the tips, Levente.

Cheers,

Hernán

> Levente
>
> P.S.: My problem with the ANSI standard is that it seems more like
> something that documents the common things in Smalltalks at the time of
> its creation instead of a complete and future-proof base API.
>
>>
>> Best regards,
>>
>> Hernán
>>
>>
>>
>
>
>