overriding built-ins

[dan]

Alex Martelli <aleax at aleax.it> wrote in message news:<Yfbeb.194368$R32.6272607 at news2.tin.it>...
... 
> Actually, I suspect it's pretty obvious to most respondents why one
> might want to create their own language, embedded inside Python but
> enriched and modified.  Guido himself is on record as having the far
> _dream_ of one day managing to let people define "application-specific
> languages" inside Python -- IF he can come up with a smart way to
> do it, one that won't destroy Python's simplicity and utter
> straightforwardness.  I suspect that "strong hint" reflects a deep
> distrust that any such silver bullet exists, and a deep fear that in
> the pursuit of such elusive goals Python's simplicity and philosophy
> of "there should be only one way to do it" might be destroyed.

Excellent response -- of course that is exactly what I would like to
do.  And I appreciate that Python's simplicity and uniformity can be
seen as pluses.  Perhaps this is a request for a different type of
meta-language, and shouldn't be shoe-horned into Python.  I'll look at
Dylan and some of the other stuff you mention.

Of course Python would be a great language in which to develop a
parser/interpreter/compiler for such a language.  Perhaps it would
make sense to develop a new syntax that shares the Python bytecodes
and import methodology, so you could start with a large library of
support modules and such.

However that brings up an interesting issue: the plethora of new
languages with bytecode interpreters (Java, Python, C#) are starting
to concern me.  It seems like there could be a place for some sort of
standardized, low-level bytecode syntax, so that work on things like
JIC compilation can occur independently of high-level changes and
alternatives to source syntax.

> 
> There exist languages which have very powerful macro systems.  Common
> Lisp is the canonical example, but if you prefer syntax that is rather
> more Python-like you might look into Dylan instead.  Lisp and Dylan
> also share the powerful concept of "multiple dispatch", a way to do
> OO that is as superior to C++'s or Python's as the latter is superior
> to that of _purely_ single-inheritance languages [ones without even
> such helpers as Java interfaces or Ruby mixins].  Some languages do
> not really have such power, but can still come close -- e.g., in
> Smalltalk, "IF" is not a _statement_, just a method to which you pass
> code blocks, so there is little impediment to piling up "more of the
> same" to make your own application-specific language inside it; to
> a lesser extent, you can do somewhat similar things in Ruby -- and
> Perl has its own inimitable way (google for "Lingua Latina Perligata"
> if you're REALLY TRULY into such... ahem... divertissements:-).
> 
> A widespread feeling around the Python community is that Python's own
> uniqueness is SIMPLICITY.  Python is straightforward and thereby most
> productive because it DOESN'T EVEN TRY to let you bend its syntax in
> strange ways (in that, it's closest to Java -- i.e., it even lacks the
> puny "preprocessor" that C and C++ come with).  If you want an
> application-specific language, you design and implement it in the good
> old time-trusted way -- lexx and yacc, or their Python equivalents (of
> which there are quite a few) -- Python stays Python, your language
> is your own, and everybody (hopefully) is happy...;-).
> 
> 
> Alex