Python syntax in Lisp and Scheme

[Pascal Costanza]

Andrew Dalke wrote:

> Me:
> 
>>>My continued response is that [Lisp is] not optimal for all
>>>domains.
> 
> 
> Pascal Costanza:
> 
>>Yes, we disagree in this regard.
> 
> 
> *Shrug*  The existence of awk/perl (great for 1-liners on the
> unix command-line) or PHP (for simple web programming) or
> Mathematica (for symbolic math) is strong enough evidence for
> me to continue to disagree.

Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

> Pascal Costanza:
> 
>>However, you have mentioned that someone has implemented an quantum
>>extension for Perl - and if that's possible then you can safely bet that
>>it's also possible in pure Lisp.
> 
> 
> The fact that all computing can be programmed in Turing Machine
> Language doesn't mean TML is the optimal programming language.

Right.

> The fact that there is perl code for emulating *some* quantum
> programming means that Lisp can handle that subset.  It doesn't mean
> that people have fully explored even in Lisp what it means to do all
> of quantum computing.

...and you expect me to have fully explored it? If this topic is so 
interesting to you, why don't you just grab a Common Lisp environment 
and start working on it? ;)

I am pretty sure you can get very far.

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

Sure, but it's much more work.

> 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)

Sure, but inconvenient.

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

Sure, there is no way around that. But you can reduce the tediousness in 
the long run.

I believe it is an accepted fact that uniformity in GUI design is a good 
thing because users don't need to learn arbitrarily different ways of 
using different programs. You only need different ways of interaction 
when a program actually requires it for its specific domain.

That's pretty much the same when you program in Lisp. It takes some time 
to get used to s-expressions, but afterwards you forget about syntax and 
focus on the real problems.

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

Sure, but is it worth it?

>>I am not so sure whether this is a good idea. Personally, I prefer not
>>to think about syntax anymore. It's boring. But that's maybe just me.
> 
> 
> wave equation vs. matrix approach
> Newtownian mechanics or Lagrangian
> measure theory or non-standard analysis
> recursive algorithms vs. iterative ones
> travelling salesman vs. maximum clique detection
> 
> Each is a pair of different but equivalent ways of viewing the same
> problem.  Is the difference just syntax?

Probably not. This question is too general though for my taste.

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

Convenience is what matters. If you are able to conveniently express 
solutions for hard problems, then you win. In the long run, it doesn't 
matter much how things behave in the background, only at first.

Or do you really still care about how sorting algorithms work? No, you 
look for an API that has some useful sorting functions, and then you 
just use them.

Macros are just another tool to create new abstractions that allow you 
to conveniently express solutions for hard problems.

It seems to me that in Python, just as in most other languages, you 
always have to be aware that you are dealing with classes and objects. 
Why should one care? Why does the language force me to see that when it 
really doesn't contribute to the solution?

That's why lambda expressions are sometimes also not quite right. When I 
want to execute some code in some context, why should I care about it 
being wrapped in a lambda expression to make it work? How does that 
contribute to the problem I am trying to tackle?

I want to think in terms of the problem I need to solve. Lisp is one of 
the very rare languages that doesn't force me to think in terms of its 
native language constructs.

>>If it's only a syntactical issue, then it's a safe bet that you can add
>>that to the language. Syntax is boring.
> 
> Umm... Sure.  C++ can be expressed as a parse tree, and that
> parse tree converted to an s-exp, which can be claimed to be
> a Lisp; perhaps with the right set of macros.

That's computational equivalence, and that's not interesting.

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

If it's a good Lisp library I would expect it to work like this:

(with-allocation-from :shared-memory
   ...)

;)

Any more questions?

>>Sounds like a possible application for the CLOS MOP.
> 
> 
> Or any other language's MOP.

Sure.

>>Seriously, I haven't invented this analogy, I have just tried to answer
>>a rhetorical question by Alex in a non-obvious way. Basically, I think
>>the analogy is flawed.
> 
> 
> Then the right solution is to claim the analogy is wrong, not
> go along with it as you did.  ;)

Thanks for your kind words. ;)


Pascal