Compile Time Constants

David N. Smith (IBM) dnsmith at watson.ibm.com
Sat Jun 17 02:17:36 UTC 2000


At 17:01 -0500 6/16/00, Eric Arseneau wrote:
>Has there been any thought of adding compile time constants to Squeak ?  I
>find them very useful for obvious optimizations, as well as documenting code
>in a more readable fashion.
>
>In VA, I normally use expressions like
>	^number bitAnd: ##((2 raisedToInteger: 16) - 1)
>But in Squeak I have to change things like this to
>	^number bitAnd: 65535 "(2 raisedToInteger: 16) - 1, 16rFFFF - 1"
>
>As well, with the compile time constants, I can do away with a lot of Class
>variables I would normally use to cache information.  Which also gets rid of
>init code and reset code.
>
>my 2 cents.
>
>PS: I will be looking into what it would take to add some of the things I've
>mentioned lately.  I'm just wondering what others are thinking.  It should
>be easy to add ByteArray literals and CTCs.  The only issue is what the
>syntax of the CTC would look like.  The VA one leaves something to be
>desired, but it kinda works if you think of Symbols using # (maybe not ;->


Eric:

I miss them too, but they were being actively discouraged by the IBM Smalltalk team recently due to problems with portability to certain platforms. (I suspect that the 'certain platform' was our old buddy MVS but there may be problems porting to other platforms too.)

BTW,  that expression can be written as:

	^number bitAnd:  16rFFFF

which is clearly four sets of 4-bit digits, 16 bits of one-bits, and the operation is clearly masking off the right 16 bits of number. I find it clearer, but tastes vary and not everybody does.


If the reader has not run into the ##() construct, let me explain. It compiles and executes the expressions between the parentheses and places the result in the method (parse tree) instead of the construct. *Anything* can be evaluated in a text pane can be put between the parentheses including the opening of a file, bit twiddling of floating-point numbers, creating and posting a semaphore, and any other horrors you can think of.

On one hand they allow compile time evaluation of code that doesn't change at run time, and on the other they expose terrible monstrosities when, say, used to evaluate something that holds system memory for operating system functions.

Dave
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.





More information about the Squeak-dev mailing list