Python syntax in Lisp and Scheme

[Coby Beck]

"Andrew Dalke" <adalke at mindspring.com> wrote in message
news:rr0ib.7732$dn6.1011 at newsread4.news.pas.earthlink.net...
> > Furthermore, it has been suggested more than once that a valid
> > working model is that a good Lisp programmer can provide a
> > domain-specific language for the non-professional programmer. It's very
> > likely that a DSL matches better the needs of the user than some
> > restricted general-purpose language.
>
> Another *shrug*  And a good C programmer can provide a
> domain-specific language for the non-professional programmer.

Now you're obviously just trying to be difficult!  Reminds me of a thread a
while back where someone argued that C could so dynamically compile code and
posted an example that wrote a hello-world in a string, wrote it to a file,
called gcc on it and then system-called the .so file!

Or is there something else you mean besides design the language, implement a
parser, write a compiler?  Yes you can do that in C.

> Any good Python programmer could make an implementation
> of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like
>
> import lisp
> def spam(distance):
>     """(time_to_fall 9.8 distance)"""
> spam = lisp.convert(spam)
>
> def time_to_fall(g, distance):
>   print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"
>
> print spam(10)

I don't get your point at all.  At least not how it possibly applies to a
discussion of using macros to create domain specific languages.

> > Ah, but then you need to constantly change the syntax and need to
> > remember the idiosyncrasies of several languages.
>
> Yup.  Just like remembering what macros do for different domains.

This is just the same memorizing that applies to application specific
functions, classes etc.  Not at all like memorizing @ % $ ; { } & etc.
Really, this argument is based on pure FUD.  It is not the norm to use
macros to do anything at all obfuscating.  One of the most controversial
macros has got to be loop, and it is ridiculed for something close to what
you seem to be arguing: it creates a very different and unlisp-like
sublanguage.

But even that, it is not:
(loop ^x %% foo==bar -> baz)

it is:
(loop for x from foo upto bar finally return baz)

Not hard to memorize what FROM and UPTO mean.

> I firmly believe people can in general easily handle much more
> complicated syntax than Lisp has.  There's plenty of room to
> spare in people's heads for this subject.

My head prefers to be full of more important things, that's all.

>>>Lispniks are driven by the assumption that there is always the
>>>unexpected. No matter what happens, it's a safe bet that you can make
>>>Lisp behave the way you want it to behave, even in the unlikely event
>>>that something happens that no language designer has ever thought of
>>>before.

>>> Ahh, but that assumes that behaviour is the only important thing
>>> in a language.

>> No.
>
> Thank you for your elaboration.  You say the driving force is the
> ability to handle unexpected events.  I assumed that means you need
> new styles of behaviour.

Just have another look.  He did not even say behaviour is the most
important, let alone the only important thing.

But in the global trade of language design (because remember, everything is
a trade-off) behaviour *is* more important than syntax *if* your goals are
primarily technical rather than social.

Nothing wrong with social goals, but you should not be naive when it comes
to considering what you have traded in for personal notions of ease of
learning.

> Still doesn't answer my question on how nicely Lisp handles
> the 'unexpected' need of allocating objects from different
> memory arenas.

I don't think this is a reasonable discussion point.  You are presumably
trying to show us an example of a problem lisp is not flexible enough to
handle, but you have not presented a problem to solve, you have presented a
solution to implement.  These are entirely different things.

-- 
Coby Beck
(remove #\Space "coby 101 @ big pond . com")