Smalltalk › Gemtalk › Gemstone/S

ByteArray literals and Array constructors

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 7 messages Options
James Foster-6
Reply | Threaded
Open this post in threaded view
♦
♦
|

ByteArray literals and Array constructors

James Foster-6
We have a feature request to add ByteArray literals to GemStone Smalltalk. Interested parties are invited to comment on the various options (or suggest others).

Background:
  • ANSI Smalltalk specifies Array literals using a #() syntax, and GemStone supports this syntax.
  • Although not part of ANSI, most Smalltalks allow ByteArray literals using a #[] syntax.
  • Unfortunately, GemStone uses #[] for an Array constructor (with expressions separated by comma), so there is another difference between GemStone Smalltalk and most of the other Smalltalks.
  • Squeak/Pharo uses {} for Array constructors (with period/dot separators rather than comma), and this syntax is supported by GemStone (it does not conflict with 'select blocks' since a select block always takes one argument).
Options
  1. No change. Keep the syntax simple; don't add more complexity to the language. ByteArray instances can be constructed using existing syntax and stored if needed for performance.
  2. Add a unique ByteArray literal syntax to GemStone that is backwards-compatible with existing code (i.e., does not conflict with the existing Array constructor). A likely syntax would be #B(), such as #B(0 1 2 3 255). This gives the opportunity to consider other literals, like an OrderedCollection, and other constructors, like #B[].
  3. Change the meaning of #[] from an Array constructor to a ByteArray literal. This change could be made for 3.0 and could require  modification to some existing code and scripts. Tools could be provided to assist in finding code that needs modification.
Do you use the existing GemStone Array constructor?
Would you use a ByteArray literal if it were available?
Do you have other suggestions?
Georg Gollmann
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: ByteArray literals and Array constructors

Georg Gollmann

Am 03.05.2010 um 20:40 schrieb James Foster:

> Do you use the existing GemStone Array constructor?
Yes.

> Would you use a ByteArray literal if it were available?
I have no current use for this.

> Do you have other suggestions?
Breaking backwards compatibility would be a pain.

Kind regards
Georg Gollmann



Paul Baumann
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: ByteArray literals and Array constructors

Paul Baumann
In reply to this post by James Foster-6
One solution involves a radical and more useful construct; the Compile-time evaluated method literal.
 
VA is one dialect that uses this syntax. The syntax has been added to other dialects over the years, but I haven't used it since VA.
 
##[ some code]
 
The "some code" gets evaluated when the code is compiled, and the result is stored in a method literal. This is how you could use it to store a byteArray:
 
byteArray := ##[ #(65 66 67) asByteArray ].
 
The method literal refers to an object--any object.
 
I loved using this feature in VA. It allowed for some useful optimizations. It allows code to be optimized and self-describing at the same time. The most frequent alternative to having this syntax is to declare some object (sometimes a pool dictionary) or registered instance that is initialized by other code elsewhere. This syntax makes it easier to maintain extremely fast code.
 
The drawbacks:
 
1) If you save compiled methods, you need to also have a way to save objects.
2) It is possible for someone to write code that does not compile to behave the same way.
3) Code may have compiled fine when written, but now errors on file-in.
 
#1 is even less an issue in an object database than it was in VA. In VA it would have been an issue for IBM when doing the equivalent of a VW pcl file to store pre-compiled methods (I forget what IBM called their form; component something).
 
#2 is really a non-issue but I mentioned it before someone else raises it. Someone may misuse anything and be surprised by results. Just note how the feature works. Having code that may not compile the same way can be useful for platform-specific code. Kind of like C pre-compiling.
 
#3 Same issue as #2. Users need to know how to use the feature properly.
 
Paul Baumann 
IntercontinentalExchange | ICE
2100 RiverEdge Pkwy | 5th Floor | Atlanta, GA 30328
Tel: 770.738.2137 | Cel: 678.460.7527
[hidden email]
 

From: [hidden email] [mailto:[hidden email]] On Behalf Of James Foster
Sent: Monday, May 03, 2010 2:40 PM
To: GemStone Smalltalk Customer Forum
Subject: [gemstone-smalltalk] ByteArray literals and Array constructors

