Kind Folks,
I just feel obligated to say that I had absolutely no intention
of introducing the far too well-worn debate between untyped,
latently typed and manifestly typed languages.
My intention was to far more specifically ask: why "small
core, user comprehensible and modifiable, and boot-strapable"
systems seem to be the province of either latently typed (Smalltak,
Lisp, Scheme, Icon (?), etc.) or untyped (Forth, B (?)) languages
rather than...
...manifestly typed languages (wide variety - C++, D, Oberon,
Haskell, Standard ML and oodles more).
This is a very highly contextual question, I believe apropos of
this mailing list.
Mucho thanks again, in advance.
- S.
On 6/4/2011 11:27 AM, Michael Forster wrote:
On Sat, Jun 4, 2011 at 10:08 AM, Alan Kay<[email protected]> 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
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
