all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: plists, alists, and hashtables
Date: Thu, 06 Aug 2015 20:46:09 +0200	[thread overview]
Message-ID: <8737zwntla.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: 87si7wtpib.fsf@lifelogs.com


Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, it's possible, but that's a terrible syntax. Maps should *look*
> different from lists and their keys and values, in particular, should be
> easily distinguished from each other.

Why?

The whole point of lisp, is to recognize that things don't need to look
different at all, that you get much more mileage by using a uniform
syntax for everything: (operator argument argument…)
Or in the case of plain data: (type attribute attribute).
which is the same in the case of (BOA) constructors:

    (vector 1 2 3)
    (list 'thx 1138)
    (point 10.3 12.4 'red)


I've been advocating for readtable and reader macros as a mean for _end_
_user_ extension, not because I support adding syntaxes to lisp.
Additionnal syntaxes can be useful, and should only be used, for end
users and DSL implementing a domain with pre-existing _extensive_ use of
that syntax.

For example, if you were programming a physics simulation, with a lot of
differential mathematical equations that you'd copy from books, you
might implement a DSL for infix mathematical expressions with all kinds
of reader macro to be able to transcribe the printed formular as closely
as possible (just to avoid bugs in the transcription, that will be performed
by your DSL reader macros and macros).    But even in this case, for new
code, you would be strongly advised to use lisp sexps, cf. sicm.
http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html
https://www.youtube.com/watch?v=arMH5GjBwUQ


Notice that if you quote an expression using strange reader macros, you
will see what lisp expression it actually represent, and you can use
that instead.


For example, I have a reader macro that lets me write Objective-C FFI
calls in Common Lisp:

    [NSDictionary dictionary]
    --> #<ns-dictionary [uninitialized] (#x30BC10)>

If I wanted to avoid this reader macro, I could quote it, to see what it
reads as:

    '[NSDictionary dictionary]
    --> (objc:send ns:ns-dictionary 'dictionary)

    (objc:send ns:ns-dictionary 'dictionary)
    --> #<ns-dictionary [uninitialized] (#x30BC10)>

(in this case, I usually don't want to get out of the DSL, since it
implies a strong dependency on Objective-C frameworks, I just restrict
the use of the #\[ reader macro to low level system modules, not
spreading them all around the program).



But maps are not something out of this lisp world.  They existed from
the start as a-list, then p-list and then hash-tables.  They are a basic
data structure perfectly integrated to an algorithmic programming
language, and don't constitute a different, Domain Specific Language.

For this reason, they should use the usual lisp sexps.  Also:

 « Ceci est une chaîne de caractères ! »
 » Dies ist ein String « 

Therefore « and » are very confusing characters to choose for maps.


If you want some "syntax", could instead use → (but again, it's also a
heavily overloaded character).

  →(k1 v1
    k2 v2
    k3 v3)

which would read as:

  '→(k1 v1
     k2 v2
     k3 v3)
  --> #s(hash-table size 65 test eql rehash-size 1.5 
                    rehash-threshold 0.8
                    data (k1 v1 k2 v2 k3 v3))


Then you could define a printer for hash-tables to print them as 

  →(k1 v1
    k2 v2
    k3 v3)

Then you will have to patch all the editors in the world (not only
emacs, people also use vim, textmate, eclipse, notepad, etc to edit
lisp), to teach them about this → that is not inside the parentheses…

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk


  reply	other threads:[~2015-08-06 18:46 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 21:42 How to iterate over properties in a plist? Marcin Borkowski
2015-07-31 22:18 ` Stefan Monnier
2015-07-31 22:29   ` Marcin Borkowski
2015-07-31 22:42     ` Dmitry Gutov
2015-08-01 13:34       ` Michael Heerdegen
     [not found]   ` <mailman.7705.1438381807.904.help-gnu-emacs@gnu.org>
2015-07-31 23:33     ` Pascal J. Bourguignon
2015-08-01 22:49       ` Stefan Monnier
     [not found]       ` <mailman.7750.1438469396.904.help-gnu-emacs@gnu.org>
2015-08-04 10:15         ` plists, alists, and hashtables (was: How to iterate over properties in a plist?) Ted Zlatanov
2015-08-04 10:29           ` Nicolas Petton
     [not found]           ` <mailman.7809.1438684158.904.help-gnu-emacs@gnu.org>
2015-08-04 11:23             ` plists, alists, and hashtables Ted Zlatanov
2015-08-05  4:36           ` plists, alists, and hashtables (was: How to iterate over properties in a plist?) Rusi
2015-08-05  6:12             ` plists, alists, and hashtables Pascal J. Bourguignon
2015-08-05  9:47               ` Ted Zlatanov
2015-08-05 12:20                 ` Rusi
2015-08-06 19:16                   ` Stefan Monnier
     [not found]                   ` <mailman.7892.1438888819.904.help-gnu-emacs@gnu.org>
2015-08-07 16:33                     ` Rusi
2015-08-05 17:24                 ` Pascal J. Bourguignon
2015-08-05 18:31                   ` Ted Zlatanov
2015-08-05 19:30                     ` Barry Margolin
2015-08-05 19:40                     ` Robert Thorpe
2015-08-05 21:11                     ` Pascal J. Bourguignon
2015-08-06 15:17                       ` Ted Zlatanov
2015-08-06 18:46                         ` Pascal J. Bourguignon [this message]
2015-08-06 20:19                           ` Drew Adams
2015-08-06 21:08                           ` Ted Zlatanov
2015-08-07  0:23                             ` Pascal J. Bourguignon
2015-08-06 19:35                         ` Stefan Monnier
2015-08-05 13:48               ` Drew Adams
2015-08-06 19:12           ` Stefan Monnier
     [not found]           ` <mailman.7890.1438888393.904.help-gnu-emacs@gnu.org>
2015-08-06 20:00             ` Pascal J. Bourguignon
2015-08-06 20:57             ` Ted Zlatanov
2015-08-06 21:10               ` Drew Adams
     [not found]               ` <mailman.7902.1438895429.904.help-gnu-emacs@gnu.org>
2015-08-06 21:15                 ` Ted Zlatanov
2015-08-06 21:31               ` Stefan Monnier
2015-08-07  1:53                 ` Ted Zlatanov
2015-08-07  7:34                   ` Pascal J. Bourguignon
2015-08-07 16:32                   ` Stefan Monnier
     [not found]                   ` <mailman.7941.1438965165.904.help-gnu-emacs@gnu.org>
2015-08-08  3:48                     ` Pascal J. Bourguignon
2015-08-08 13:42                       ` Stefan Monnier
2015-08-08 14:51                         ` Rusi
2015-08-07  0:08               ` Pascal J. Bourguignon
2015-08-07  2:14                 ` Ted Zlatanov
2015-08-07  7:53                   ` Pascal J. Bourguignon
2015-08-07 11:21                     ` Ted Zlatanov
2015-08-07 11:47                       ` Pascal J. Bourguignon
2015-08-07 17:21                         ` Ted Zlatanov
2015-08-07 19:21                           ` Stefan Monnier
     [not found]                           ` <mailman.7952.1438975314.904.help-gnu-emacs@gnu.org>
2015-08-08  3:52                             ` Pascal J. Bourguignon
2015-08-07 16:35                       ` Stefan Monnier
     [not found] <mailman.7856.1438803631.904.help-gnu-emacs@gnu.org>
2015-08-05 20:08 ` Ted Zlatanov
2015-08-05 20:45   ` Stefan Monnier
2015-08-05 21:36   ` Drew Adams
2015-08-05 21:41   ` Pascal J. Bourguignon
     [not found]   ` <mailman.7860.1438807554.904.help-gnu-emacs@gnu.org>
2015-08-06  1:32     ` Ted Zlatanov
     [not found]   ` <mailman.7862.1438810623.904.help-gnu-emacs@gnu.org>
2015-08-06  1:36     ` Ted Zlatanov

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=8737zwntla.fsf@kuiper.lan.informatimago.com \
    --to=pjb@informatimago.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.