On Sat, Jun 4, 2011 at 10:08 AM, Alan Kay <alan.n...@yahoo.com> wrote:
[...]
> This left the other question and possible motivation for static type
> checking, which was: could the tradeoffs it imposed still wind up helping
> the programmers more than bogging them down?
>
> The extreme case of this -- where the variables are actually constrained to
> the specific values they are supposed to contain -- would be very useful if
> it could be made to generally work -- it amounts to declarative programming.
A specific case only, but a useful one: SQL. (Even if it is an
"ad-hoc, informally-specified, bug-ridden, slow implementation of
half" of the relational model.)
> Another extreme case would concern procedures/methods (we've called it
> "semantic typing"). For example, we want to find an operator that will do
> something specific -- like the sine function -- and we type our local name
> for this so that the only value it can have is a procedure that will compute
> sine. We could think of this as a kind of unit test for resources, or we
> could think of this as search criteria. Ted Kaehler implemented the Squeak
> method finder to do some of this. You give it examples of relations and it
> finds the methods. So 3 . 4 . 7 will yield both "+" and "xor". 30 . 0.5 will
> find "degreeSine", etc.
[...]
> It's always seemed to me that what we really need to be working on is
> something more like "real specifications that execute to produce prototypes
> (and can be debugged) much more than weak schemes that are complex enough to
> introduce severe cognitive load, but aren't comprehensive enough to come
> close to paying their way.
A small step along the path? Haskell's type system and the Hoogle
Haskell API search engine:
http://haskell.org/hoogle/
Regards,
Mike
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
