freenode/#lisp - IRC Chatlog

5:33:35 beach Good morning everyone!

5:56:22 ahungry morning

6:33:39 william_1 ** NICK williamyaoh

7:06:19 jackdaniel lately I encounter a pattern, that I define a variable being a collection (property list or hashtable), and to not expose it (I may want to change implementation in the future - maybe database or switch from plist to ht), I provide a functional interface for it: #'register-xxx, #'remove-xxx, #'reigstered-xxx. Is it a bad idea to provide a macro to simplify such definitions?

7:07:15 flip214 jackdaniel: what would the macro do?

7:07:31 flip214 provide these functions?

7:07:44 flip214 don't know whether it's worth the effort...

7:08:38 jackdaniel basically what I type by hand: `(progn (defparameter ,name (make-hash-table)) (defun ,(symbolicate 'register- ,name) (setf …)))

7:08:44 jackdaniel well, writing such macro is trivial

7:09:24 pillton It would be if (register-xxx a b) was equivalent to (register (xxx-registrations a) b).

7:09:36 Bike oh, i've done that sometimes

7:11:01 flip214 jackdaniel: but the searching for is (or might be) different each time

7:11:27 jackdaniel flip214: from the interface perspective its not

7:11:47 jackdaniel for prototypes I usually use hash table, but later (preserving the interface) I may change it to whatever I like

7:12:21 william_1 ** NICK williamyaoh

7:13:42 flip214 well, if you find a nice abstraction -- lots of things use this pattern

7:15:41 jackdaniel drawbacks of that I can see are: readibility (I'm not especially keen with symbols appearning out of the blue in the package) and it is arguable whenever such syntatic sugar is worth having such macro.

7:18:28 pillton You could have (define-registrar xxx :add register-xxx :remove deregister-xxx).

7:20:52 jackdaniel right, that sounds like a good idea

7:21:21 jackdaniel thanks

7:44:52 fiddlerwoaroof jackdaniel: what's the advantage over making register/deregister/etc. be generic functions?

7:45:23 pillton The global variable is private I gather.

7:47:02 pillton I would assume that define-registrar would expand in to code that applies generic functions though.

7:47:54 fiddlerwoaroof (defparameter xxx (make-hash-table)) (defmethod register ((registry (eql xxx)) ...))...

7:47:54 fiddlerwoaroof

7:48:14 fiddlerwoaroof Or something like that, then switch to a class when you want to use a db instead of a hash table

7:49:15 jackdaniel so you basically expose xxx object if you mandate, that user provides it to the function

7:49:18 jackdaniel that's for one

7:50:01 jackdaniel the second problem with this is that names should be meaningful, like (register-search-provider :wonderful-provider (lambda (obj) nil))

7:50:31 jackdaniel because it is a part of a funcionality, stock name "register" isn't meaningful here

7:50:43 jackdaniel it's basically singleton collection with setters/getters/listers

7:51:11 pillton jackdaniel: There are some systems for defining namespaces. e.g. https://github.com/guicho271828/lisp-namespace

7:51:47 pillton jackdaniel: Not sure that project satisfies your use case though.

7:52:06 pillton jackdaniel: It does provide support for lexical registrations though.

7:52:26 jackdaniel maybe I didn't express my need clear. I want to have a variable internally with a funcitonal interface exported. The question is whenever it is /elegant enough/ to simplify creation of it with a macro :)

7:52:52 Bike well, fuck elegance, it's simple and easy and that's enough

7:52:58 jackdaniel I know what I want to do and how

7:53:03 jackdaniel right

7:53:16 Bike no need to think about it too much really

7:53:44 fiddlerwoaroof You'll discover whether or not it's elegant, once you come back to the code in a month :)

7:53:56 jackdaniel you've got a point here, but I have gathered a nice idea how to avoid implicit symbol creation, so it's not a waste of time happily

7:54:05 jackdaniel ↑ was directed to Bike

8:53:38 williamyaoh :quit

8:53:43 williamyaoh whoops

10:04:56 younder hrm.. lineinfo has a terminfo.lisp, but instead of reading the terminfo it hardcodes the values. It looks like he intened to read it from a file but in the end tok the terminfo file and 'massaged' it into a working definition. (emacs is great for that)

10:16:19 #lisp ** TOPIC Common Lisp, the #1=(programmable . #1#) programming language <http://cliki.net/> <http://paste.lisp.org/new> logs:<http://ccl.clozure.com/irc-logs/lisp/>|contact op if muted|SBCL 1.3.7, ASDF 3.1.7, ECL 16.1.2, CMUCL 21a, CFFI 0.16.0, cl-launch 4.1.4, flexi-streams 1.0.15, Hunchentoot 1.2.34, Drakma 2.0.1

10:19:23 Colleen_ ** NICK Colleen

10:19:24 ephe_meral_ ** NICK ephe_meral

10:24:52 mrSpec ** NICK Guest68459

10:25:45 arrsim_ ** NICK arrsim

11:01:07 beaky1 ** NICK beaky

11:02:36 younder aah 'infocmp' decompiles terminfo into text.

11:27:10 MoALTz_ ** NICK MoALTz

11:28:07 loke` Hello

