Python syntax in Lisp and Scheme

[Daniel P. M. Silva]

Greg Ewing (using news.cis.dfn.de) wrote:

> Daniel P. M. Silva wrote:
> 
>> Haven't some people implemented an entire class system as one huge macro?
> 
> YES! Been there, done that -- about 3 or 4 times, actually.
> I went through a bit of a phase where writing OO implementations
> for Scheme was one of my principal hobbies. :-)
> 

Nice! I was alluding to MzScheme's class.ss but I guess that's a fun hobby
to have. :)  Do you have your class systems available anywhere to download? 
I would be especially interested in them if they allow multiple
inheritance, run-time pillaging of class contracts, and explicit "this"
arguments to methods...


> By the way, Scheme was my Favourite Cool Language for quite
> a while. Then I discovered Python, and while I still appreciate
> all the things about Scheme that I appreciated then, I wouldn't
> want to go back to using it on a regular basis now. So it's not
> a given that any person who likes Scheme must inevitably dislike
> Python!
> 
> I do "get" macros, and I appreciate having them available in
> languages like Scheme, where they seem to fit naturally. But
> I can't say I've missed them in Python, probably because Python
> provides enough facilities of its own for constructing kinds of
> mini-languages (keyword arguments, operator overloading,
> iterators, etc.) to satisfy my needs without having to resort
> to macros.

You still can't add new binding constructs or safe parameterizations like a
with_directory form:

with_directory("/tmp", do_something())

Where do_something() would be evaluated with the current directory set to "
tmp" and the old pwd would be restored afterward (even in the event of an
exception).

Last year -- I think at LL2 -- someone showed how they added some sort of
'using "filename":' form to Python... by hacking the interpreter.

> And I do regard macros as something that one "resorts" to, for
> all the reasons discussed here, plus another fairly major one
> that nobody has mentioned: Unless both the macro system and
> the macros written in it are *extremely* well designed, error
> reporting in the presence of macros of any complexity tends to
> be abysmal, because errors get reported in terms of the expansion
> of the macro rather than what the programmer originally wrote.
 
I've yet to encounter this problem in the standard library included with my
Scheme implementation of choice, but ok.

> ALL macro systems of any kind that I have ever used have suffered
> from this - cpp, C++ templates, Lisp/Scheme macros, TeX,
> you name it. I'd hate to see Python grow the same problems.
> 

Some people use Python's hooks to create little languages inside Python (eg.
to change the meaning of instantiation), which are not free of problems:

class Object(object):
  def __init__(this, *args, **kwargs):
    this.rest = args
    this.keys = kwargs

def new_obj_id(count=[0]):
   count[0] = count[0] + 1
   return count[0]

def tag_obj(obj, id):
   obj.object_id = id
   return obj
   
def obj_id(obj): return obj.object_id
   
type.__setattr__(Object, "__new__", staticmethod(lambda type, *args:
tag_obj(object.__new__(type), new_obj_id())))


Great, now all object instantiations (of our own Object class) will also tag
new objects with an ID:

obj = Object()
print "id: ", obj_id(obj)
print "another id: ", obj_id(Object())

Which gives you 1 and then 2.  Hurrah.
Have you caught the bug yet?

# forgot to check for this case...
print Object(foo="bar")

This is of course illegal and I get the following error message:

Traceback (most recent call last):
  File "n.py", line 27, in ?
    print Object(foo="bar").rest
TypeError: <lambda>() got an unexpected keyword argument 'foo'

Hmm...