[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why would anyone want opacity?
As I understood Jaffer's proposal, the existing R4RS syntax
for LAMBDA creates opaque procedures and the new ("advertised")
syntax created (advertised?) procedures.
I generally like the idea, but I think it's useful to have an
interface that makes heuristic information available for all
procedures, not just those that are created using a special
syntax. In a separate message I have proposed such an interface.
With this interface, Jaffer's syntax could be used to declare
that debugging is more important than optimization for a specific
lambda expression.
> - syntax: lambda <formals> <documentation> <body>
> *Syntax:* <Formals> should be a formal arguments list as
> described below, and <body> should be a sequence of one or more
> expressions. <Documentation> is a string.
This makes <documentation> come before rather than after any
internal definitions. Is that the intended syntax?
My personal preference would be to have the documentation string
come after the internal definitions. Then the advertised syntax
would be a special case of the current syntax, and we wouldn't
have to extend the language.
> This information is not available for
> opaque procedures. However, opaque procedures can be optimized
> more aggressivly by compilers.
I would prefer "may not be" and "may be" instead of "is not"
and "can be".
> Shouldn't compilers rename lambda-lifted procedures?
Probably, but I was guessing that some people would want to
maintain whatever correspondences were possible. Twobit, for
example, renames all local variables, not just lambda-lifted
procedures, but I think most people would prefer to see the
original names when debugging.
Jeff Dalton wrote concerning the prevalence of
representation-dependent code:
> Do you have, like, statistics?
No, but I have lots and lots of anecdotal evidence. Most people
who have supervised a reasonably large multi-person project have
similar stories to tell.
> Your map instead of map-set looks like a plausible source of
> accidental errors, but how often are the words so similar?
It isn't the similarity of the words that causes the problem.
The problem comes from forgetting whether you're an implementor
of the ADT (in which case it's ok to depend upon the representation)
or a client of the ADT. This is a conceptual problem that most
inexperienced programmers seem to have, particularly when they
spend their morning implementing the ADT and their afternoon
writing client code (and switching back and forth between the
two to fix bugs).
It's a special case of the well-documented problem of switching
between two cognitive contexts. It's not a lexical problem at all.
Will