unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: John Mastro <john.b.mastro@gmail.com>
To: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: Re: beginnerquestion (nconc)
Date: Wed, 22 Mar 2017 12:00:45 -0700	[thread overview]
Message-ID: <CAOj2CQT-FcV3awu1SVrZGRLgeWQRAxtagaXywAqBF6A94ary1Q@mail.gmail.com> (raw)
In-Reply-To: <87mvcef8x1.fsf@jupiter.lan>

Stefan Huchler <stefan.huchler@mail.de> wrote:
> I would even think about seq-position to get the id but that seems to be
> not in 24.x version of seq.el

From an efficiency standpoint, that also means scanning the list over
and over. It would only "really" matter if the list got largish, but
it's easy enough to avoid. Another option would be to use something like
`-map-indexed' from the `dash' library. (Incidentally, the efficiency
concern also applies to using `dotimes' plus `elt' to iterate over a
linked list).

> your solution looks interesting, too. first you also use at least 1
> cl-... function I dont know what I have to thinb about that. isnt clisp
> supposed to be ugly or bad? still everwhere you get suggestions about
> it.

People have a few different concerns with `cl' and `cl-lib':
  1. `cl' introduces lots of non-namespaced names
  2. Some people find the "cl"-prefixed names in `cl-lib' to be
     aesthetically unappealing
  3. Some people find the programming style associated with Common
     Lisp to be aesthetically unappealing

I avoid `cl' for the first reason above but the second and third don't
trouble me much.

> often the non (cl-) prefixed stuff seem to be wrappers or renamed
> commonlisp functions, too?

Yes, the idea of both `cl' and `cl-lib' is to provide Common Lisp-like
functions that aren't present in Emacs Lisp's standard library.

> also you used one time let and one time let* only a mistake or has that
> any meaning?
>
> I thought let* is for most cases better?

There is a reasonable argument to always use `let*', but my personal
habit is to use `let' by default and only use `let*' when the difference
between them is significant.

> Wow and you use let after setq I never thought about that, but of course
> it should/will work.

Yes, either way works.

> I am much about learning by doing, and to learn on concrete use cases /
> needs. seems to kind of work. Meanwhile people (most important me) can
> use the badly programmed but good usable kodi-remote if they want :)

That's a good way to learn - it's hard to beat practice and experience.

> yes I also used much python in the past. Well its more a emacs-lisp
> specific thing right? I mean common-lisp has append. its not good for
> performance critical stuff and huge amounts of data... which would be
> pretty irrelevant for my usecase.

The `push' / `nreverse' idiom is found in both Common Lisp and Scheme,
and probably other Lisps too, though I don't have experience with most
of the others.

Common Lisp, Scheme, and Emacs Lisp all have `append', but it's not the
same as Python's `list.append', because the underlying data structure is
different.

Lists in CL/Scheme/Elisp are singly-linked lists built from cons cells,
which means it's inherently inefficient to append to the end. That's the
ultimate reason for the `push' / `nreverse' style: you append at the
front (where it's efficient to do so, but results in the elements being
in reverse order), then reverse the list to get it back in the desired
order.

> But ok, if it leads me to better coding style, so be it.
>
> I did not use map and lambda very much in the past. But should start
> doing that more :)

Like any style or approach, it has its limits, but I think it's quite
nice for many common uses.

        John



  parent reply	other threads:[~2017-03-22 19:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  5:58 beginnerquestion (nconc) Stefan Huchler
2017-03-17  7:33 ` Thien-Thi Nguyen
2017-03-17  8:52   ` Thien-Thi Nguyen
2017-03-17 14:19   ` Stefan Huchler
2017-03-17 14:48     ` tomas
2017-03-17 14:42 ` Yuri Khan
2017-03-17 16:59   ` Stefan Huchler
2017-03-17 17:20     ` Drew Adams
2017-03-17 17:32       ` Drew Adams
2017-03-18  2:15     ` Stefan Monnier
2017-03-21 16:47       ` Stefan Huchler
2017-03-21 16:59       ` Stefan Huchler
2017-03-21 20:14         ` John Mastro
2017-03-22  0:32           ` Stefan Huchler
2017-03-22 15:02             ` Michael Heerdegen
2017-03-22 19:00             ` John Mastro [this message]
2017-03-21 11:05     ` Michael Heerdegen

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOj2CQT-FcV3awu1SVrZGRLgeWQRAxtagaXywAqBF6A94ary1Q@mail.gmail.com \
    --to=john.b.mastro@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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).