11:37:09 Xach ahoy loke`

11:37:15 loke` Hello Xach

11:37:20 loke` What's happening?

11:40:46 Xach external-format hacking

11:41:29 loke` In what context?

11:41:39 loke` External formats should be easy these days. UTF-8 or bust?

11:42:28 Xach loke`: web client

11:42:47 loke` Xach: For what?

11:43:08 loke` Hello Dea

11:43:12 loke` Hello DeadTrickster

11:43:16 younder In my case I am messing with the lineedit package. Unraveling out the terminfo interface.

11:46:01 loke` * is hypothesising about the ability to reimplement the Emacs core in CL.

11:46:17 loke` Still wondering if I should actually start that project.

11:46:39 flip214 loke`: isn't that what Second-Climacs, hemlock, etc. have done or tried?

11:47:13 loke` flip214: jackdaniel pointed me to an attempt to do it for Hemlock, but I don't know the results.

11:47:16 loke` Any other attempts?

11:47:41 flip214 loke`: second-climacs?

11:47:50 loke` My idea is basically to implement the native functions (1188 of them) in CL, so that the rest of Emacs (the Lisp parts) can run on top of it.

11:48:12 flip214 loke`: http://cliki.net/CL-Emacs

11:48:54 isoraqathedh It's somewhat annoying that paredit automatically matches [] and in CL even though that pair doesn't have any special meaning in it.

11:48:58 younder Just added C-Arrow-left for move-word-forward etc after understanding the cryptic escape codes generated.

11:49:16 flip214 oh, and there's another try at that, see neomacs, https://github.com/adolenc/cl-neovim/issues/1

11:49:27 loke` flip214: Right. Those are Emacs-like editrs in CL. My idea would be to base the work on one of those, but actually implementing the core Emacs functions in it, so that Emacs Lisp code (this includes all the Elisp that is part of Emacs itself0 can run on it.

11:49:39 isoraqathedh I'm not sure if setting the keys [ and ] to self-insert mode will bork Elisp.

11:49:44 loke` That is what I'm wondering if anyone has ever attempted (and got anywehre)

11:49:46 isoraqathedh elisp-mode, rather.

11:50:46 loke` isoraqathedh: There is a way to csutmise which symbols are considered parens in Paredit.

11:50:57 isoraqathedh But is it global?

11:51:03 isoraqathedh I would want [] to match in Elisp but not in CL.

11:54:02 loke` isoraqathedh: What if you locally remove pareid-wrap-square from paredit-wrap-commands

11:54:02 loke` ?

11:55:55 loke` isoraqathedh: Right, so you do it only locally.

11:56:17 loke` You set it buffer0local in the init-hook for Lisp-mode

12:01:04 younder is there a portable way of sb-ext:posix-getenv

12:01:20 scymtym younder: uiop:getenv

12:02:19 scymtym younder: hasn't the terminfo extraction from lineinfo already happened? there is a terminfo project in quicklisp that seems to be just that

12:03:16 younder I am having probles mapping C-Left arrow etc. it crashes lineedit.

12:47:31 igam loke: have a look at http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=751

12:48:32 igam loke: I propose another way to integrate emacs into Common Lisp: write a C compiler targetting Common Lisp. Then you will be able to compile the emacs C code and run it in a Common Lisp implementation; add emacs-lisp <-> Common-Lisp FFI; profit!

12:51:29 phoe aw geez not again

12:51:55 igam loke: I started https://framagit.org/com-informatimago/com-informatimago/tree/master/languages/c11

12:52:03 brucem morning

12:52:08 igam phoe: just giving references.

12:54:44 igam loke: also, Hemlock contains some emacs lisp stuff.

13:24:00 loke` igam: I'm not sure that's a very good idea.

13:24:17 loke` You'll end up with all the drawbacks of Emacs with none of the benefits.

13:26:12 igam loke`: nope. The only drawback we'd keep, is that we'd still have to use emacs lisp code. But the problem it solves is that we could use emacs lisp code without having to rewrite it entirely (and third party libraries) in Common Lisp, which we cannot do. Then we can use Common Lisp for our own emacs extensions, and we can use FFI, threads, whatever the underlying CL implementation provides.

13:27:09 igam Agreed, it'd be better if all the emacs code was rewritten cleanly in CL, but this will never happen (until you have an AI and several centuries processor time to do it).

13:27:37 flip214 igam: a CL decompiler might be more reasonable ;)

13:27:47 igam (Happily, the AI will be able to rewrite it in less than a day on Amazon cloud, but you'll still have to pay for the century proessor time).

13:27:55 igam flip214: what do you mean?

13:28:14 flip214 instead of a AI to convert, just decompile the binary to CL code.

13:28:29 flip214 *an AI

13:29:02 igam Oh, and the big advantage of implementing a C -> CL translator, is that we won't have to maintain emacs, mostly. We will just have merge new versions and recompile them. And it'll work with any target future CL implementation too.

13:29:32 igam Oh, and another advantage is that you'll be able to use this C compiler to compile other stuff. Perhaps c-python and ruby implementations, etc.

13:30:01 igam flip214: read tromey blog, and my answer.

13:31:13 loke` igam: But you'll still be using the current ELisp implementaiton, just that it's compiled by a CL compiler instead of C.

13:31:26 loke` The elisp code won't run in CL

13:31:57 loke` igam: Well, being able to compile C into Lisp certainly has plenty of benefits.

13:32:03 loke` I just don't think Emacs is the main one.

13:32:14 loke` I'd love to have a C-compiler that tagets Lisp.

13:32:22 loke` Didn't the Lisp machines of yore have that?

13:32:30 igam loke`: the emacs code will be compiled by the CL compiler and will be running inside the CL implementation.

13:32:46 igam loke`: each C function will be compiled as a CL function, that you can call from Cl.

13:32:52 igam What more do you want?

13:33:16 igam Oh, elisp. elisp will be compiled to byte code and will be executed by a C VM compiled to CL, ie. a CL function.

13:33:27 igam How is it not running in CL?

13:33:29 loke` igam: Right. But I wanted to have the Elisp objects being actual CL objects. An elisp cons call literally be a CL cons. An elisp closure would be a CL closure. The only thing that would be problematic are Emacs strings, which can't be mapped directly to CL strings.

13:33:38 lemonpie lol, this is absurd

13:33:41 igam Now, indeed, you have to have a FFI to be able to call an elisp function from CL.

13:33:57 loke` igam: Right. That's what I wanted to avoid.

13:34:08 loke` I wanted the Lisp engine to _be_ CL.

13:34:08 igam But you won't do that much, since we're CL programmers, we'll write our stuff in CL, relying on CL libraries, not on elisp libraries.

13:34:23 loke` igam: True, but Emacs users won't switch that easily.

13:34:40 igam The elisp code is only used because it implements features we don't want to do without, but that we don't have the means to re-implement in CL, such as org-mode.

13:34:45 loke` My hope was to end up with somethat that could actually replace the C engine in Emacs.

13:35:24 igam loke`: the mapping of elisp types to CL types can be implemented by the VM. Ie. yes, we'll have to rewrite/adapt a few headers.

13:35:33 loke` igam: I fully understand your idea, I think. It's just we have different ideals here. In my vision, Elisp would simply be a DSL for CL.

13:35:43 igam This will be the value add we'll provide, and this will be what we'll have to maintain!

13:36:31 igam loke`: This is what hemlock does, just implementing elisp macros and functions in CL. The problem here is that we don't have resources to do a complete enough job for it to be useful, or even usable with the smallest elisp library.

13:37:31 igam The alternative of course would be to be South African, earn a lot of money doing anything but CL, and then instead of going to space and financing ubuntu, or financing tesla and spacex, you'd finance heavily CL developments.

13:38:03 igam (possibly being South African is optional, I'm not sure).

13:38:32 igam loke`: Lisp machines had Zeta-C; sources available, difficult to port to Common Lisp.

13:38:55 igam And it's an old C, nowadays you'll want most of C11.

13:40:24 loke` igam: Well, I haven't written a single line of code for any of this myself, so there's that.

13:41:30 igam loke`: I've completed the C pre-processor of my C11 C->CL translator, and started the parser.

13:41:33 loke` igam: I looked at writing a code generator for LLVM that targets Lisp. I quickly gave up on that since their backends work on an instruction level. I.e. they have an asusmption of some basic behaviour of the underlying architecture, such as having registers. :-)

13:42:07 igam loke`: this could still be a good idea to pursue, since it could give results rapidly.

13:42:17 brucem loke`: You'd be better starting from how WebAssembly and asm.js generation from LLVM happens.

13:42:29 igam (deftype registers () (vector 16))

13:43:01 loke` brucem: Yes. But I don't want that :-)

13:43:12 loke` I'd like a C function to a lisp defun

13:43:40 brucem loke`: I don't mean to use WebAssembly or asm.js ... just that a lot of the issues that you would or did run into have been dealt with there.

13:43:44 flip214 loke`: interpreted, via FFI, or a _real_ translation?

13:43:55 loke` flip214: the C code?

13:44:12 loke` flip214: Well, if you want to use LLVM, you're going to end up with functions that contains lots and lots of SETQ :-)

13:44:27 flip214 clang can give you an AST... you "only" have to convert it to the right notation.

13:44:29 igam loke`: so, translating C to lisp at a high level would be very nice. But: 1- we would now have to maintain cl-emacs. The current maintainers of GNU emacs wouldn't take this CL sources (they prefer guile).

13:45:47 igam AST in the C world is not so much a good point as it could be with other programming languages. (and even worse for C++). Ie, the "Abstract" part is all but.

13:45:57 loke` actually, it's rms that dislikes CL

13:46:06 loke` (for completely irrational reasons)

13:46:36 igam Or, say, hysterical ;-)

13:46:49 loke` igam: Another alternative would be to use the Emacs module system to load, say, ECL into it and provide a CL->elisp bridge.

13:47:07 loke` That's probably the fastest way to get CL into Emacs. Should be doable in a weekend.

13:47:15 igam loke`: yes, nowadays it's a possibility.

13:50:35 loke` igam: What can the c11 project do at the moment?

13:51:02 igam Pre-process source files.

13:51:33 loke` Does it build an AST?

13:52:21 igam https://framagit.org/com-informatimago/com-informatimago/blob/master/languages/c11/scratch.lisp#L48

13:52:57 igam No, it only tokenize the source for the purposes of the pre-processor.

13:53:36 loke` igam: I see. So lots of hard work to get it to a functioning system.

13:53:53 ski_ ** NICK ski

13:54:04 loke` I wonder if a GCC backend would be better (less low-level). I've never tried, and is there documentation on this?