Re: becoming a lisp developer

[PJ Weisberg]

On Wed, Jun 27, 2012 at 8:36 AM, ken <gebser@mousecar.com> wrote:
>
>
> On 06/26/2012 08:29 AM Pascal J. Bourguignon wrote:
...
>>     (let ((a 1)
>>           (b 1111111112)
>>           (c 1111111113))
>>       (setf a (+ b c)))
>>
>> in lisp.  But the syntac is irrelevant.  You can easily write a
>> pre-processor to convert one into the other.
>> (See for example: http://paste.lisp.org/display/25134)
>
>
> Yes, the latter sort of expression, where the operand is at the beginning of
> the expression, is called reverse-polish.  There was at least one hand-held
> scientific calculator which came out in the mid-1970s which used this
> notation.  Though it took only a few seconds to adjust one's thinking to
> this syntax, that sort of syntax on such devices pretty much died out
> (AFAIA), people, not surprisingly, preferring a notation which conformed
> more closely to natural language.  Conforming to natural language has long
> been a goal of cyber-language developers, for understandable reasons: less
> attention to syntactic anomolies allows for more attention to logic and so
> too then probably better applications.
>
> But, yes, just this once instance is trivial.  Back in the 1980s I wrote an
> expression parser (in C).  I remember being quite surprised how little code
> it required, just ten or twelve lines IIRC.  It was so pleasing in its
> terseness and elegance that I assigned the same task to my college students
> to exercise our discussion on recursion.  (To make it a homework assignment
> they could do in a week, their C code needn't perform error checking, but
> rather assume that all expressions their programs would read in were well
> formed, nor would they need consider critically heavy burdens on the stack
> due to very deep nesting.)  This function/program was intended to parse
> C-style syntax (e.g., "(2 + (5 * 3))"), but it would be trivial to alter it
> to parse reverse-polish, or vice versa-- which offers up the question, why
> require text to be parsed to conform to one syntactical ruleset as opposed
> to another?  The code for the parser is nigh identical... so why not cut
> developers a small break by conforming more closely to natural language?

a = b + c * d - e

What happens first?  Do you go left to right, assign b to a, add c to
the result, multiply by d, and subtract e?  No, in fact the assignment
happens last, for mostly obvious reasons, and the multiplication
happens first, because of some arbitrary convention.

(setf a (- (+ b
              (* c d))
           e))

It's different from natural language, but it's completely unambiguous,
and in fact it's structured just like the tree you would have parsed
the C-style expression into.  Plus, it's exactly like the list data
structure, which makes it easy for code to write code at runtime.
Macros.  You can define your own syntax.  If you really wanted to, you
could write a macro, call it `cparse', that would transform

(cparse
    a = b + c * d - e)

into

(setf a (- (+ b
              (* c d))
           e))

Load your macro at the beginning of the file, and you can use C-style
expressions all you want.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.