From: Rusi <rustompmody@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: What does "lacks a prefix" mean?
Date: Wed, 29 Jul 2015 19:49:40 -0700 (PDT) [thread overview]
Message-ID: <57c992e4-38ba-48a5-8a25-3b1f69da96b1@googlegroups.com> (raw)
In-Reply-To: <mailman.7638.1438220428.904.help-gnu-emacs@gnu.org>
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 :-)
next prev parent reply other threads:[~2015-07-30 2:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 16:32 What does "lacks a prefix" mean? BobD
2015-07-08 16:45 ` Barry Margolin
2015-07-08 16:59 ` Vaidheeswaran C
2015-07-08 17:10 ` Vaidheeswaran C
2015-07-08 18:17 ` BobD
2015-07-08 18:21 ` Pascal J. Bourguignon
2015-07-08 18:45 ` BobD
2015-07-08 23:24 ` Emanuel Berg
2015-07-09 15:23 ` Filipp Gunbin
2015-07-09 22:32 ` Emanuel Berg
2015-07-10 17:04 ` Stefan Monnier
2015-07-11 22:42 ` Emanuel Berg
[not found] ` <mailman.6748.1436654668.904.help-gnu-emacs@gnu.org>
2015-07-11 23:58 ` Barry Margolin
2015-07-13 12:26 ` Filipp Gunbin
[not found] ` <mailman.6685.1436547891.904.help-gnu-emacs@gnu.org>
2015-07-10 18:27 ` Barry Margolin
[not found] ` <mailman.6612.1436455429.904.help-gnu-emacs@gnu.org>
2015-07-09 23:27 ` Barry Margolin
[not found] ` <mailman.6643.1436488423.904.help-gnu-emacs@gnu.org>
2015-07-10 0:49 ` Pascal J. Bourguignon
2015-07-10 5:04 ` Drew Adams
2015-07-10 14:42 ` Barry Margolin
[not found] ` <<barmar-2BC802.10421910072015@88-209-239-213.giganet.hu>
2015-07-10 14:53 ` Drew Adams
[not found] ` <<barmar-500871.19271109072015@88-209-239-213.giganet.hu>
2015-07-10 0:33 ` Drew Adams
[not found] ` <mailman.6590.1436397914.904.help-gnu-emacs@gnu.org>
2015-07-09 14:01 ` Barry Margolin
2015-07-09 14:10 ` Rusi
2015-07-09 22:27 ` Emanuel Berg
[not found] ` <mailman.6639.1436481016.904.help-gnu-emacs@gnu.org>
2015-07-10 3:10 ` Rusi
2015-07-10 16:00 ` Emanuel Berg
2015-07-09 22:19 ` Emanuel Berg
[not found] ` <<barmar-F23189.10014209072015@88-209-239-213.giganet.hu>
2015-07-09 15:33 ` Drew Adams
2015-07-12 1:47 ` Emanuel Berg
2015-07-12 16:59 ` Drew Adams
2015-07-13 0:46 ` Emanuel Berg
2015-07-13 7:26 ` Yuri Khan
2015-07-13 23:47 ` Emanuel Berg
2015-07-14 6:23 ` Yuri Khan
2015-07-14 21:58 ` Emanuel Berg
2015-07-19 0:59 ` Robert Thorpe
2015-07-28 0:24 ` Emanuel Berg
2015-07-30 1:40 ` Robert Thorpe
[not found] ` <mailman.7638.1438220428.904.help-gnu-emacs@gnu.org>
2015-07-30 2:49 ` Rusi [this message]
2015-07-30 2:53 ` Rusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57c992e4-38ba-48a5-8a25-3b1f69da96b1@googlegroups.com \
--to=rustompmody@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.