On 6/3/2011 8:37 PM, Scott McLoughlin wrote:
For many, many moons, I've examined the early Smalltalk
books, small bootstrap Forth systems, Lisp based systems
(implementing a large subset of CL decades ago) and the like.
In recent years, I've taken an interest in type systems and
typed functional languages.
What is the relationship, positive and negative, between static
typing in language design and user-transparent and modifiable
systems bootstrapped from small kernels?
Any elucidation or pointers to prior research greatly appreciated.
well, whether or not any of this is helpful or not, I don't know.
also, most of this is based on my own experience, which apparently some
people disagree with (for example, before when I claimed that to
implement a C compiler was hugely more of a PITA than a JavaScript style
VM, some people got all up in arms over the matter...).
in my own language/VM effort, I am mostly using a "hybridized"
typesystem, which basically resembles a statically typed system (most
variables have assigned types), but one can just as easily use dynamic
types (via the 'var' or 'variant' type).
the static types then serve one of several roles:
as optimization hints (allowing skipping type checking, or use native
machine types for variables);
as a means of performing static type checking (ideally, to detect if the
programmer made a big botch-up or typo early on, as a major drawback of
dynamic types is often that one may often accidentally end up typing
very brain-damaged code, but this will not be caught until much later,
such as at run-time, or until stumbled across).
currently, much of the present VM itself mostly uses dynamic types
internally though.
the merits of dynamic typing are:
generally, these are much easier to work with, and can be much more
expressive with a lot less implementation effort.
for example, with a mostly statically typed VM, then generally complex
semantics require a seemingly somewhat more complex implementation.
whereas, with dynamic types, beyond some the costs of implementing the
typesystem itself, the creation of complex mechanics or systems becomes
much easier (as nearly everything tends to decompose much more easily
into its fundamental parts).
the above is true even for seemingly "unrelated" things, like
implementing scoping semantics, or the FFI.
my last attempt to implement one of my style of scope systems (with the
following types of scopes: lexical, dynamic, object, package, toplevel,
and delegate), using plain static typing (mostly motivated by the idea
of VM performance) proved exceedingly painful.
the main alternative is simply to use a recursive lookup at runtime, and
maybe optimize subsequent lookups via a hash table.
as for type declarations, my personal preference is the creation of
simple C/Java/... style explicit/manifest typing.
a major reason here is that it makes it very obvious what type each
variable should be at any given point, and is generally easy to
understand and work with. this is in contrast to inferred type systems,
or a type-system like the one in Haskell, which personally I found
nearly impossible to understand or use.
and, really, there is an easy solution to most non-trivial cases:
just fall back to variant/dynamic types.
then, either the VM will use type-inference to optimize it, or will just
use dynamic type-checking if the VM can't figure it out either, or
(maybe) complain if the programmer is doing something which will
invariably result in a runtime type-check failure.
some people had accused me though of endorsing Java style "bondage type
systems", but generally this is not the case (partly this is because I
tend to use a lot more implicit type coercion as well, rather than the
more Java-like "must manually cast everything or get a type-error" style).
in most cases, where people will probably use static type declarations
is those cases where what the type should be are fairly obvious, and if
the type is not obvious, then don't declare it as such. seems obvious
enough?...
also I hold the belief that declaring things also works as a memory aid,
since otherwise a person may forget just what sort of types they put in
the variables, or worse yet, resort to using Hungarian-notation as a
memory aide.
and, in my case, the difference between "int x;" and "var x;" is not
exactly huge.
note: my present language isn't really functional though, as its design
is mostly influenced by JavaScript, ActionScript, Java, C#, and C.
less directly, other influences include Scheme, Self, and Erlang.
it has a few misc FPL features (lexical scope, first class
functions/methods, closures, tail-call optimization, ...) but this isn't
really its design focus.
it is also being used generally fairly tightly with C at the moment, as
its design features a fairly lightweight/transparent FFI, and is really
rather the opposite of the Java-style "make ones' own self-contained
island" strategy. I am apparently one of the few language designers
around who doesn't despise C.
but, there is a range as to how a lot of this can be implemented,
ranging from simpler options to more complex options.
originally, I implemented a Scheme VM (around 2001).
then later, a loosely JavaScript style language (around 2004).
then, just sort of continued on from there (decided to leave out a
summary of major project developments over the years).
things start out much simpler, but sadly don't always stay this way.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
