Python syntax in Lisp and Scheme

Matthias no at spam.pls
Tue Oct 7 08:50:04 EDT 2003


bokr at oz.net (Bengt Richter) writes:

> On 06 Oct 2003 12:54:30 +0200, Matthias <no at spam.pls> wrote:
> >1.) Inventing new control structures (implement lazy data structures,
> You mean like an object olazy with olazy.x and olazy.y, where x might
> be an integer 123 and y might be the text of the latest bug python report
> on sourceforge? Not so hard with properties (you'd proabably want to cache
> the latest for y and not re-check for some reasonable interval, but that
> doesn't change client code (unless you later decide you want the value to
> be a tuple of (timestamp, text), etc.)

Actually, I meant more lazy-like-lazy-in-Haskell.  Infinite data
structures and such.  "primes" being a list representing _all_ prime
numbers for instance.  You can build this as soon as you have closures
but making the construction easy to use for the application programmer
might be a challenge without macros.  But I don't know what
"properties" are in Python, possibly they are built for exactly that.

> >  implement declarative control structures, etc.)  
> You mean like case or such? 

No. I was thinking about Prolog and such.  Or nondeterministic
programming.  Or multimethod dispatch.

> >2.) Serve as abbreviation of repeating code.  Ever used a code
> >  generator?  Discovered there was a bug in the generated code?  Had
> >  to fix it at a zillion places?
> >  => Macros serve as extremely flexible code generators, and there
> >  is only one place to fix a bug.
> >  => Many Design Patterns can be implemented as macros, allowing you
> >  to have them explicitly in your code.  This makes for better 
> >  documentation and maintainability.
> You can generate code many ways in Python. What use case are you thinking of?

I was not talking about generating code /in/ Python but generating
code /for/ Python /within/ it.  For the Design Pattern use case take a
look at http://norvig.com/design-patterns/

> >3.) Invent pleasant syntax in limited domains.
> >  => Some people don't like Lips' prefix syntax.  It's changeable if you 
> >  have macros.
> >  => This feature can also be misused.
> You can do this also.

You can change Python's syntax?  Easily?

> >4.) Do computations at compile time instead of at runtime.
> >  => Have heard about template metaprogramming in the C++ world?
> >  People do a lot to get fast performance by shifting computation 
> >  to compile time.  Macros do this effortlessly.
> This also, but Python has so many possible compile times ;-)

I'm not sure I understand.

> Python is pretty sharp ;-)
> I think we need some realistic use cases for your "specific" [categories of]
> examples in order to compare how problems would be approached.

Well, if you don't want to learn about syntactic abstraction you'll
probably never miss it during your programming.  Just keep in mind
that before oo-abstraction became fashionable people didn't miss OOP
either.




More information about the Python-list mailing list