lazy (?) evaluation, request for advice
Tim Peters
tim_one at email.msn.com
Thu Jan 6 19:52:46 EST 2000
[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
More information about the Python-list
mailing list