genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #commonlisp
<hexology>
is there some tool that can show me a diff between sexprs? it might be useful when debugging and/or testing a macro, to see what exactly differs between my expected output and my broken stupid macro
ebrasca has quit [Remote host closed the connection]
lips123mob has joined #commonlisp
<lips123mob>
hexology: Good question. I would suggest a different route (more practice with macros until it becomes second nature)
<lips123mob>
As to your question, a naive way would be to compare each list and it’s children recursively and flagging differences
<hexology>
nobody is practiced enough to write bug-free code
<lips123mob>
Where this fails is say you are missing an item in one of the lists, but otherwise the two are identical
<lips123mob>
once you hit the item that fails, that error would cascade down to the rest of the comparison as you would be off by 1
<lips123mob>
now you could find ways to resolve that, but you are moving into the territory of parsing incomplete data, which is tricky
<lips123mob>
A simple way would be to check for missing items, and then put a placeholder for them to let the rest of the match work
<lips123mob>
alternatively look to match each component individually and find what is left over (not matched)…that might work
<lips123mob>
but ultimately you would want to understand the semantics of what you are trying to write to perform the best possible matching
<lips123mob>
ultimately to do this right, you would need decent error recovery strategies whilst parsing the lists
<hexology>
that's a good point about the parsing incomplete data. i assume at some point you either give up, or just let it pinball through your algorithm and make no guarantee about the results
<hexology>
presumably there is a lot of prior art here in the various json diffing tools
<hexology>
anyway, that's a young man's yak to shave
<hexology>
would be cool if it existed already though!
<lips123mob>
Yes exactly. I think the idea of matching each sub list and “ticking” them off between both lists will get you a reasonable outcome (leaving the ones which don’t appear in the other)
<hexology>
right. you could probably come up with some rough "edit distance" and adapt the "dynamic time warping" technique for optimal alignment of sequences
<lips123mob>
yes I think this is where the mythical lisp IDE could help, picking up where forms are left out / incorrect (eg calling a generic method with arguments for which there is no specialisation)
<hexology>
"mythical lisp IDE" hah
<hexology>
really i'd like to see this in a test framework
<hexology>
e.g. pytest in python does a surprisingly good job of showing the diff between what you expected and what you got
<hexology>
well... sometimes
<lips123mob>
machine learning might help here too, ala github copilot style
<hexology>
i don't think we even know how that would look
<hexology>
if ML is likely to show up in test frameworks, i would expect that it shows up as something like bayesian black-box optimization in property-based testing
<lips123mob>
training over a large corpus of lisp code to see likely patterns and then fixing incomplete code based on that to allow error recovery during parsing
<hexology>
you'd need to tag forms as in
<hexology>
"incomplete" somehow
<hexology>
(ironically and 100% unintentionally i pressed enter and failed to complete that message)
<lips123mob>
a sufficiently smart editor to capture incomplete forms until you jump out of the top level sexp
<lips123mob>
which could collect a series of information of how the forms are ‘developed,’ from start to finish
<lips123mob>
its a fascinating subject, alas one needs to some spend some serious time to cover it off. hopefully someone does one day
<hexology>
i could see something like that being built for a more popular language like python, or perhaps something that needs more "help" in writing correct code like ruby
<lips123mob>
yes. agree. it can get in your way too - if it pushes you down the path of bad design patterns
mon_aaraj has quit [Ping timeout: 245 seconds]
<hexology>
what, like making it easier to write bad code?
<lips123mob>
yeah, less abstraction / more repetitive code. using it just for error recovery during parsing shouldn’t have that much of an impact, but it might still subtly point you in a direction based on pre-existing paths
mon_aaraj has joined #commonlisp
<lips123mob>
have you been writing helper functions that create macro code? I find that helps a lot
lips123mob has quit [Remote host closed the connection]
notzmv has quit [Ping timeout: 276 seconds]
akoana has quit [Quit: leaving]
anticomputer has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
anticomputer has joined #commonlisp
danieli has quit [Remote host closed the connection]
yauhsien has quit [Ping timeout: 252 seconds]
danieli has joined #commonlisp
danieli has quit [Read error: Connection reset by peer]
danieli has joined #commonlisp
notzmv has joined #commonlisp
danieli has quit [Read error: Connection reset by peer]
danieli has joined #commonlisp
danieli has quit [Read error: Connection reset by peer]
danieli has joined #commonlisp
danieli has quit [Read error: Connection reset by peer]
<hexology>
kagevf: i didn't think about difftastic but i'm sure they also have algorithms for this kind of thing! and pjb i've never heard of informatimago, i'll look into it!
<hexology>
is this someone's personal omnibus library?
<pjb>
Yes, something like that.
rdrg109 has joined #commonlisp
<drakonis>
hexology: look at the initials and then look at pjb's name
<hexology>
ah, i see the username :)
nij- has joined #commonlisp
<dlowe>
I would love to see a common lisp treewalking interface spec so that the implementation's tree-walker could potentially be used.
<NotThatRPG>
There's a code walker in the hu.dwim code-base, which might be helpful...
waleee has quit [Ping timeout: 240 seconds]
<jcowan>
Fully portable code walking is not possible in principle, because implementations may have standard macros that expand to non-standard special forms
<dlowe>
that's why having the implementation provide it would be such a win
<hexology>
jcowan: fwiw i am specifically _not_ interested in macro expansion for my "sexpr diffing" task, just lists of data
nij- has quit [Remote host closed the connection]
<jcowan>
Sure. I was responding to dlowe.
frgo has quit [Remote host closed the connection]
nij- has joined #commonlisp
nij- has quit [Ping timeout: 244 seconds]
frgo has joined #commonlisp
frgo has quit [Read error: Connection reset by peer]
jeosol has quit [Quit: Client closed]
frgo has joined #commonlisp
<pjb>
jcowan: wrong.
<pjb>
jcowan: if an implementation provides additionnal special forms, it must also provide a corresponding macro expanding to standard special forms and/or function calls.
<pjb>
jcowan: otherwise, it's a big conformity bug in the implementation.
azimut has quit [Ping timeout: 268 seconds]
<beach>
pjb: Where is that written?
asarch has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
jeosol has joined #commonlisp
<Bike>
pretty sure that isn't true. if an implementation implements a macro as a special operator it has to provide a macroexpansion, but that doesn't apply to novel operators
<beach>
Yes, that I knew. But I had not seen the claim by pjb anywhere.
<pjb>
beach: 3.1.2.1.2.2 Macro Forms "An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided."
<pjb>
so, sorry, not as I said it.
<pjb>
there's no obligation.
<pjb>
I'll rephrase as: if an implementation provides additionnal special forms, then it should also provide a corresponding macro to let code walker walk the subforms correctly.
<pjb>
Also said otherwise, given a conforming code walker using just macroexpand, we can add support to it for any implementation specific special operator by just defining that corresponding macro.
anticomputer_ has joined #commonlisp
<Bike>
but it might not be possible to do so. for example there may be special operators related to FFI that cannot be expressible with the standard language for example, or extended control operators
anticomputer has quit [Ping timeout: 268 seconds]
<pjb>
Bike: these macros don't need to expand to functional code, only to forms that will help identify the usage of the subforms.
<pjb>
Bike: we need to know what symbols will be used in bindings (variables, functions, macros, symbol-macros), and what forms will be used as forms (they will have to be code walked). So the macro only needs to expand to some let/flet/macrolet/symbol-macrolet and some body (perhaps in a lambda), wrapped in an internal function call.
<hexology>
for source code located in some arbitrary directory, will this allow asdf to find systems & packages in that directory? CL_SOURCE_REGISTRY="/path/to/my/project"
<Josh_2>
Why not use quicklisp?
<hexology>
doesn't quicklisp also require me to put my systems in a centralized place?
<Josh_2>
hexology: no, you can use a symlink and it'll follow the symlink
<hexology>
right, i'd like to avoid that if possible
<Josh_2>
if you put a symlink in ~/quicklisp/local-projects/<my lisp folder> then it'll find your lisp projects
<pjb>
hexology: you can use ql:*local-project-directories*
<pjb>
or asdf:*central-registry*
<pjb>
Following symlinks doesn't work in all implementations.
<pjb>
more precisely, quicklisp doesn't follow symlinks in all implementations.
<Josh_2>
Well it should :sunglasses:
<hexology>
well setting CL_SOURCE_REGISTRY does actually seem to work
<hexology>
so far at least
<hexology>
pjb: i would append the path to my project to `ql:*local-project-directories*`?
<hexology>
what would be the advantage of doing it through quicklisp instead of directly through ASDF?
<Bike>
hmm. i wonder. certainly it would be convenient if implementations did provide macroexpansions. i'd have to survey if it's really workable
<pjb>
beach: note that 3.1.2.1.2.1 Special Forms "The set of special operator names is fixed in Common Lisp; no way is provided for the user to define a special operator. The next figure lists all of the Common Lisp symbols that have definitions as special operators." to me, this means that implementations are not allowed to add special operators.
<pjb>
hexology: yes. (push #P"/my/projects/" ql:*local-project-directories*) ; it also looks in subdirectories.
<pjb>
hexology: with ql:*local-project-directories* you can shadow systems that are in quicklisp.
<pjb>
hexology: also, dependencies will be installed automatically by quicklisp (not by asdf).
<hexology>
i see
<Bike>
well, that says users not implementors
<hexology>
so i could invoke my repl this way for example: sbcl --eval '(push (merge-pathnames #P".") ql:*local-project-directories*))' --eval '(asdf:load-system "my-project-system")'
<Bike>
the other tricky thing with code walking is extensions to function names. sbcl has a couple of those. i guess it's not that hard to deal with generally though
<hexology>
(i think i have an extra ")" in there)
<Bike>
let's see... for clasp, i think the only weird one would be the ffi defcallback, but that could probably be expanded into a sham function call that doesn't actually work
<pjb>
Well, 3.1.2.1.2 only defines function forms (with a symbol), and lambda forms (with a lambda expression). I don't think extensions would be allowed here.
<pjb>
extensions to function names could be used only in (function …) AFAICS.
<Bike>
it's not an extensions to the kinds of forms, just to the kinds of special forms
<Bike>
in function, yes
<Bike>
i wonder if it would be ok to provide sham expansions of (special-op ...) to (eval '(special-op ...))
<Bike>
no it wouldn't, they can refer to the lexical environment
MajorBiscuit has quit [Ping timeout: 245 seconds]
jeosol has quit [Quit: Client closed]
frgo has quit [Read error: Connection reset by peer]
bitmapper has joined #commonlisp
rogersm has quit [Quit: Leaving...]
wbsl has quit [Remote host closed the connection]
<hexology>
https://www.sbcl.org/manual/#Defining-Constants in this section, why do they recommend using this macro instead of wrapping your DEFCONSTANT in an (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) ?
<hexology>
is it because you might invoke defconstant _not_ at top level?
<Bike>
hexology: wrapping in that eval-when would not solve the problem; subsequent recompilation of the file would result in an error just the same
<hexology>
ah, i see. so it solves the problem of getting a surprising error upon first load, but does not solve the problem of subsequent recompilations
<Bike>
hexology: alexandria has a define-constant macro that's better and covers this case
<Bike>
(it's basically like this, but tests that the object is the same under some given predicate, and provides a restart)
<hexology>
thank you, i can use that
asarch has quit [Quit: Leaving]
<hexology>
huh, alexandria:define-constant didn't solve the problem for me
<hexology>
or perhaps i'm doing something else wrong here
wbsl has joined #commonlisp
cage has joined #commonlisp
<hexology>
wherease the recipe in the sbcl manual did work
<Bike>
hexology: you need to provide a :test, since eql is the default
<Bike>
in your case it will find that the new list is not eql to the old list and complain. if you have it use equal instead it should be fine
wbsl has quit [Ping timeout: 240 seconds]
nij- has joined #commonlisp
<hexology>
i see that now. i had assumed that it did the same thing as the recipe in the sbcl manual, which appears to instead check if the symbol is bound, and if so expands to (defconstant +foo+ +foo+).
nij- has quit [Remote host closed the connection]
<White_Flame>
yeah, that'll catch the case if there was a prior (defvar +foo+ ...) first, as opposed to just skipping the defconstant if already bound
<pjb>
Note: defconstant doesn't declare the symbol special, defvar does! So it's entirely incompatible.
<jcowan>
I'm astonished that eql is the comparison rather than equal, which after all is (roughly speaking) equality at the code level
nij- has joined #commonlisp
<Bike>
hexology: the equality check is what i meant by "tests that the object is the same under some given predicate"
szkl has quit [Quit: Connection closed for inactivity]
<hexology>
ah i see. so it's a question of whether you want greater control over the rebinding check, or whether you want to just ignore subsequent rebindings
wbsl has joined #commonlisp
<hexology>
jcowan: do you mind if i quote you on that? i'm writing an answer on stackoverflow using this information
<hexology>
otherwise i can just quote the hyperspec's use of the term "isomorphic"
<jcowan>
Sure.
<jcowan>
Quote me all you like
nij- has left #commonlisp [#commonlisp]
HaxCPU is now known as WaxCPU
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest7627
yauhsien has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
yauhsien has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
rogersm has joined #commonlisp
<dlowe>
"You can't prove I said anything" -- jcowan
frgo has joined #commonlisp
<Bike>
equal still wouldn't work for literal structs
<Bike>
if literals is what's meant by "code equality"
<jcowan>
True, which is why equal is not an exact match. (In Scheme, equal? may or may not do strut equality, but typically does.)
<jcowan>
s/strut/struct (aka record)
yauhsien has quit [Ping timeout: 244 seconds]
<dlowe>
I suspect eql was chosen just because it's the faster option
<jcowan>
Probably
<jcowan>
The fact that there is no way to compare structs for equality is bogus.
<Catie>
That's definitely something that "object-oriented languages" got right, being able to define custom equality predicates using dynamic dispatch
<dlowe>
there's a generic equals library running around
<edgar-rft>
a fact that is bogus?
<jcowan>
s/The fact t/T
<Bike>
eql is chosen because it's the default comparison everywhere else in the language (except for eq in a few silly places)
<dlowe>
it can definitely be done without dipping into the implementation
<dlowe>
but nothing else will use it by default
<jcowan>
You could sort of do it with read and print, I suppose
<Bike>
equalp will compare structs in CL
<Bike>
i don't know about scheme structs at all
<hexology>
ns12: that's the one i wrote an answer for :)
<hexology>
Catie: in general isn't that one of the complaints about CLOS?
<jcowan>
Scheme does not have equalp, so I don't have it firmly in mind
<Catie>
hexology: I think so yeah, that it's very powerful but not used in enough places in the base language?
<hexology>
not specifically equality predicates, but the lack of ability to hook into standard functionality
<hexology>
yeah
<hexology>
although even in python you can't control things like equality comparisons of built-in types. you'd have to subclass the built-in in order to add your custom equality hook
<hexology>
i think in compiled languages with multiple dispatch you can do basically whatever you want though, e.g. c++ and julia
<hexology>
and R i believe as well (using its S4 system)
<Catie>
D was what I had in mind, but it's probably available for a lot of languages
causal has joined #commonlisp
<jcowan>
Is it true in CL that eql implies equal?
<Catie>
In a lot of cases, no
<jcowan>
the obvious counterexample is circular lists
<pjb>
In general it's false. (let ((s1 "hello") (s2 "hello")) (values (eql s1 s2) (equal s1 s2))) #| --> nil ; t |#
<pjb>
Err, I mean, it's true. eql implies equal, no exception. equal doesn't imply eql.
<Catie>
The reverse is true though, equal very much implies eql
<pjb>
No, it's the opposite, see my example.
<pjb>
(eql a b) ==> (equal a b) ==> (equalp a b)
<Catie>
Ah shucks, I've gotten mixed up
<Catie>
Yeah, sorry about that
tyson2 has joined #commonlisp
yauhsien has joined #commonlisp
gxt_ has quit [Ping timeout: 268 seconds]
gxt_ has joined #commonlisp
morganw has joined #commonlisp
mon_aaraj has quit [Ping timeout: 245 seconds]
yauhsien has quit [Remote host closed the connection]
mon_aaraj has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 245 seconds]
yauhsien has joined #commonlisp
Lord_of_Life has joined #commonlisp
yauhsien has quit [Ping timeout: 268 seconds]
dra_ has joined #commonlisp
dra_ has quit [Remote host closed the connection]
waleee has joined #commonlisp
frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
karlosz has joined #commonlisp
pranavats has left #commonlisp [#commonlisp]
jeosol has joined #commonlisp
karlosz has quit [Quit: karlosz]
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
frgo_ has quit [Read error: Connection reset by peer]
tyson2 has quit [Remote host closed the connection]
jealousmonk has quit [Read error: Connection reset by peer]
frgo has joined #commonlisp
yauhsien has joined #commonlisp
notzmv has quit [Ping timeout: 240 seconds]
yauhsien has quit [Ping timeout: 245 seconds]
<jcowan>
pjb: The reason I was unsure is that it's not obvious, given (defparameter circ '#1=(1 . #1#)), that (equal circ circ) => T, given the definition "For conses, equal is defined recursively as the two cars being equal and the two cdrs being equal."
mon_aaraj has quit [Ping timeout: 268 seconds]
<pjb>
jcowan: indeed, equal and equalp cannot be applied conformingly to circular lists and structures in general.
<pjb>
but in the case (equal circ circ) equal uses eql to compare the cars and the cdrs first, so it's ok.
mon_aaraj has joined #commonlisp
<pjb>
On the other hand (equal '#1=(1 . #1#) '#1=(1 . #1#)) would fail to return in most implementations.
<jcowan>
whereas (eql circ circ) is clearly t
<pjb>
actually, (equal circ circ) wouldn't even call equal on the car and cdr, it would have detected that (eql circ circ).
<pjb>
indeed.
<jcowan>
But it is not a specific requirement.
<pjb>
(defun equal (a b) (or (eql a b) (typecase (cons (and (equal (car a) (car b)) (equal (cdr a) (cdr b)))) … (t nil))))
<jcowan>
The "For conses" sentence is a recursion without a base case
<jcowan>
Scheme specifically requires that if eqv? then equal?.
<pjb>
Well, the specification is lax, but any implementation worth its bits would test for eql first.
* jcowan
nods
karlosz has joined #commonlisp
mon_aaraj has quit [Ping timeout: 245 seconds]
MajorBiscuit has joined #commonlisp
mon_aaraj has joined #commonlisp
yauhsien has joined #commonlisp
_whitelogger has joined #commonlisp
yauhsien has quit [Ping timeout: 268 seconds]
frgo has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
frgo has joined #commonlisp
frgo has quit [Read error: Connection reset by peer]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Oddity has joined #commonlisp
parjanya has quit [Ping timeout: 264 seconds]
rogersm has quit [Quit: Leaving...]
lagash has quit [Ping timeout: 255 seconds]
jamesmartinez has quit [Ping timeout: 260 seconds]