Re: plists, alists, and hashtables

[Pascal J. Bourguignon]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 07 Aug 2015 02:08:58 +0200 "Pascal J. Bourguignon" 
> <pjb@informatimago.com> wrote: 
>  
> PJB> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> Maybe the macro is good enough, but I think the keys and values have to
>>> be clearly separated from each other and from other cells to make it
>>> visually useful.  
>
> PJB> I understand that, and I cannot advise more strongly that you add
> PJB> newlines and indent your data to clearly show it.
>
> PJB>          (hash-table  k1      v1
> PJB>                       kkkk2   v2
> PJB>                       k3      vvvvvv3)
>
> I don't think it's good to force the programmer to reformat their code
> because the syntax doesn't do the right thing.

But for a function, I'm saying it's more practical.

> PJB> Also, I would admit that using parentheses around the entries could help
> PJB> editing the data structure, since that allows adding or removing entries
> PJB> easily with a structural editor like emacs+paredit.
>
> PJB>         (mhash-table  (k1      v1)
> PJB>                       (kkkk2   v2)
> PJB>                       (k3      vvvvvv3))
>
> PJB> It works well enough for a macro (eg. let), but for a function it is a
> PJB> real bother
>
> I think that's good enough in the `let' format, as a macro. The
> syntactic shortcut of creating keys without a cell with a null value is
> nice too. Can we agree that this is a good syntax and move back to
> discussing Unicode markers again? :)

For a macro, ok.


> PJB> And this is why we feel the lack of reader macros, since that would
> PJB> clearly allow you to write a new syntax in a user library, instead of
> PJB> having to beg it from the emacs lisp language itself.
>
> Is this work already planned?

Well, once emacs got to git, I cloned it to do that, add CL packages and
reader macros to emacs.  But unfortunately I've not worked on it since.

But I'm planing a take over :-)  I'm writing a C parser in CL, so that I
may read the C sources of CL, and then translate them into maintainable
CL.  Then I will be able to compile a CL GNU emacs core, that would be
100% bug-for-bug compatible with GNU emacs, and on which you could run
all the .el (and even .elc) you'd want.

But since the core would be written in CL, I could now provide features
found in CL and in CL implementations, such as FFI, threads, packages,
readtables, etc, by merely providing access to the underlying CL API.

Basically, in GNU emacs, buffer-substring-no-properties is a C function.
In CL GNU emacs, buffer-substring-no-properties would be a Common Lisp
function, named by a CL symbol emacs:buffer-substring-no-properties.

You could write CL code in some CL package my-lib:process-buffer that
could call those core emacs functions.

For the emacs lisp functions more work will be needed, because from the
automatic translations we would just get an emacs lisp VM (and the
interpreter), working in a separate metalinguistic level.  Even if we
used CL symbols for the emacs lisp symbols, we couldn't funcall them
from CL, since there would be no CL function defined by emacs lisp
defun.  

And similarly, the readtable feature and CL package feature in emacs
lisp will have to be hacked similarly as well in CL GNU emacs than in
GNU emacs, but the difference is that then I'll be able to rely on the
underlying CL to implement them for emacs lisp. Basically, I'll have to
gut out some emacs lisp parts (eg. the emacs lisp reader), and implement
it as a Common Lisp readtable.  Then emacs lisp symbols will be CL
symbols and the package:symbol syntax will be available in emacs lisp to
call CL.  Then modifications to the interpreter and VM will allow
calling emacs lisp functions from CL, and we'll be set.


> How much of it must be done to accomplish what I want, a library that
> lets me say `{ "k1": "v1" }' (giving JSON syntax as an example) and
> translates it to the correct #s(hash-table ...) serialization?

Very little, since it's already implemented:

M-x package-install RET json RET
(require 'json) C-x C-e
{"k1":"v1"} C-a C-u M-: json-read RET
--> ((k1 . "v1"))


So: 

   (defmacro json-quote (string)
      (with-temp-buffer
        (insert string)
        (goto-char 0)
        `',(json-read)))

  (json-quote "{\"k1\":\"v1\"}") ; same problem as with regexp, 
                                 ; no reader macros to simplify this.
  --> ((k1 . "v1"))


> Together with the Customize support for hashtables, I think we can agree
> these would be nice usability improvements.
>
> Stefan also mentioned there could be performance optimizations for
> hashtables themselves.  I think that's a good direction too.
>
> Ted

-- 
__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