libera/#sicl - IRC Chatlog

11:44:07 edgar-rft` ** NICK edgar-rft

14:00:04 beach I conducted some experiments with the idea of pretty-printing an expression to a CST with SICL source information. I can get the text right, but I think I need the help of yitzi in order to get the source information right. For some reason, even though I call INCLESS:WRITE-OBJECT with my own stream instance, this instance does not get propagated to recursive calls to INCLESS:WRITE-OBJECT.

14:05:07 beach It wraps the stream either in a BROADCAST-STREAM or an INRAVINA:PRETTY-STREAM.

14:07:38 beach Also, it seems to print the entire expression twice, once with a broadcast stream and once with a pretty-stream, but maybe that's normal.

14:08:14 bike probably to detect circularities

14:08:26 beach Maybe so.

14:08:31 bike with an empty broadcast stream so it doesn't actually print anything

14:08:43 beach Yes, I see.

14:11:14 beach So I think defining and :AROUND method on INCLESS:WRITE-OBJECT is wrong, because not every object printed is passed to INCLESS:WRITE-OBJECT. I need to figure out where to stick this :AROUND method.

14:11:31 beach Otherwise, I think I am on the right track.

14:13:03 beach When yitzi is back in business I'll ask for help. The code is just 100 lines or so.

14:13:26 beach Or, if I have more time, I'll dig deeper into Inravina myself.

14:13:52 beach If I am going to use it in SICL, it is good to have a second person who understands how it works.

14:25:17 beach Maybe I didn't mention this, but I want to use this feature to create a CST with source information from a form that is generated, like a discriminating function. And since SICL source information does not rely on files, and instead uses a vector of lines in main memory, this is relatively simple to do.

14:26:16 beach Then, if something goes wrong in such a form, we can use the ordinary debugging tool to inspect the source code, as opposed to something like what SBCL uses.

15:02:39 beach Would the adjective for something that could be inlined be spelled "inlinable" or "inlineable"?

15:06:28 paulapatience Inlinable would be my preference

15:06:36 beach Thanks.

15:06:52 paulapatience The situations where the e is kept are less frequent than the alternative, I think.

15:07:12 beach You are probably right. I haven't thought about it too hard.

15:07:21 paulapatience Merge -> mergeable is because mergable would be pronounced differently.

15:07:30 paulapatience Inlinable has no such problem

15:07:37 beach Indeed.

15:07:54 paulapatience (And of course now every time I type inlinable I accidentally put the e)

15:08:07 beach Heh!

15:08:15 paulapatience Though that might be because I'm used to typing inline

15:08:59 beach That's the situation where I make an Emacs abbrev to correct my spelling. :)

15:09:46 paulapatience But then you will perpetuate the mistake when using other editors!

15:10:01 beach Other editors? :)

15:10:12 paulapatience Heresy!

15:11:32 paulapatience Speaking of, I'm starting to look forward to Climacs. I am in an unfortunate situation where I want a function named LABELS, but Sly refuses to indent it as a function, instead assuming it is CL:LABELS.

15:11:59 paulapatience And that, even when it is prefixed with the package name (which differs from CL)

15:12:00 beach I know what you mean.

15:12:32 paulapatience I'm actually thinking of an alternative name for the function to try to deal with this issue, but that is totally backwards.

15:12:38 beach I am *so* tired of Emacs+SLIME/Sly, but it's the best we have.

15:13:06 paulapatience That's what I tell people in my group: it's not that I *like* Emacs, it's just that I like CL and it's currently the only reasonable option

15:13:19 beach Well put.

15:13:54 beach I am fine with Emacs for many other things, but not for editing Common Lisp code.

15:14:48 beach I will start using Common Lisp myself as soon as we have some reasonable code for automatic indentation. But that will take some time yet.

15:14:57 beach s/Common Lisp/Second Climacs/

15:15:00 beach *sigh*

15:18:01 beach And then, we should be able to plug in Iconoclast and Common Boot into Second Climacs so as to get a much better analysis of the code.

15:20:26 beach It kind of all comes together. We need Eclector to read the code, and we need extrinsic Parcl to handle (possibly non-existing) packages, s-expression-syntax to parse the code and turn it into Iconoclast ASTs, and Common Boot to finalize the ASTs relative to a Clostrum environment, using Trucler, of course. :)

15:21:22 beach Oh, and an AST evaluator for MACROLET.

16:32:48 paulapatience Yeah, automatic indentation is a must

16:34:12 paulapatience It will be fun to write extension packages. They will be able to leverage existing CL code that is useful in the general ecosystem, unlike elisp which is useful only for Emacs.

16:34:43 beach Indeed.

16:35:47 beach I want to use all those things I listed above, because they are the same things used for SICL, both for bootstrapping and in the final system.

16:37:32 paulapatience On my side I have been writing some libraries that I think are essential for doing science in CL. Right now I'm working on a plotting library (with a gnuplot backend, but that can be extended to others, e.g., CLIM) so that I can visualize the results of my research. And I also have an embryonic dataframe library to make data exploration more convenient, and which hooks directly into the

16:37:32 paulapatience plotting library.

16:38:08 paulapatience Then with Clasp I have wrapped an FEM library to do simulations with, and there is also the blackbox optimization library I mentioned on #commonlisp some time ago.

16:38:25 beach Sounds great!

16:38:35 paulapatience And they all define a protocol based on the client pattern

16:38:47 beach Even better! :)

16:38:51 paulapatience Which makes them all fit together very nicely

16:39:41 paulapatience For example, a user can choose a plotting backend and dataframe representation by subclassing their client from the appropriate plotting and dataframe clients.

16:39:54 paulapatience I don't understand why the client pattern is not more widespread

16:40:15 beach Perfect! Yes, I think we were on to something with that pattern.

16:40:30 paulapatience I recently learned that the njson library, which offers a generic interface across existing JSON libraries, can load only one backend at a time

16:40:37 paulapatience Because it has no client parameter

16:40:46 beach It is useful only when you have multiple dispatch, so perhaps people are not so used to having that.

16:41:06 paulapatience That makes it close to useless in my opinion. Nobody can use the library in public code, because it would force the choice of backend.

16:41:20 beach Sure.

16:42:38 paulapatience And all this is thanks to my having contributed to Trucler. That's where I learned of the pattern.

16:42:48 beach Nice!

16:42:54 beach I think the CLIENT pattern is a necessity if you imagine a host that has the code loaded, and then you need the code extrinsically for something like bootstrapping.

16:43:43 beach But it is also useful just for overriding or extending some methods.

16:44:46 paulapatience I find it useful whenever a client would want to specialize a method to a native CL type.

16:45:03 paulapatience It frees them from having to define an artificial wrapper class.

16:45:31 beach Do you mean a native type that is also not a class?

16:45:47 paulapatience Yes

16:45:51 beach Sure.

16:46:31 paulapatience But in fact it is also useful when the type is a class but it might be annoying to subclass it, perhaps because there are 10 or 20 classes you'd need to subclass

16:46:47 beach I see, yes.

16:47:16 paulapatience For instance, my dataframe library will support plain arrays and lists transparently, thanks to the client

16:47:52 beach Interesting.

16:48:35 beach Maybe someone should write an ELS paper about the patterns and its usefulness?

16:49:04 beach But you are already working on a paper, right?

16:49:38 beach My (admittedly small) family just announced that dinner is served. I'll be back tomorrow.

16:50:19 paulapatience I think that that would be a very good idea. It would be good to list examples of its usefulness and how to best use it.

16:50:41 paulapatience bike had been asking about ways we used clients, a few months ago

16:50:57 paulapatience However for this ELS, the working plan is that yitzi and I coauthor the paper on Quaviver

16:51:16 paulapatience I could maybe work on a client paper for ELS 2026 ;)

17:18:50 yitzi beach: doing an :around method in write-object isn't going to work. The pretty printer does all layout once the last pprint-logical-block is complete, therefore the stream line and column are meaningless in write-object.

17:20:28 yitzi I am thinking this would be a specialized type of output stream. I'll see what I can figure out.

17:37:35 scymtym since the "client parameter" design pattern is mentioned so frequently, it may be a good time to (re)consider what fare had to say about the topic (using differently terminology): http://fare.tunes.org/files/cs/lil-ilc2012/lil-ilc2012.pdf (or https://fare.livejournal.com/155094.html for the less patient)

17:43:17 paulapatience Oh, wow, I had already seen the lisp-interface-library, but I hadn't understood the relationship with the client parameter

17:46:36 paulapatience Huh, it has ways to make the argument implicit. E.g., with-interface for locally, or define-interface-specialized-functions for package-wide

17:46:44 paulapatience I'll have to read the paper in more detail

20:05:51 robin scymtym, i immediately started thinking "type classes" after seeing the name :P

20:09:46 robin wondering how it would interact with the kind of "intentional dispatch" described in http://www.nhplace.com/kent/PS/EQUAL.html

20:11:11 robin probably accomodates that pattern in a more structured way

22:01:18 paulapatience beach: Why is clonedijk:clone-information :most-specific-last?

22:02:01 paulapatience Wouldn't it make sense to be the opposite? Otherwise if we naively apply the cloning information to make instance, any duplicate initargs in more specific classes would be ignored.