[Top][All Lists]

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

Re: plists, alists, and hashtables

From: Ted Zlatanov
Subject: Re: plists, alists, and hashtables
Date: Thu, 06 Aug 2015 17:08:39 -0400
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

On Thu, 06 Aug 2015 20:46:09 +0200 "Pascal J. Bourguignon" <address@hidden> 

PJB> Ted Zlatanov <address@hidden> 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.

PJB> Why?

Because I don't want to look at (a b c d e f g h) and count until I find
that g is a key and h is a value.  That's dumb and leads to mistakes.

PJB> Additionnal syntaxes can be useful, and should only be used, for end
PJB> users and DSL implementing a domain with pre-existing _extensive_ use of
PJB> that syntax.

My claim, I guess, is that general ELisp programming involves an
extensive use of maps, so it could use a syntax for it.

I am not making any philosophical claims about the essence of Lisp.

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

I've given examples of why lists, in my opinion, don't make a good read
syntax for maps.  If that's not enough to convince people, then it's not
a good idea.

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

OK, that's fine.  I really don't want to care about the choice of markers.
It's completely irrelevant to me.  It could be "Pascal" on the left and
"Bourguignon" on the right, with "J" as the cell separator.

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

Yup. I agree that adoption will be painful and slow, but it has to start


reply via email to

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