[E-Lang] proposal for lexically limited retvals in an expression language

zooko@zooko.com zooko@zooko.com
Tue, 06 Mar 2001 11:54:21 -0800


Here is an idea for lexically limiting return values without (I hope) touching
the dreaded "expression language" issue.

1.  Make a guard, called e.g. ":retAny", which passes the value iff it is
wrapped in a "RetWrapper" object.  This guard returns the bare object, not the
RetWrapper wrapper containing the object.

2.  Make a new reserved word `return' which wraps its argument in a RetWrapper

That's it.

AFAICT, this gives you all of the advantages of explicit return values without
the disadvantages of a non-expression-language syntax.  It also offers the
possibility of supporting both expression-language-style code and
required-return-keyword code (simply by using ":exprInteger", which allows all
Integers out, instead of ":retInteger", which allows only `return'ed integers

The advantages of explicit return values include:

1.  No more "transitive leakage due to ignorance".  It is no longer the case
that a capability is accidentally leaked from a function `f' simply because the
programmer of `f' was unaware that the last function that *she* used in the
implementation of `f' returned a capability.  

2.  `return' style is the standard to mainstream programmers, as proven by the
fact that among sourceforge's top five languages (excluding niche language PHP),
only Perl doesn't use it, and C, C++, Java, and Python do.

3.  Fewer keystrokes because you needn't use an explicit guard, even on
functions that return values.  This seems like a win on the "Ease of
Use/Scripting" part of the Marketing Plan.  (Having to use an explicit `return'
keyword is a loss on ease of use, but it is not a loss on the "Ease of
Use/Scripting" part of the Marketing Plan, since mainstream programmers expect

4.  Auditors who are trying to find out where capabilities are leaking from can
quickly scan or even grep long function definitions searching for the `return'

5.  Lazy programmers put `return' on the specific things that they are going to
return, and leave the guard at the implicit default of ":retAny".  This gives
much more type information to later developers, auditors and automatic type
inferencers, contrasted with the lazy programmers putting ":any" on all
functions that return anything.

Please excuse me if this has been discussed before.  I did consult the archives
concerning the "reveal" operator `^', but I may have missed important parts of
the discussion.

Also please excuse me if this is tantamount to revoking the "expression-
language" design decision.  I don't think that it causes the problems that would
be caused by revoking "expression-language", but I could be wrong.  It is
certainly not my intent to attempt to persuade MarkM to abandon expression-

(BTW, this idea comes from contemplating the relation between traditional type
systems and MarkM's "guard" notion.  I must say I am very impressed with the
idea of "guards", and that I look forward to the evolution and combination of
traditional type systems, guards, and rely/suspect typing...)