freenode/#lisp - IRC Chatlog
Search
7:04:15
asarch
Just in the case if you are wondering if PortableAllegroServe can do REST API, the answer is yes:
7:08:45
asarch
A 40 years old programming language can use a 20 years old program to develop nowadays web applications!
9:02:31
splittist
Once again I am amazed by how a short period of concentrated thought is a substitute for hours of key bashing. And how hard it is to carve out time for concentrated thought.
11:32:45
dim
well there's also the interactive discovery of the problem at hand, which often requires a fair amount of key bashing
11:33:51
_death
a method that has definitely proven to work this past year was to let my subconscious do the hard work.. but that presupposes you can manage your own time
11:51:13
margaritamike
Not sure. Think it's a prologgy search pattern. Just saw this HN thread that was posted and wondered: https://news.ycombinator.com/item?id=19141197
13:25:03
jackdaniel
since it is so quiet here, I'll drop an output of a tool I've hacked a moment ago (dependency graph of systems in McCLIM): https://files.mastodon.social/media_attachments/files/011/321/125/original/ad53eb257ca058e5.png
13:29:34
makomo
is there a solution to the "package problem" regarding anaphoric macros? you could export the symbol and make your clients use that symbol/your whole package
13:30:58
makomo
splittist: the use-case isn't like LOOP. i'm kind of "injecting" a macrolet within a body
13:56:01
Bike
well, it uses the current package to make symbols. if you want one of those symbols to be in a different package that has to be done specially
14:00:50
makomo
Bike: something like manually creating those functions and forwarding the calls to the ones made by DEFSTRUCT?
14:02:19
Bike
like using :constructor instead of conc-name so you can specify the whole symbol and *package* isn't used
14:04:54
makomo
Bike: ah, i just skimmed the clhs and saw "interning the name in whatever package is current at the time" under the documentation for :constructor as well so i assumed it only uses the name of the provided symbol, without reading further
14:05:41
makomo
but that's only done in the case where no :constructor is given so it pieces it together with "MAKE-", bla bla
14:07:31
Bike
generally speaking, i'd rather manually specify a symbol than have to worry about *package*
14:12:38
makomo
Bike: yeah, i agree (in general), but for certain macros that beats their purpose :(
14:14:49
makomo
i wonder, would it require some big changes to include a portable code walker within the standard?
14:15:14
jackdaniel
agnostic-lizard depends only on cltl2 interface. but what do you need code walking for?
14:15:30
makomo
jackdaniel: yeah, the "non-portableness" of code walkers. i'm trying to avoid the problem by using a MACROLET to do the walking for me (but even that isn't really perfect, as i have to use MACROEXPAND-ALL)
14:17:01
makomo
jackdaniel: basically, symbols of the form "g!<something>" evaluate to one and the same gensym
14:17:20
Bike
mostly memorable to me because the method they use to do it is nonconforming and people sometimes come in here to ask why sbcl is broken
14:20:18
jackdaniel
I assume (given there are semi-popular operators for that) what I use is a simplified hack though
14:24:02
Bike
(with-clean-symbols (x) (let ((x y)) (+ x x))) -> (let ((#1=#:x y)) (+ #1# #1#)) i think
14:24:04
makomo
here it is, https://gitlab.com/embeddable-common-lisp/ecl/blob/develop/src/lsp/cmuutil.lsp#L189
14:26:57
makomo
jackdaniel: indeed, which is why i find macros such as defmacro/g! and defmacro! useful :-)
14:27:51
jackdaniel
(I want to note, that these names are not self-descriptive (to me at least), while with-clean-symbols is obvious (once again, to me))
14:28:37
makomo
yeah, true. to the uninitiated it's not clear what they do, but once you know what they do, it's really easy to look at a macro defined using defmacro/g!
14:29:55
makomo
the definition of defmacro! (which automatically avoids multiple evaluation for arguments named like "o!<something>") is really neat (and imo much easier to understand than the definition of once-only)
14:31:03
makomo
it's defined using defmacro/g! and this layering of macros/introduction of new syntax is very nice
14:31:46
Bike
i don't think it's that bad explicitly specifying what symbols you want to be gensyms or once-only or whatever.
14:32:37
jackdaniel
I personaly dislike a "magic" syntax which treats things differently depending on what name they have
14:33:37
makomo
yeah, this is where opinions start to differ, but i think that if it was easier (i.e. portable) to write such macros, we would have more of them and would explore these "radical" ideas further
14:34:50
makomo
jackdaniel: in a certain sense it might be "magic", but then again, that's what non-lispers think of ordinary macros. they say how they don't want to learn a thousand custom macros/languages that someone cooked up for a project of theirs, or something
14:36:57
makomo
nothing is good when used excessively, but i think there are very interesting things to be found
14:40:29
akater
makomo: What is the issue with anaphoric macros? Is it about providing them from your system or using them cleanly?
14:41:56
makomo
akater: yeah. the user/client has to use the same symbol within its body as the one that the anaphoric macro injects
14:42:26
makomo
if the user of the macro and the macro itself are within the same package, there's no problem. the problem comes up when they're not
14:43:07
makomo
then you have to either import the symbol/use the package or do ugly stuff like explicitly specifying the package prefix
14:44:30
makomo
or, you could write the anaphoric macro in such a way that it injects a different symbol depending on the value of *PACKAGE* at the time the macro is expanded
14:45:09
akater
makomo: I never exported anaphoric macros but I would export the symbol without thinking twice. Or maybe used a keyword symbol.
14:45:54
makomo
akater: i guess, but it annoys me a bit, especially when the anaphoric macro is there to ease the writing of certain stuff/provide syntactic shortcuts
14:46:23
makomo
then you usually have short non-unique names which might end up clashing if other packages export them as well
14:47:05
jackdaniel
are you certain it is not that you overthink the problem? maybe you had a higher purpose for using this anaphoric macro and gone down a rabbit hole?
14:47:39
akater
makomo: I'm relatively new to CL and have not released libraries yet but if a user wants a package, they will use the package.
14:49:10
makomo
jackdaniel: well, i don't know yet, but to me it doesn't seem like overthinking. i've had multiple problems basically boil down to this
14:49:38
makomo
the problem is that it's not really solveable in any satisfactory *and* standard way, so it's not something that's usually done
14:50:17
akater
Actually, I would often prefer foo:operation to foo-operation but this seems to go against the traditions so I'm still observing.
14:52:16
jackdaniel
what I mean is that either you try to implement something (and then resolving IT is trivial like importing "it" symbol from the package, having ^IT name convention [like I do], or writing symbol-macrolet if you really must); or you think really really hard how to solve it in a systematic and portable way, getting into code walkers and other esotery and lose sight of the thing you wanted to implement at
14:52:35
akater
By the way, suppose I release a library which provides something:make instead of make-something. Will this be considered a mortal sin?
14:56:31
makomo
jackdaniel: yeah, there's a certain truth to that i guess. it's very similiar, if not the same as, the performance vs. perfection problem that beach talks about
16:20:58
flip214
What's the easiest safe way to parse a string to a symbol name? Just READ isn't [or is (SETF *READ-EVAL* NIL) enough?],
16:21:26
flip214
but the split by ":", lookup package, lookup symbol dance is a bit heavy, too (|symbols|, etc.)
16:43:45
jmercouris
then again, I used to be an objective-c developer, so take that with a grain of salt
16:44:50
akater
jmercouris: Nothing prevents you from using define-function. define- macros are often defined.
16:45:15
jmercouris
I try to stick to the standard as much as possible, hence why I'm against efforts such as cl21
16:48:12
akater
By the way, several times I encountered hu.dwim libraries. There's a fairly large repository with lots of custom syntax defined and consistently used. But it looks obscure.
16:52:17
akater
I tried to read one library, and even though it's custom syntax all over the place, it's fairly readable.
16:53:58
akater
An example: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.walker;a=headblob;f=/source/function.lisp
16:54:34
jmercouris
I'm glad it works for them, but to be completely frank, I find the source in that file unacceptable
16:58:16
akater
I'd say if indentation or highlight is difficult to adjust, it is a flaw of its implementation in the editor.
17:01:04
jmercouris
akater: I would say its really hard to make an editor for Common Lisp due to the control you have over the language
17:01:25
jmercouris
the user could do all sorts of things to sabotage the effectiveness of the editor :D
17:02:19
akater
If emacs had indentation/highlighting templates along the lines of "indent this form like defclass", there would be no issues with non-standard syntax at all, I believe.
17:03:12
akater
Maybe it has, and I just did not discover it. But when I tried to highlight everything that starts with def the way defun is highlighted, I failed.
17:05:04
akater
Have to admit, I'm never happy when programming Elisp. Would like to jump ship as soon as somewhat decent alternative is there.
17:09:40
ggole
Emacs does have indentation control, see the docstring of common-lisp-indent-function
17:11:35
ggole
I don't think there is a particularly smooth way to automatically set that up when editing some random file of CL code, though
17:13:03
dlowe
It does occur to me that since guile supports elisp and guile supports scheme, that it might be possible to write a CL frontend to guile
17:13:58
jmercouris
why does it need to exist? it really doesn't, could have easily been an implementation of CL
17:14:47
dlowe
It was the official extension language - I imagine a scheme was just easier to sandbox