From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rusi Newsgroups: gmane.emacs.help Subject: Re: What does "lacks a prefix" mean? Date: Wed, 29 Jul 2015 19:49:40 -0700 (PDT) Message-ID: <57c992e4-38ba-48a5-8a25-3b1f69da96b1@googlegroups.com> References: <87fv492ko8.fsf@nl106-137-147.student.uu.se> (message from Emanuel Berg on Tue, 28 Jul 2015 02:24:55 +0200)> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1438224618 27089 80.91.229.3 (30 Jul 2015 02:50:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 02:50:18 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 30 04:50:18 2015 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 1ZKdvF-0006Xo-Qg for geh-help-gnu-emacs@m.gmane.org; Thu, 30 Jul 2015 04:50:17 +0200 Original-Received: from localhost ([::1]:37739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKdvF-0007h3-00 for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Jul 2015 22:50:17 -0400 X-Received: by 10.50.114.98 with SMTP id jf2mr941697igb.4.1438224580801; Wed, 29 Jul 2015 19:49:40 -0700 (PDT) X-Received: by 10.50.62.10 with SMTP id u10mr9371igr.12.1438224580785; Wed, 29 Jul 2015 19:49:40 -0700 (PDT) Original-Path: usenet.stanford.edu!f3no4715254igg.0!news-out.google.com!a16ni32704ign.0!nntp.google.com!pg9no5197771igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=117.195.44.133; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui Original-NNTP-Posting-Host: 117.195.44.133 User-Agent: G2/1.0 Injection-Date: Thu, 30 Jul 2015 02:49:40 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:213854 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:106139 Archived-At: On Thursday, July 30, 2015 at 7:10:31 AM UTC+5:30, Robert Thorpe wrote: > I won't talk about this much more because I think it's getting off-topic > for this list. > > Emanuel Berg writes: > > This is the exact same tiresome argument that has been > > put forward several times by now and the argument is > > still only logical within the framework that is "this > > is the way people do it". Yes: I know! > > I think that new languages should be written to do this the same way. I > think the convention for let and let* used in lisp is useful and I wish > it were more widespread. I'm not advocating it just because it's used > in old code. My comments about refactoring were separate. > > > In the other framework, where it is natural and > > *desired* that things depend on each other and happen > > stepwise - nothing to be afraid of and nothing that > > must be marked specifically as it is the natural order > > of things - in that framework it doesn't make > > sense (surprise, surprise!). > > Certainly there is no point in avoiding dependencies. They always occur > in programming. But, there's no need to make it look as through there > are dependencies where there aren't. There's no point removing tools > that allow use to differentiate one situation from the other easily. > That's the problem with the approach you're advocating. > > As I said earlier, let's suppose you're reading through function foo > looking for what happens to variable bar. > > Suppose you have:- > (let (..... > (foo (code ...))) > body) > > In this case there's no need to read through any of the other variables > defined in the let. > > Suppose instead you have: > (let* (..... > (foo (code ...))) > body) > > In that case the part I've labeled "code ..." could depend on the other > local variables. In the "let" case it's often possible to eval the > "code ..." part with C-x C-e. That's often not possible in the let* > case. In the let* case you have to read through the rest of the local > variable definitions. > > In elisp we have the following meanings: > * let - there aren't dependencies between these variables. > * let* - there are dependencies between these variables. > > In other languages that only support something like let* it means "there > may be dependencies between these variables, you have to read all the > code". Strongly concur! Dijkstra made a statement that is as alarming as it is true, viz. "It takes 100 years for an idea to go from inception to general acceptance" [dont have exact quote handy...] Some examples: Cantor-1880 to New-math-1970 (set theory) 200 years for Leibniz calculus notation to replace the clumsier Newton fluxion notation 600 years for Hindu-Arabic (decimal) numerals to replace roman 30 years between Wright brothers flight and first commercial flight In the same way Lisp was invented in 1960 For the next 40 years something vague and acdaemic called 'functional programming' was talked of but everyone only really had lisp as an example/exemplar. Finally it is only this century -- Haskell, Clojure, Scala -- that its become mainstream And finally its become abc of programming ACM curriculum 2013 pg 158 lists what EVERY programmer should know of FP. Seeing this discussion, I am coming to the conclusion that dependencies (and their minimization) is something that should be added there. To be fair the one thing I agree with Emanuel is that let* is a clumsy name. I'd like best a single let with a 'dependency-fence' So Say {e,f} depends on {c,d} depends on {a,b} (no inra-set dependency) The least-dependency way of writing would be (let ((a ..) (b ..)) (let ((c ..) (d ..)) (let ((e ..) (f ..)) body))) The sloppy way would be just one let* Neither is quite satisfactory -- one is over-dependent; the other is over-nested What I'd like (newlet ((a ..) (b ..) :fence (c ..) (d ..) :fence (e ..) (f ..)) body))) The keyword ":fence" can be improved :-)