Greedy triple-quoted string literals
liorean at gmail.com
Mon Feb 18 13:17:56 PST 2008
On 18/02/2008, Lars T Hansen <lth at acm.org> wrote:
> It's been pretty quiet around here since we debated tail calls...
I never finished my part of that discussion... I have a long message
half-written on it since how long? Three months ago? I never quite
finished my line of thought though.
<digression about tail-calls>
Basically the idea was along the lines of investigating the effects of
removing GetValue usage from those productions whose semantics just
pass values through (such as all the shortcut evaluation operators,
parenthesised expressions, plain assignment, function arguments,
return statement etc.). The only semantics that would in effect be
changed are those for function calls. Function calls would always
"remember" the this-object of any member lookup since they are passed
around as a Reference object, while still not making that object
outside detectable. Of course if the function is referenced again
using member lookup, then a new Reference object would be created with
the new base object and the function object itself GetValue'd out of
the old Reference object.
This change would eradicate a pet peeve of mine:
o.f(); // => o
f(); // => window
(o.f)(); // =>o
(f=o.f)(); // => window
With the change, all of those would return o.
I never quite finished my analysis of the backwards compatibility and
security implications of doing such a change though.
For backwards compatibility the issues with doing such a change should
be minor in live code. It would only affect code that both expects the
this-object to be the global object and which extracts the function
from an object using shortcut evaluation or assignment operation.
For security, there's somewhat greater implications. IF the function
cooperates (and ONLY in that case) the this-value could be extracted
through return value or assignment to a scoped variable. This can only
happen if the function itself either returns the this-object or
assigns it to an external variable.
</digression about tail-calls>
> That is what Comen, Leiserson, and Rivest[*] call greedy in
> their discussion of greedy algorithms: "A //greedy algorithm// always
> makes the choice that looks best at the moment. That is, it makes a
> locally optimal choice in the hope that this choice will lead to a
> globally optimal solution."
> Knuth does not include the term in his index, sadly, nor do any of my
> other algorithm books. Can somebody dig up a conflicting definition
> so that we can get a real discussion going?
When discussing "greedy" and "lazy" in terms of quantifierrs in regex,
the usual way to talk about them is that out of multiple valid
matches, "greedy" choses the match containing as many repetitions as
possible, and "lazy" choses the match containing as few repetitions as
possible. I don't know of a text that has a more formal definition
than that, really, nor do I know of any definition of greedy/lazy
algorithms as opposed to greedy/lazy quantifiers in regex or grammars.
I've got no formal CS education though, so I've not read that much of
David "liorean" Andersson
More information about the Es4-discuss