freenode/#lisp - IRC Chatlog
Search
5:58:25
fiddlerwoaroof
dxtr: one trick I've thought of is to use a cons cell where the car is a stack of previous items and the cdr is the remaining list
6:09:40
fiddlerwoaroof
here's a non-mutating version: https://fwoar.co/pastebin/676375393d12b9ba8ad525c85363b732e5c9604c.lisp.html
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?