From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: becoming a lisp developer Date: Wed, 27 Jun 2012 18:09:36 +0200 Organization: Informatimago Message-ID: <87ehp0pwhr.fsf@kuiper.lan.informatimago.com> References: <87bokbb4zw.fsf@gnu.org> <4FE67DF4.1010903@mousecar.com> <8262af46dv.fsf@gmail.com> <87wr2uqms4.fsf_-_@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1340813421 29561 80.91.229.3 (27 Jun 2012 16:10:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2012 16:10:21 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jun 27 18:10:18 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sjuom-00027c-SU for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Jun 2012 18:10:13 +0200 Original-Received: from localhost ([::1]:60496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sjuom-0003Gn-N0 for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Jun 2012 12:10:12 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 185 Original-X-Trace: individual.net m8Er3uUlCmxwrwD4a+fSmQ3+/zfYf/f5IokFJ9KQ6UIibdA06f5yJQLIU6sqU2ZNJr Cancel-Lock: sha1:N2Q3YTNmYTVlNDBmODg0ZjNhYmU0NDI4ZTZhNmZmY2ZhYjJmMTZhZA== sha1:gTsaC/U4Ph8w9VySuQMDSAfwy8s= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:193126 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:85521 Archived-At: ken 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 {}.