Re: Macros in SmallScript

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Macros in SmallScript

David Simmons
"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
>


Reply | Threaded
Open this post in threaded view
|

Re: Macros in SmallScript

David Simmons
"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
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].

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
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Macros in SmallScript

Blair McGlashan
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