Re: plists, alists, and hashtables

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

Ted Zlatanov <address@hidden> writes: > On Fri, 07 Aug 2015 02:08:58 +0200 "Pascal J. Bourguignon" <address@hidden> > wrote: > > PJB> Ted Zlatanov <address@hidden> 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