I think you answered your own question. A small core is small since it is
limited to what is required to make it run. This eases development and lets
you focus on what's important and interesting.
On Jun 4, 2011 6:06 PM, Scott McLoughlin scottmc...@gmail.com wrote:
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 Kayalan.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
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
