"Ian Upright" <[hidden email]> wrote in message
news:[hidden email]... > Are there any macro capabilities in Smallscript? Not in the SmallScript language itself. Macro's are a great and powerful facility which I frequently use in other languages. However, anyone familiar with lisp and scheme code maintenance would probably concede that macros are at odds with the basic philosophy of Smalltalk. My view is that, since other languages will be available for the v4 AOS Platform, if I need macros I can design those macro based elements in an AOS Platform language where they are more appropriate. Noting that: (1) any language supported on the AOS Platform will inter-operate with any other AOS Platform language; (2) the AOS Platform toolset for Microsoft.NET is designed as a front-end .NET object-model interface and a back end .NET code emitter for any AOS Platform language. > > If you want to build switches like these: > > DebugMode isOn ifTrue:[ self checkSomeCondition ]. > > Does it get optimized away into nothing if its turned off? No. If <DebugMode> is a variable and it is changed during execution then the code behavior must be able to reflect that. However, the compilers do perform constant folding/propagation so if <DebugMode> was resolved to an implicit ##const value then such constructs could be compiled away. I.e., SmallScript (and QKS Smalltalk) support, on a per namespace (class) basis, the notion of ##consts (Smalltalk equivalent to C/C++ .h enums). Their precedence and scope is one level below variables within a given namespace [although it is bad form to shadow ##consts with variables in the same namespace]. Dolphin has an interesting extension that will evaluate an expression at compile time and substitute that result into the code. I believe they use something to the effect of #[...expr...]. Which syntactically conflicts with VW usage. I would want to change it to ##[...] which would make it consistent with the ##const concept. While I need to give it more thought, I would be willing to consider adding such a construct if its resulting values were constrained to literal constants. ##[DebugMode] isOn ifTrue: [self checkSomeCondition]. -- Dave S. [SmallScript; QKS Smalltalk/SmalltalkAgents] > > Ian > |
"David Simmons" <[hidden email]> wrote in message
news:aoBK6.1848$%[hidden email]... > "Ian Upright" <[hidden email]> wrote in message > news:[hidden email]... > > Are there any macro capabilities in Smallscript? > > Not in the SmallScript language itself. Macro's are a great and powerful > facility which I frequently use in other languages. However, anyone familiar > with lisp and scheme code maintenance would probably concede that macros are > at odds with the basic philosophy of Smalltalk. > > My view is that, since other languages will be available for the v4 AOS > Platform, if I need macros I can design those macro based elements in an AOS > Platform language where they are more appropriate. > > Noting that: (1) any language supported on the AOS Platform will > inter-operate with any other AOS Platform language; (2) the AOS Platform > toolset for Microsoft.NET is designed as a front-end .NET object-model > interface and a back end .NET code emitter for any AOS Platform language. > > > > > If you want to build switches like these: > > > > DebugMode isOn ifTrue:[ self checkSomeCondition ]. > > > > Does it get optimized away into nothing if its turned off? > > No. If <DebugMode> is a variable and it is changed during execution then > code behavior must be able to reflect that. However, the compilers do > perform constant folding/propagation so if <DebugMode> was resolved to an > implicit ##const value then such constructs could be compiled away. > > I.e., SmallScript (and QKS Smalltalk) support, on a per namespace (class) > basis, the notion of ##consts (Smalltalk equivalent to C/C++ .h enums). > Their precedence and scope is one level below variables within a given > namespace [although it is bad form to shadow ##consts with variables in the > same namespace]. > > Dolphin has an interesting extension that will evaluate an expression at > compile time and substitute that result into the code. > > I believe they use something to the effect of #[...expr...]. Which > syntactically conflicts with VW usage. I would want to change it to ##[...] > which would make it consistent with the ##const concept. > > While I need to give it more thought, I would be willing to consider adding > such a construct if its resulting values were constrained to literal > constants. > > ##[DebugMode] isOn ifTrue: [self checkSomeCondition]. Uh, dummy me. To achieve Ian's desired effect this would have to be written as: ##[DebugMode isOn] ifTrue: [self checkSomeCondition]. -- Dave S. > > -- Dave S. [SmallScript; QKS Smalltalk/SmalltalkAgents] > > > > > Ian > > > > |
In reply to this post by David Simmons
Dave
"David Simmons" <[hidden email]> wrote in message news:aoBK6.1848$%[hidden email]... > "Ian Upright" <[hidden email]> wrote in message > news:[hidden email]... > > Are there any macro capabilities in Smallscript? > ... > Dolphin has an interesting extension that will evaluate an expression at > compile time and substitute that result into the code. > > I believe they use something to the effect of #[...expr...]. Which > syntactically conflicts with VW usage. I would want to change it to ##[...] > which would make it consistent with the ##const concept. No, it is ##(...). #[...] in Dolphin has the same meaning as in VW (i.e. it defines a literal byte array). VisualAge originated the ##(...) constant expresssions, and we thought it would be useful. Indeed it is, but it should be used with care to avoid creating maintenance problems, for example the the code in the expression is evaluated and then discarded so searching for references etc in the normal way will not find any from constant expressions. Of course this could be improved by having the compiler build references from the constant expression into the literal frame in the normal way, even though they are not used by the code in the method, but Dolphin doesn't currently do that. There are in any case other issues with it, as a static construct, being somewhat against the dynamic nature of Smalltalk and its iterative interactive development style, and I have some sympathy with that viewpoint. Regards Blair |
Free forum by Nabble | Edit this page |