Pluggable type sytems

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:gl0ohe$1gda$1 at digitalmars.com...
>I think pluggable type systems will become more common in the following 
>years (see also the optional annotations of Python3 that are designed for 
>that too). This is more or less related:
>
> http://bartoszmilewski.wordpress.com/2009/01/18/java-pluggable-types/
>
> (but nonnullability is so basic that it's better inside the language, and 
> not left out to a plug-in type system).
>
> Bye,
> bearophile

Interesting article. Sounds a lot like D2 but with that flow-analysis 
nice-ity, and @PolyNull (which has been proposed here...often). Although I 
wonder...maybe @PolyNull should be the default (wherever applicable) instead 
of @Nullable or @NonNull? (Or maybe I'm overlooking some obvious problem 
with that.)

I see pluggable type sytems as potentially being a specific form of a more 
general thing I've been observing an increasing need for/trend towards: 
customizable languages.

Ex: A language that doesn't say "Semicolons mark end-of-statement" or 
"Newline marks end-of-statement and lines can be split with a backslash", 
but provides both as mutually-exclusive programmer-selectable options. Or a 
choice of C-style curly-braces vs Python-style indentation. Etc. (Side note: 
This stuff could really cut down on religious language debates. Not 
eliminate, of course, but reduce.)

Also, a tool could then be used to translate code between the various 
options, maybe even integrated into the IDE, so that people working on 
multi-person projects could each set up their own environments and use their 
own "customized language" even while working on the same line of code. The 
only project-wide standard would be what settings are used for checked-in 
code, just like tab/space settings and EOL markers (but ideally performed 
automatically (and reliably) by the check-in/check-out process). Eventually 
this might even be generalizable to the point where most languages can be 
reduced to nothing more than a collection of language settings. Which I 
think is the direction we appear to be headed anyway, since it seems like 
everyone and their grandmother is designing their own language (or two) 
these days, and many of these languages are more-or-less "just like language 
X, but with A, B and C changed to be more like language Y."

Obviously this is all much easier said than done, but it's something I've 
been thinking a lot about lately, and I think may be worth exploring.