We have a feature request to add ByteArray literals to GemStone Smalltalk. Interested parties are invited to comment on the various options (or suggest others).

Background:
  • ANSI Smalltalk specifies Array literals using a #() syntax, and GemStone supports this syntax.
  • Although not part of ANSI, most Smalltalks allow ByteArray literals using a #[] syntax.
  • Unfortunately, GemStone uses #[] for an Array constructor (with expressions separated by comma), so there is another difference between GemStone Smalltalk and most of the other Smalltalks.
  • Squeak/Pharo uses {} for Array constructors (with period/dot separators rather than comma), and this syntax is supported by GemStone (it does not conflict with 'select blocks' since a select block always takes one argument).
Options
  1. No change. Keep the syntax simple; don't add more complexity to the language. ByteArray instances can be constructed using existing syntax and stored if needed for performance.
  2. Add a unique ByteArray literal syntax to GemStone that is backwards-compatible with existing code (i.e., does not conflict with the existing Array constructor). A likely syntax would be #B(), such as #B(0 1 2 3 255). This gives the opportunity to consider other literals, like an OrderedCollection, and other constructors, like #B[].
  3. Change the meaning of #[] from an Array constructor to a ByteArray literal. This change could be made for 3.0 and could require  modification to some existing code and scripts. Tools could be provided to assist in finding code that needs modification.
Do you use the existing GemStone Array constructor?
Would you use a ByteArray literal if it were available?
Do you have other suggestions?

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
Robert.Love
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: ByteArray literals and Array constructors

Robert.Love
In reply to this post by James Foster-6
Do you use the existing GemStone Array constructor?  
 
Yes
 
Would you use a ByteArray literal if it were available? 
 
Yes
 
Do you have other suggestions? 
 
#B(...) seems a reasonable syntax. Smalltalk's strength is its natural-language character, and this syntax is more consistent with that philosophy than other suggestions involving more "arcane" characters (such as curly brackets).

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
       
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.  The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.  
If verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.

 
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
federico.mennite@lifeware.ch
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: ByteArray literals and Array constructors

federico.mennite@lifeware.ch
In reply to this post by James Foster-6


Do you use the existing GemStone Array constructor?
Yes, but mostly for "byte" values.
Would you use a ByteArray literal if it were available?
Yes. In our environment It would allow some serious performance gains without having to deal with the complexity of managing instantiated Bytearrays.

Regards,
Federico
federico.mennite@lifeware.ch
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: ByteArray literals and Array constructors

federico.mennite@lifeware.ch
In reply to this post by James Foster-6
Not that I would put it as requirement for Gemstone but I really like the "optimization and self describing parts" of  this approach.
It also avoids the gap you can possibly have when updating the initialization code of a class var and forgetting to run it.

Possible drawback aside, it seems to make class vars nearly unnecessary.

Regards,
Federico


On 03.05.2010 21:16, Paul Baumann wrote:
One solution involves a radical and more useful construct; the Compile-time evaluated method literal.
 
VA is one dialect that uses this syntax. The syntax has been added to other dialects over the years, but I haven't used it since VA.
 
##[ some code]
 
The "some code" gets evaluated when the code is compiled, and the result is stored in a method literal. This is how you could use it to store a byteArray:
 
byteArray := ##[ #(65 66 67) asByteArray ].
 
The method literal refers to an object--any object.
 
I loved using this feature in VA. It allowed for some useful optimizations. It allows code to be optimized and self-describing at the same time. The most frequent alternative to having this syntax is to declare some object (sometimes a pool dictionary) or registered instance that is initialized by other code elsewhere. This syntax makes it easier to maintain extremely fast code.
 
The drawbacks:
 
1) If you save compiled methods, you need to also have a way to save objects.
2) It is possible for someone to write code that does not compile to behave the same way.
3) Code may have compiled fine when written, but now errors on file-in.
 
#1 is even less an issue in an object database than it was in VA. In VA it would have been an issue for IBM when doing the equivalent of a VW pcl file to store pre-compiled methods (I forget what IBM called their form; component something).
 
