Python syntax in Lisp and Scheme

[Daniel P. M. Silva]

Alex Martelli wrote:

>> What makes you think that macros have farther reaching effects in this
>> regard than functions? If I call a method and pass it a function object,
>> I also don't know what the method will do with it.
> 
> Of course not -- but it *cannot possibly* do what Gat's example of macros,
> WITH-MAINTAINED-CONDITION, is _claimed_ to do... "reason" about the
> condition it's meant to maintain (in his example a constraint on a
> variable named temperature), about the code over which it is to be
> maintained (three functions, or macros, that start, run, and stop the
> reactor), presumably infer from that code a model of how a reactor
> _works_, and rewrite the control code accordingly to ensure the condition
> _is_ in fact
> being maintained.  A callable passed as a parameter is _atomic_ -- you
> call it zero or more times with arguments, and/or you store it somewhere
> for later calling, *THAT'S IT*.  This is _trivially simple_ to document
> and reason about, compared to something that has the potential to dissect
> and alter the code it's passed to generate completely new one, most
> particularly when there are also implicit models of the physical world
> being
> inferred and reasoned about. 

Don't fear code that rewrites code.  Hell, if Psycho didn't exist (or if I
didn't think it did a good enough job), I'd sure like to say:

optimized:
  for x in range(2**63):
     pass

and let an 'optimized' special form rewrite my code into just "pass".

Or maybe I don't want to manually delete unexported functions in my modules:

clean_module exporting [a, b, d]
             and exporting_from {some.module:[fun1,fun2]}:
  import some.module
  def a(): pass
  def b(): pass
  def c(): pass
  def c(): pass

becomes:

import some.module
def a(): pass
def b(): pass
def c(): pass
def d(): pass
fun1 = some.module.fun1
fun2 = some.module.fun2
del c

Or cleanly write code using another module's namespace:

using_module some.module:
  print x, some.other.module.y
  using_module __main__:
    print x

In this case using_module inspects the code and rewrites it, leaving all
qualified identifiers untouched but modifying the global references, so the
example becomes:

print some.module.x, some.other.module.y
print x

Is that so dangerous?

> Without macros, when you see you want to design a special-purpose
> language you are motivated to put it OUTSIDE your primary language,
> and design it WITH its intended users, FOR its intended purposes, which
> may well have nothing at all to do with programming.  You parse it with a
> parser (trivial these days, trivial a quarter of a century ago), and off
> you
> go.

Hmm, but isn't every program a language?

http://blogs.gotdotnet.com/emeijer/PermaLink.aspx
ea13a4da-7421-44af-99e8-fc86de84e29c

Guy Steele agrees:

http://java.sun.com/features/2003/05/steele_qa.html

////////////////////
Q: You have written that "a language design can no longer be a thing. It
must be a pattern -- a pattern for growth - a pattern for growing the
pattern for defining the patterns that programmers can use for their real
work and their main goal." You said that a good programmer does not just
write programs, but engages in language design, building on the frame of a
base language. Could you elaborate on this?

A: Sure. Every time you write a new function, a new method, and give it a
name, you have invented a new word. If you write a library for a new
application area, then the methods in that library are a collection of
related words, a new technical jargon for that application domain. Look at
the Collection API: it adds new words (or new meanings for words) such as
"add", "remove", "contains", "Set", "List", and "LinkedHashSet". With that
API added to Java, you have a bigger vocabulary, a richer set of concepts
to work with.

Some concepts are more powerful, more general, more widely used than others
-- "liberty" and "mortgage" are more widely used than "belly button ring"
or "faucet wrench". But every new word, every new meaning, every new idiom
enriches the language. 
////////////////////////


But talk is cheap.  Maybe my next project should be a Python preprocessor :)

- Daniel