[e-lang] Returning guards from __getAllegedType: opinions needed
Mark S. Miller
markm at cs.jhu.edu
Mon Oct 16 10:58:02 CDT 2006
Kevin Reid wrote:
> A principle which accounts for both of these is that anything between
> the 'def' and the method bodies --
>
> def foo extends bar { to run(arg :guard) :int { return 99 } }
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> is public.
["implements baz" removed from the example so that email clients won't rewrap.
Kevin qualifier about the "implements baz" part remains true.]
> If the programmer wishes to hide a powerful guard, or a more specific
> guard, they can re-coerce inside the body:
>
> def f(box :Box) {
> def thing :Unseal := box
> }
The thing I really like about this rule is that we can explain what's hidden
according to the syntactic placement of curly brackets, which fits well with
the rest of the E language.
This let us sensibly also reserve the right for __getAllegedType to reveal
other information appearing between the "def" and the method/matcher bodies,
such as the ASTs of the patterns. I can imagine this being useful, e.g., for
future documentation generator tools. For example, in E one defines a
variable-arity function as
? def add {
> match [`run`, args] {
> var result := 0
> for arg in args {
> result += arg
> }
> result
> }
> }
# value: <add>
? add(3,4,5)
# value: 12
? add.__getAllegedType().help()
# value: interface "__main$add" {
# }
#
It would be nice if, in a future version of E, add's alleged type explained
its protocol better. It would therefore be good for us to reserve the right
for future __getAllegedType behavior to be enhanced to provide such
information. We allow this merely by saying that the programmer may not rely
on future __getAllegedType behavior not revealing information visible outside
the curlies which bracket the object's method/matcher bodies.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the e-lang
mailing list