help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: plists, alists, and hashtables


From: Pascal J. Bourguignon
Subject: Re: plists, alists, and hashtables
Date: Thu, 06 Aug 2015 20:46:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]