lazy (?) evaluation, request for advice

[Tim Peters]

[Alex Martelli]
>>> ... I'd much rather let the user write the deal-selection
>>> function in Python, than in either Tcl, or any custom,
>>> ad-hoc "little language".

[Tim, proving that his ability to give offense did not die
 with the changing of the calendar]
>> Against that, you invented ad-hoc semantics as you went along;
>> the only connection to Python appeared to be syntactic.

[Alex]
> Did I?  I used, e.g., spades to mean "the value of a
> variable named `spades' in the current scope[s]".  Isn't
> that normal Python semantics? ...
> I would appreciate understanding how you define "syntactic" in
> this context to justify this extremely peculiar assertion.

The answer to "what's in a name?" is fundamental semantics for any language.
Your language's answer is not Python's answer, hence my objection to calling
the former Python.

> ...
> Where more than one hand is of interest, object notation will
> be used; and where more power is needed, statements will be
> used rather than just an expression.

The last wasn't (isn't) clear.  You described it as a "deal-selection
function", but the example fragments showed only expressions.  If you are in
fact going to treat isolated expressions as if they were functions, it's
again a sense in which your language is not (although may be related to)
Python.  This means you're in the language-design business, as you went to
great lengths in this reply to prove; I can only repeat my advice that
Python is already well-designed and your users will be better served in the
end by letting them use the language as-is; you don't agree, so that's that.

>> Note also that if your users truly are morons, there's
>> nothing to stop *you* from marching over their string and
>> replacing e.g. "spades" with "current_hand.spades" before
>> compilation.

> Is there a way I could use the existing parsing tools to help
> me with this?  I've read through the library reference, but I
> still find that part a tad obscure. 3.14.6.1 and 3.14.6.2 are
> the parts I am thinking about.  If I could examine in the AST
> the variable names used in the expression, matching them with
> the dictionary of the hand features I know how to evaluate, I
> could pre-populate the dictionary to be used as the scope in
> the eval; or, I guess, change the variables as you suggest, to
> get even lazier (for those cases where short-circuit logic
> lets me evaluate a certain feature only in a subset of cases).
>  But the logic for examining, and even more for modifying, the
> AST, appears to be somewhat complex. Are there more online
> examples that I could use?
>
> Or, were you suggesting a similar operation on a purely lexical
> level?  E.g., with tokenize?  Or, a string-manipulation
> approach?

Well, "all of the above", plus John Aycock's SPARKS system and Michael
Hudson's bytecodehacks, *may* be appropriate.  It's simply impossible to be
helpful here until your language is fully defined, which is the first point
at which we can judge how radical a transformation is needed to convert it
into executable Python.

>From what you've said so far, it doesn't *look* like anything fancier than a
regexp replace is needed; e.g.,

import re, string
IMPLIED_OBJECT_NAME = "__whatever"
magic_names = string.split("diamonds clubs hearts spades losers")
_lookfor = re.compile(r"\b(" +
                      string.join(magic_names, "|") +
                      r")\b")
_replace = IMPLIED_OBJECT_NAME + r".\1"

during module initialization, and

   codestring = _lookfor.sub(_replace, codestring)

to do the transformation.  This changes, e.g.,

    spades >= 6 or hearts >= 6

to

    __whatever.spades >= 6 or __whatever.hearts >= 6

The bracketing word-boundary assertions ("\b") in the regexp prevent it from
transforming e.g. biglosers or heartsaches.  Generating a whole parse tree
wouldn't work any better, *provided that* you don't have string literals in
your language, and that the mapping to Python isn't hairier than simple
token substitution.

> I will appreciate further advice about this, and tolerate the
> sneers and name-calling that seem to go with the advice
> (although rarely have I seen discussion quite as sneering as
> this on this group

Alex!  That wasn't sneering -- it was brazen ridicule <wink>.  Seriously,
the exaggerated relentlessness of it all was supposed to nudge you away from
taking at all soooooo seriously.  Didn't work, eh?

> -- reminds me a lot of the ambiance on the Perl group -- this
> one had so far seemed friendlier, though I guess that may have
> been an artefact due to a frequentation started more recently).

Oh, this *is* much friendlier.  Over on c.l.p.m., they would have called
*you* an idiot.  I consistently insulted your *users*.

how-much-friendlier-can-a-computer-guy-get<wink>?!-ly y'rs  - tim