Comment on PEP-0238

[Bengt Richter]

At 10:16 2001-07-09 +0200, Thomas Wouters wrote:
>On Sun, Jul 08, 2001 at 08:02:27PM -0700, Bengt Richter wrote:
>
> > >Doesn't fix the problems. What about this:
> > >
> > >semantics PRECISION, 0:
> > >     x = 2/7
> > >
> > >semantics PRECISION, 100:
> > >     print x
>
> > I'm thinking that's trying to peek from one nested scope into another,
> > and would be either illegal, trigger a special exception, or get you
> > a NameError. I haven't thought this through, but that was
> > part of the reason for a block rather than just setting global control
> > parameters. I think only new bindings would be affected. Rebinding
> > global names to stuff created within a semantic scope might have to carry
> > environment along. I haven't thought that through either ;-)
>
>Note that currently, only functions and classes introduce a new scope, not
>other blocks like if, for, try, etc. And this still is no solution: if you
>can't carry values from your 'precision scopes' to upper scopes, they are

Actually, my scopes were 'semantics' scopes. I just jumped on the
precision thing as one possible use. I.e., 'semantics' being one
keyword for similar patterns of use.

>useless black bloxes that eat everything that goes in :) And an explicit
>'return x' is not going to change anything about the problem.

By that logic most programs are useless black bloxes ;-)
(I.e., since they don't have an "upper scope" to carry values to).

I realize about the blocks. I was thinking def/class/lambda/something.

>And what about this, for that matter:
>
>def printme(x):
>     semantics PRECISION, 100:
>         print x

It would seem to call for semantic coercion when using variables with
different semantics. To carry the information about applicable semantics
would be something like carrying bindings in a closure, I'm thinking.
The latter is what I was getting at with "carrying environment" above.

>semantics PRECISION, 0:
>     x = 2/7
>     printme(x)
Meaning 2/7 is evaluated with (PRECISION,0) rules, and the resulting
value representation includes a reference to those rules (because the
'/' operator is overridden within the scope to do that). The symbol
x is bound to the value, and the value reference is passed to printme,
which will have to deal with it according to its context.

OTTOMH, perhaps the semantics keyword could cause the following block
to be translated to an anonymous function (like lambda but full def
capability) and then a reference to it would be passed to a standard
method of the semantics-altering system object referred to in the
semantics arg list, e.g., one bound to the symbol PRECISION in this case.

If you call the tuple of semantics args t, and the lambda of the block f,
then semantics processing might call t[0].__SEMANTICS__(f,t[1:]) by 
convention. Thus PRECISION.__SEMANTICS__(f,t[1:]) would see the lambda
and be able to fiddle with its environment before it got executed.

For PRECISION I assume that would involve overrides for some math operations.
After the mods, which semantics knows nothing about, semantics would execute
the lambda.

If you had a semantics INTEGER_DIV: ... block, then
INTEGER_DIV.__SEMANTICS__(f,()) would be called, perhaps overriding
the '/' operator with divmod(x,y)[0] and % with divmod(x,y)[1]
for the ensuing lambda execution.

>(or even with printme defined as
>
>semantics PRECISION, 100:
>     def printme(x):
>         print x
That would be ok for access within the scope, but it
wouldn't be visible from the outside of the lambda.

This could be an instance of PIHCAL (post in haste, cringe at leisure)
but it's fun to toss around ;-)

Regards,
Bengt Richter