Re: becoming a lisp developer

[Pascal J. Bourguignon]

ken <gebser@mousecar.com> writes:

> Yes, the latter sort of expression, where the operand is at the
> beginning of the expression, is called reverse-polish.  

Of course not.

> There was at
> least one hand-held scientific calculator which came out in the
> mid-1970s which used this notation.  

No, it used the Reverse Polish Notation ("RPN"), in which, the arguments
are first, and the operators are suffixed.

    12  45  +  --> 57

In Lisp, we use the fully parenthesized Polish Notation!

   (+ 12 45)    --> 57

The reasons we use parentheses is that:

1- it allows us to deal easily with variadic operations

      (+ 1 2 3 4)    ; lisp

      + + + 1 2 3 4  ; Polish

2- it allows us to deal with fixed-arity operations WITHOUT HAVING TO
   KNOW what their arity is.  This is important to be able to write
   macros easily.


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

Not at all.  Discriminating user of hand-held calculators still prefer
HP calculators for its RPN.
http://welcome.hp.com/country/us/en/prodserv/calculator.html


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

And this has been a failure in all case, because natural language is by
nature ambiguous, which is a deal breaker for algorithmics and
programming languages.


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

That's the wrong question (see above).  The right question would be, why
the editors wouldn't present the same Sexp-based representation of
program sources, in the syntax the user prefers.

In emacs you could easily unparse sexp files into any kind of syntax,
and parse it again upon saving to write back sexps.

That's exactly what lisp does, but lisp programmers (in general) just
like to write directly the sexps, instead of dealing with artificial and
useless syntax layer.


>> What's more important to understand the meaning of those programs, is
>> their semantics.
>>
>> In a 32-bit C, (ie. a C where int has a 32-bit two-complement
>> representation), the result would be -2072745071 with some compiler.
>> (In some other C compilers, it could signal a run-time error, the C
>> standard doesn't specify what must happen).
>>
>> In a 64-bit C, (ie. a C where int has a 64-bit two-complement
>> representation), the result would be 2222222225.
>>
>> In a 32-bit emacs, which has no bignums and where fixnums are limited to
>> 29-bit two-complement the result would be 74738577.
>>
>> In a 64-bit emacs, which has still no bignums, but where fixnums are
>> limited to 61-bit two-complement, the result would be 2222222225.
>>
>> In a Common Lisp implementation, which therefore has bignums, whatever
>> the size of the fixnums, the results would be 2222222225.
>>
>> ....
>
> Thank goodness such concerns are seldom central to applications
> developers, systems developers having for the most part isolated app
> developers from hardware vagaries (as von Neuman intended).  This
> however has long been an area requiring more co-operation between
> hardware and systems folks.

You mean, to Common Lisp application developers.
But not to

1- emacs application developers,

2- C or C++ application developers,

3- any other language that doesn't provide bignums,

4- any programming language (included Common Lisp!) that doesn't provide
   real Real numbers (eg. using the reallib library). 
   http://www.daimi.au.dk/~barnie/RealPractical.pdf


Otherwise, given that there's still no cl-reallib, and that most other
programming language don't have bignums for integers, then it's
obviously a central concern for any application developers!  Just try to
write a program to compute the US debt!  Or the next Fed quantitative easing!




>> The semantical differences are therefore:
>>
>> In Common Lisp, + for integers implements the mathematical integer
>> addition (up to the available memory).
>>
>> In emacs lisp, + for integers implements the addition modulo 29 or 61
>> depending on the machine word size.
>>
>> In C, + for int may implement the addition modulo 32 or 64, or something
>> else (including signaling a run-time error, or a compilation-time error).
>
> Yes, if these were the only barriers to understanding, for all
> practical purposes, there effectively be no barriers at all.

That wasn't my point.  My point was that since even for the simpliest
operation there are big semantics difference, you can expect that
learning a language in a different category of language be something
that either:

1- is hard, or

2- require that you empty your mind and start from a blank slate.




>> The conclusion is that to learn a programming language in a different
>> category of what you know already, you must forget what you know, and
>> just learn it from the beginning.
>
> I wouldn't say, "forget what you know" but rather "don't make
> assumptions about one language based solely on knowledge from another
> language."  

You may express it like that.  But it looks like for most people it
would be easier to forget than to keep knowledge about different things
separate.

> As you pointed out above, while there are many differences, there are
> also many similarities.  We don't really want to forget and then have
> to relearn the similarities.

    It is practically impossible to teach good programming to students
    that have had a prior exposure to BASIC: as potential programmers
    they are mentally mutilated beyond hope of regeneration. 

http://www.cs.virginia.edu/~cs655/readings/ewd498.html


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.