#2 is really a non-issue but I mentioned it before someone else raises it. Someone may misuse anything and be surprised by results. Just note how the feature works. Having code that may not compile the same way can be useful for platform-specific code. Kind of like C pre-compiling.
 
#3 Same issue as #2. Users need to know how to use the feature properly.
 
Paul Baumann 
IntercontinentalExchange | ICE
2100 RiverEdge Pkwy | 5th Floor | Atlanta, GA 30328
Tel: 770.738.2137 | Cel: 678.460.7527
[hidden email]
 

From: [hidden email] [[hidden email]] On Behalf Of James Foster
Sent: Monday, May 03, 2010 2:40 PM
To: GemStone Smalltalk Customer Forum
Subject: [gemstone-smalltalk] ByteArray literals and Array constructors

We have a feature request to add ByteArray literals to GemStone Smalltalk. Interested parties are invited to comment on the various options (or suggest others).

Background:
  • ANSI Smalltalk specifies Array literals using a #() syntax, and GemStone supports this syntax.
  • Although not part of ANSI, most Smalltalks allow ByteArray literals using a #[] syntax.
  • Unfortunately, GemStone uses #[] for an Array constructor (with expressions separated by comma), so there is another difference between GemStone Smalltalk and most of the other Smalltalks.
  • Squeak/Pharo uses {} for Array constructors (with period/dot separators rather than comma), and this syntax is supported by GemStone (it does not conflict with 'select blocks' since a select block always takes one argument).
Options
  1. No change. Keep the syntax simple; don't add more complexity to the language. ByteArray instances can be constructed using existing syntax and stored if needed for performance.
  2. Add a unique ByteArray literal syntax to GemStone that is backwards-compatible with existing code (i.e., does not conflict with the existing Array constructor). A likely syntax would be #B(), such as #B(0 1 2 3 255). This gives the opportunity to consider other literals, like an OrderedCollection, and other constructors, like #B[].
  3. Change the meaning of #[] from an Array constructor to a ByteArray literal. This change could be made for 3.0 and could require  modification to some existing code and scripts. Tools could be provided to assist in finding code that needs modification.
Do you use the existing GemStone Array constructor?
Would you use a ByteArray literal if it were available?
Do you have other suggestions?

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Paul Baumann
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: ByteArray literals and Array constructors

Paul Baumann
In reply to this post by James Foster-6
Whoops. I just noticed the VA syntax is ##( some code ) rather than ##[ some code ].
 
Also, I'd been thinking that a mechanism for saving the binary of a compiled method would need to save the object. That would be wrong. Any mechanism for saving the binary of a compiled method containing compile-time evaluation literals should save source code (of the literal) that is evaluated when the compiled method is loaded. Saving the object from a previous execution would be far less useful and unnecessarily tricky. The literal could be a kind of association with code as key and object as value. Like other association literals (bindings), the value should be representative of the environment.
 
>> ...it seems to make class vars nearly unnecessary.

Perhaps. Just note the difference when using it for a class variable substitute that also has an embedded default value. Something like:
 
classVarSubstitute_holder
    ^##(Association new value: 'default value'; yourself)
classVarSubstitute
    ^self classVarSubstitute_holder value
classVarSubstitute: aValue
    self classVarSubstitute_holder value: aValue
 
In the example above, if #classVarSubstitute_holder were changed to include a new default value then that value would be effective as soon as the new method were compiled. A value previously assigned into the pseudo "class variable" would be replaced by the new default value. For that reason, if you use it as a class variable then you may want to separate initialization from definition: 
 
classVarSubstitute_holder
    ^##(Association new)
classVarSubstitute_initialize
    self classVarSubstitute: 'default value'.
 
You'd want to use it either as a class var or as a holder of a value that was determined at compile time. There is a chance of surprise when both are attempted at the same time. This would do both responsibilities, but isn't as efficient and needs a commit later to preserve the default value:
 
classVarSubstitute_holder
    | holder |
    holder := ##(Association new).
    holder value isNil ifTrue: [holder value: 'default value'].
    ^holder
 
