Python syntax in Lisp and Scheme

[Pascal Costanza]

Alex Martelli wrote:

> Pascal Costanza 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.

...but such a macro _exclusively_ reasons about the code that is passed 
to it. So the effects are completely localized. You don't do any damage 
to the rest of the language because of such a macro.

Of course, such a macro needs to be well-defined and well-documented. 
But that's the case for any code, isn't it?

>>(Are you also considering to add DBC to Python? I would expect that by
>>now given your reply above.)
[...]

> Guido has already declared that ONE concept of interfaces (or 
> typeclasses, or protocols, etc) _will_ eventually get into Python -- but
> _which one_, it's far too early to tell.  I would be surprised if whichever
> version does make it into Python doesn't let you express contracts.

OK, I think I understand the Python mindset a little bit better. Thanks.

>>Can you give an example for the presumably dangerous things macros
>>supposedly can do that you have in mind?
> 
> 
> I have given this repeatedly: they can (and in fact have) tempt programmers
> using a language which offers macros (various versions of lisp) to, e.g.,
> "embed a domain specific language" right into the general purpose language.
> I.e., exactly the use which is claimed to be the ADVANTAGE of macros.  I
> have seen computer scientists with modest grasp of integrated circuit design
> embed half-baked hardware-description languages (_at least_ one different
> incompatible such sublanguage per lab) right into the general-purpose
> language, and tout it at conferences as the holy grail

That's all? And you really think this has anything to do with macros?

Yes, macros allow you to write bad programs - but this is true for any 
language construct.

Your proposed model means that for each DSL you might need you also need 
to implement it as a separate language. Well, this has also been done 
over and over again, with varying degrees of success. You can probably 
name several badly designed "out-bedded" little languages. Does this 
mean that your propose sucks as well? It doesn't seem to guarantee good 
little languages, does it?

In reality, in both approaches we can just find both badly and well 
designed DSLs.

Bad languages, no matter whether embedded or "out-bedded", exist not 
because of the technology that is being used to implement them but 
because of the fact that humans can fail when they undertake something.

You surely can name some badly desigend libraries, even for Python. Does 
this mean that the respective languages suck? That the very concept of 
libraries suck?

Here is a one of my favorite quotes, by Guy Steele and Gerald Sussman: 
"No amount of language design can _force_ a programmer to write clear 
programs. If the programmer's conception of the problem is badly 
organized, then his program will also be badly organized. The extent to 
which a programming language can help a programmer to organize his 
problem is precisely the extent to which it provides features 
appropriate to his problem domain. The emphasis should not be on 
eliminating “bad” language constructs, but on discovering or inventing 
helpful ones." (from "Lambda - The Ultimate Imperative")


Pythonistas seem to think otherwise wrt language design that can force 
programmers to write clear programs. If you think that this is a good 
summary of the Python mindset then we can stop the discussion. I simply 
don't buy into such a mindset.


Pascal