You'd also need to be aware that if #classVarSubstitute_holder were recompiled for any reason then any assigned value would be flushed. Sometimes that is what you want; however, it is different from how a real class var would behave.
 
Paul Baumann 
 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Federico Mennite
Sent: Wednesday, May 05, 2010 8:51 AM
To: GemStone Smalltalk Customer Forum
Subject: [gemstone-smalltalk] RE: ByteArray literals and Array constructors

Not that I would put it as requirement for Gemstone but I really like the "optimization and self describing parts" of  this approach.
It also avoids the gap you can possibly have when updating the initialization code of a class var and forgetting to run it.

Possible drawback aside, it seems to make class vars nearly unnecessary.

Regards,
Federico


On 03.05.2010 21:16, Paul Baumann wrote:
One solution involves a radical and more useful construct; the Compile-time evaluated method literal.
 
VA is one dialect that uses this syntax. The syntax has been added to other dialects over the years, but I haven't used it since VA.
 
##[ some code]
 
The "some code" gets evaluated when the code is compiled, and the result is stored in a method literal. This is how you could use it to store a byteArray:
 
byteArray := ##[ #(65 66 67) asByteArray ].
 
The method literal refers to an object--any object.
 
I loved using this feature in VA. It allowed for some useful optimizations. It allows code to be optimized and self-describing at the same time. The most frequent alternative to having this syntax is to declare some object (sometimes a pool dictionary) or registered instance that is initialized by other code elsewhere. This syntax makes it easier to maintain extremely fast code.
 
The drawbacks:
 
1) If you save compiled methods, you need to also have a way to save objects.
2) It is possible for someone to write code that does not compile to behave the same way.
3) Code may have compiled fine when written, but now errors on file-in.
 
#1 is even less an issue in an object database than it was in VA. In VA it would have been an issue for IBM when doing the equivalent of a VW pcl file to store pre-compiled methods (I forget what IBM called their form; component something).
 
#2 is really a non-issue but I mentioned it before someone else raises it. Someone may misuse anything and be surprised by results. Just note how the feature works. Having code that may not compile the same way can be useful for platform-specific code. Kind of like C pre-compiling.
 
#3 Same issue as #2. Users need to know how to use the feature properly.
 
Paul Baumann 
IntercontinentalExchange | ICE
2100 RiverEdge Pkwy | 5th Floor | Atlanta, GA 30328
Tel: 770.738.2137 | Cel: 678.460.7527
[hidden email]
 

From: [hidden email] [[hidden email]] On Behalf Of James Foster
Sent: Monday, May 03, 2010 2:40 PM
To: GemStone Smalltalk Customer Forum
Subject: [gemstone-smalltalk] ByteArray literals and Array constructors

We have a feature request to add ByteArray literals to GemStone Smalltalk. Interested parties are invited to comment on the various options (or suggest others).

Background:
  • ANSI Smalltalk specifies Array literals using a #() syntax, and GemStone supports this syntax.
  • Although not part of ANSI, most Smalltalks allow ByteArray literals using a #[] syntax.
  • Unfortunately, GemStone uses #[] for an Array constructor (with expressions separated by comma), so there is another difference between GemStone Smalltalk and most of the other Smalltalks.
  • Squeak/Pharo uses {} for Array constructors (with period/dot separators rather than comma), and this syntax is supported by GemStone (it does not conflict with 'select blocks' since a select block always takes one argument).
Options
  1. No change. Keep the syntax simple; don't add more complexity to the language. ByteArray instances can be constructed using existing syntax and stored if needed for performance.
  2. Add a unique ByteArray literal syntax to GemStone that is backwards-compatible with existing code (i.e., does not conflict with the existing Array constructor). A likely syntax would be #B(), such as #B(0 1 2 3 255). This gives the opportunity to consider other literals, like an OrderedCollection, and other constructors, like #B[].
  3. Change the meaning of #[] from an Array constructor to a ByteArray literal. This change could be made for 3.0 and could require  modification to some existing code and scripts. Tools could be provided to assist in finding code that needs modification.
Do you use the existing GemStone Array constructor?
Would you use a ByteArray literal if it were available?
Do you have other suggestions?

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
Free forum by Nabble Edit this page