jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
attila_lendvai_ has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
[deleted] has joined #commonlisp
random-nick has quit [Ping timeout: 268 seconds]
shka has quit [Ping timeout: 268 seconds]
attila_lendvai_ has quit [Ping timeout: 268 seconds]
livoreno has quit [Ping timeout: 268 seconds]
karlosz has quit [Quit: Client closed]
ec has quit [Quit: ec]
tyson2 has quit [Ping timeout: 268 seconds]
waleee has quit [Ping timeout: 244 seconds]
attila_lendvai_ has joined #commonlisp
joast has quit [Quit: Leaving.]
attila_lendvai_ has quit [Remote host closed the connection]
ebrasca has quit [Remote host closed the connection]
Colere has quit [Ping timeout: 268 seconds]
Colere has joined #commonlisp
hineios0 has joined #commonlisp
hineios has quit [Ping timeout: 268 seconds]
hineios0 is now known as hineios
Nilby has quit [Ping timeout: 244 seconds]
NotThatRPG has joined #commonlisp
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
joast has joined #commonlisp
fitzsim has joined #commonlisp
EsoAlgo has quit [Ping timeout: 244 seconds]
azimut has quit [Ping timeout: 268 seconds]
kingofcsu has joined #commonlisp
kingofcsu has left #commonlisp [#commonlisp]
SR-71 has joined #commonlisp
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
son0p has quit [Ping timeout: 268 seconds]
bilegeek has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
Cymew has joined #commonlisp
MajorBiscuit has joined #commonlisp
pve has joined #commonlisp
ttree has quit [Ping timeout: 252 seconds]
ttree has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
ttree has quit [Ping timeout: 252 seconds]
son0p has joined #commonlisp
chimp_ has joined #commonlisp
Psybur has quit [Ping timeout: 252 seconds]
shka has joined #commonlisp
artchad has joined #commonlisp
notzmv has quit [Ping timeout: 268 seconds]
irfan has joined #commonlisp
_cymew_ has joined #commonlisp
[deleted] has quit [Read error: Connection reset by peer]
livoreno has joined #commonlisp
tyson2 has joined #commonlisp
_cymew_ has quit [Ping timeout: 255 seconds]
cosimone has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 268 seconds]
bilegeek has quit [Quit: Leaving]
<dim> hi there! so my latest changes to handling conditions in pgloader worked, thanks all who helped!
notzmv has joined #commonlisp
<dim> now I would like to find if I can capure the compiler notes and choose to output them in debug mode only (see https://paste.debian.net/1249834/)
cosimone has joined #commonlisp
<scymtym> dim: if you just want the textual output and not, say, the individual condition objects, you could bind *STANDARD-OUTPUT*, *ERROR-OUTPUT*, etc. to a string output stream around the COMPILE call to capture the output
<dim> scymtym: yeah I think that capturing is something I do in other places in pgloader, and that'd be good enough to get started
kg7ski has quit [Quit: ZNC 1.8.2 - https://znc.in]
aartaka has quit [Ping timeout: 252 seconds]
ebrasca has joined #commonlisp
kg7ski has joined #commonlisp
aartaka has joined #commonlisp
<dim> (with-output-to-string (*error-output*) (compile nil (lambda (x) (+ x "plop"))))
<dim> I though that would capture the output and return it as a string, but it doesn't (the output still gets printed in the slime buffer, and the return value is an empty string) ; and I can't remember how to do the capturing now, I have forgotten most of my CL it seems... help?
cosimone has quit [Remote host closed the connection]
Dynom has joined #commonlisp
random-nick has joined #commonlisp
gateway2000 has quit [Quit: Leaving]
gateway2000 has joined #commonlisp
igemnace has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
azimut has joined #commonlisp
cage has joined #commonlisp
frgo has quit [Ping timeout: 252 seconds]
<Shinmera> The conditions are not printed inside compile. They escape to slime or whatever else handles the toplevel and then get printed there, escaping your *error-output* binding.
<scymtym> there could be two problems: 1) different conditions are printed to different streams 2) calling COMPILE in a SLIME REPL vs. a plain REPL vs. in a non-REPL thread may result in different surrounding compilation unit setups (which can influence when problems are reported). (with-output-to-string (stream) (with-compilation-unit (:override t) (let ((*standard-output* stream) (*error-output* stream) (*trace-output* stream)) (comp
<scymtym> '(lambda (x) y))))) may address both issues
<scymtym> the code was supposed to be (with-output-to-string (stream) (with-compilation-unit (:override t) (let ((*standard-output* stream) (*error-output* stream) (*trace-output* stream)) (compile nil '(lambda (x) y)))))
attila_lendvai_ has joined #commonlisp
waleee has joined #commonlisp
attila_lendvai_ is now known as attila_lendvai
cage has quit [Ping timeout: 268 seconds]
splatt990 has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
<dim> (with-output-to-string (*error-output*) (compile nil '(lambda (x) (+ x "plop"))))
<dim> ahah, I forgot to quote the code to compile...
<dim> this works
<dim> scymtym: your complete solution looks better but returns nil at the moment
<dim> sorry, returns the text correctly, my bad
<scymtym> dim: no worries
<dim> now I need to see about capturing both the output and the return value from compile
<dim> (let* ((fun nil) (notes (with-output-to-string (*error-output*) (setf fun (compile nil '(lambda (x) (+ x "plop"))))))) (values fun notes))
<dim> that's the simple one, now on to the more complete one
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
maxz has joined #commonlisp
<scymtym> (multiple-value-bind (function warnings-p failure-p) … is not going to receive a second and third value since (setf fun (compile nil source)) discards any values but the first
<dim> yeah fixed now, thanks for review
<dim> I don't have a test env anymore on my local machine, so I have to commit and push and inspect the CI output, sorry
<dim> if I wanted to get back seriously on hacking pgloader I would invest some more time and have a local test env of course, but I'm just trying to fix it from a distance, if that makes sense
azimut has quit [Ping timeout: 268 seconds]
<dim> the link to the current changeset is https://github.com/dimitri/pgloader/pull/1411/files (which now includes a fix to what you mentioned last)
maxz has quit [Quit: Leaving.]
azimut has joined #commonlisp
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
minion has quit [Remote host closed the connection]
specbot has quit [Remote host closed the connection]
specbot has joined #commonlisp
minion has joined #commonlisp
frgo has joined #commonlisp
dBc has joined #commonlisp
<pve> Hi, is the correctable error signalled by make-package if a package already exists going to be of type "error"? So I should do (handler-case (make-package "MY-PACKAGE") (error (c) ...))?
<pve> or can it be a serious-condition?
<beach> Since it says an "error" is signaled, it should be an instance of ERROR.
notzmv has quit [Ping timeout: 268 seconds]
<pve> beach: ok, thanks.. so I can't assume it is of type "package-error"
livoreno has quit [Ping timeout: 268 seconds]
<beach> I'm afraid not. It sounds like a case for WSCL.
livoreno has joined #commonlisp
<pve> I guess I could have one handler for "error" and another for "package-error".
<beach> Well, PACKAGE-ERROR is a subtype of ERROR so the one for ERROR would be enough.
<pve> sure, I meant that if I for some reason wanted to access package-error-package then the second handler would be convenient
<beach> Oh, sure.
JoshYoshi has joined #commonlisp
JoshYoshi has quit [Remote host closed the connection]
Josh_2 has quit [Ping timeout: 268 seconds]
<Bike> oh, yeah, the package errors are both surprisingly specific and surprisingly vague. for clasp i took a while to set up some helpful restarts, but none of them are standard
masinter has joined #commonlisp
<Bike> (of course how often you'd need to fix package errors programmatically anyway is debatable...)
waleee has joined #commonlisp
<pjb> pve: the only thing that clhs make-package says is: A correctable error is signaled if the package-name or any of the nicknames is already the name or nickname of an existing package.
ldb has joined #commonlisp
notzmv has joined #commonlisp
<pve> pjb: yeah, I was a little unsure if "error" here meant an instance of ERROR
<jcowan> Bike: Where can I find a list of these package-related restarts?
<pjb> It definitely means an instance of ERROR. At least, it doesn't mean a "direct instance of ERROR".
<pjb> You can bet that clhs make-package was written before conditions such as package-error where defined.
<pve> ah, makes sense
<beach> There is a lot of that in the standard. It is as if they ran out of time and couldn't go through every page one more time to make sure everything was up to date.
waleee has quit [Ping timeout: 255 seconds]
[deleted] has joined #commonlisp
<Bike> jcowan: it's actually just one now that i look at it - resolve-conflict. you pass it the symbol you want to keep for whatever operation and that's what's used. e.g. if the A package uses the B package, and you EXPORT B::FOO from B which causes a conflict with A::FOO, you can resolve-conflict with either a::foo or b:foo and the one you pick will be accessible in A
<Bike> by doing shadow or unintern or whatnot
<Bike> i don't seem to have actually documented this outside of the debugger itself, oops
krjt has quit [Quit: bye]
<Bike> this is basically cribbed from sbcl, which briefly describes the mechanism in 7.11 of the manual
<Bike> its manual*
<ldb> so it is implementation dependent mechanism?
jealousmonk has joined #commonlisp
krjst has joined #commonlisp
<Bike> yeah, like i said
<Bike> the standard says it has to be a correctable error and that's it, i think
livoreno has quit [Ping timeout: 268 seconds]
<masinter> it wasn't a matter of running out of time. "is an error" was a way of allowing existing implementations to be compliant
<masinter> a political compromise
<beach> I see. Thanks for the explanation.
dstein64- has joined #commonlisp
seok- has joined #commonlisp
dstein64 has quit [Ping timeout: 268 seconds]
dstein64- is now known as dstein64
seok has quit [Ping timeout: 268 seconds]
dmgk has left #commonlisp [#commonlisp]
causal has quit [Quit: WeeChat 3.6]
dBc has quit [Quit: leaving]
[deleted] has quit [Read error: Connection reset by peer]
livoreno has joined #commonlisp
ttree has joined #commonlisp
ldb has quit [Ping timeout: 268 seconds]
Fare has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<jcowan> Bike: thanks. It's possible to portably refit restarts into Scheme, but I want to provide a list of what restarters should be associated with to various kinds of conditions. For example, (car 32) in sbcl only allows ABORT, whereas a (when a is not bound) provides CONTINUE, USE-VALUE, START-VALUE, and ABORT. None of this seems to be documented anywhere.
<jcowan> I know it's implementation-dependent, but I don't especially care which implementation I look at.
Fare has quit [Ping timeout: 268 seconds]
<pjb> jcowan: indeed, there are very few restarts specified by the standard. Again, conditions and restarts were a late addition to the standard, and they ran out of time to revise and put everything in a consistent state.
<pjb> So yes, it's implementation dependent.
<jcowan> Right. I just want to use a particular implementation or set of implementations as a guideline.
<pjb> So you can document and provide a high number of condition subclasses and restarts.
<pjb> I don't think any implementation is a model here.
<jcowan> I guess maybe looking at the source code for restart definitions is the Right Thing, though not ideal
<pjb> error handling code in general, could easily double or triple the size of any software.
<pjb> The best to do, IMO, is to take each of the API (the operators defined in CL, not the internal functions), and to define conditions and restarts for each of them according to the arguments they receive.
<masinter> look at HTML and WHATWG insisting on defining what browsers should do...
<masinter> for an example of the comparision between HTML 5.0 vs the W3C attempt to do XHTML
tyson2 has quit [Read error: Connection reset by peer]
igemnace has quit [Remote host closed the connection]
jeosol has quit [Quit: Client closed]
ldb has joined #commonlisp
Fare has joined #commonlisp
ldb has quit [Remote host closed the connection]
ldb has joined #commonlisp
tyson2 has joined #commonlisp
livoreno has quit [Ping timeout: 268 seconds]
notzmv has quit [Ping timeout: 268 seconds]
livoreno has joined #commonlisp
cedb has joined #commonlisp
<cedb> i might be a heretic but id like a tweaked CLOS with dot access syntax for slots, is that possible without a full blown reader macro?
<White_Flame> is (dot obj field field) too much of an ask?
<White_Flame> iirc that's the shape of some of the java interops that do dot traversal
<cedb> noo, but chaining them you know? obj.objinside.objinside'.field ... namean?
<White_Flame> right, (dot obj inside inside field (:aref 3) (:call foo x y z)) => ojb.inside.inside.field[3](x,y,z) ?
<cedb> same for hashtables, i use them a lot in scheme for work and (hash-table-ref t k) is a bit verboes (i know i could alias it but still, t.k or somehting like that
<White_Flame> but really, across many languages and many tools, it's not the syntax that's a challenge, but the semantic complexity
<cedb> oh i hadnt realize you can provided a chain to "dot" (clos noob, spend most of my time in scheme these days)
<White_Flame> I personally stopped using a lot of shortcuts like that because they end up being such an infinitesimal portion of my load, and just draw away from standard form
<White_Flame> and that's in multiple languages, not just lisp
<cedb> right
<White_Flame> this is a hypothetical DOT macro
<cedb> oh right
<cedb> yes that would be a nice hypothetical
<cedb> prefix is fine, its deeply nested things just to access some field
<White_Flame> right, since prefix lexical order is inverse of the traversal order
<cedb> especially when dealing with a lot of nested json for example
<ldb> jquery?
<White_Flame> so clearly we need postfix ;)
<ldb> XML has its query language, I think json has similar thing
<cedb> right but i parse json and then store it in an alist or a hash-table afterwards
<cedb> i could call a subprocess to do some jq but like... really??
<cedb> White_Flame: well, postfix is fine, loop is great
* cedb hides
<cedb> oh wait no thats infix
<ldb> so this library works for alist hash-table etc
<cedb> ah right i member stumbling upon access
<ldb> and it has DOT syntax, lol
<cedb> woupsy
<cedb> hehe
<cedb> doenst look like a very popular project, i was wondering like am thinking about this the wrong way if almost noone seems to be coding like that
<ldb> I was doing XSLT these days, was hoping I can do something like that with plump
<ldb> I think Xpath is not a bad design which is for similar situations
<cedb> I know its not "lispy" or wtv and im used to sexps, its a not anti-parenthesis thing, its just so verbose to access nested stuff with only functions and no special syntax
<ldb> I guess many lisp programmers avoids "other people's library", except for too well known ones like alexandria
<cedb> yes well alexandria is basically stdlib at this point
<cedb> schemers do use a lot of srfis though, but i guess CL kind of has a stdlib builtin in the lang
igemnace has joined #commonlisp
<ldb> chez is so far my favoriate scheme, I don't know other people's choice
<cedb> well you can always start a nice flame in #scheme with that question if you feel like it :)
<cedb> gerbil looks promising
<White_Flame> ldb: the existence of quicklisp and its quick adoption kinda speaks against people being anti-others'-library
<cedb> 40 years late but yes
<cedb> to be fair quicklisp is also useful to manage your own libraries
<cedb> nobody wants to pull in code manually in 2022
<aeth> very useful to have a ~/git where you checkout everything (yours and others')
<aeth> and then `ln -s` to that in ~/quicklisp/local-projects/ when you need to override the version in quicklisp with the latest (and remove the link when you no longer wish to do so)
<cedb> that sounds aehmm, messy?
<aeth> I guess you could try one more layer of hierarchy
<cedb> quicklisp on stow!
<ldb> I ln -s to asdf/
<Bike> i think i just don't usually write code with deep nested accesses. usually i'll access one layer in and bind that to a name, which i then maybe do some other stuff with.
<cedb> well yes, but that becomes a hassle when dealing with web apis
son0p has quit [Ping timeout: 268 seconds]
son0p has joined #commonlisp
cage has joined #commonlisp
<aeth> rewrite k8s in Common Lisp
<aeth> and then replace Quicklisp with an elaborate containerization scheme
<aeth> (not to be confused with Containerization Scheme)
MajorBiscuit has quit [Ping timeout: 268 seconds]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life_ is now known as Lord_of_Life
<beach> cedb: One should never access slots by name anyway.
<cedb> beach: ugh?
<beach> You should always use slot accessors, without referring to slot names.
<cedb> meh, sounds like oop nonsense to me
<cedb> even worse, java oop nonsense
<jcowan> Slot names make sense when creating/initializing/reiniiializing instances, though; that's better than using slot mutators.
<jcowan> Java actually isn't very OOPy
<jcowan> though you can write OOP Java if you follow three rules: use class names only in constructors, avoid == when comparing objects, and ...
<jcowan> (I forget the third, @#$**)
<cedb> i meant the whole "attributes have to be private, separate implentation from interface" thing
<_death> it's Common Lisp Sense
notzmv has joined #commonlisp
<ldb> generally it is good to not break abstraction
karlosz has joined #commonlisp
<cedb> tbh im not a fan of the generating symbols thing
<cedb> also im not talking about a fancy class that has a lot of invariants, i specifically mentionned just accessing nested structures
<cedb> moreover, abstraction noteq gratuitous indirection
karlosz88 has joined #commonlisp
<_death> OOP has exciting advice for you: the Law of Demeter
<cedb> meh not my thing, also CLOS has multimethods so the whole "dont couple classes" thing ehhhh
Fare has quit [Ping timeout: 252 seconds]
<_death> it's actually more generally applicable than "OO style"
<cedb> sure, its just a general "design principle" that doesnt say much, also implementation just always bleeds through
<cedb> all abstractions are leaky
<cedb> embrace the darkness
<jcowan> Up to a point, Minister. Bignums aren't leaky except in the sense that if your bignum exceeds memory it blows up.\
<_death> if things are nonsense and confusing, I suggest trying to suspend your strong beliefs and reflect on what you're being told for a while
<cedb> pffff
<White_Flame> there's a reason even list elements are available via defstruct :type list
<White_Flame> to give them each named accessors
irfan has quit [Quit: leaving]
<White_Flame> if not just a custom set of renamed c[a|d]+r accessors
<cedb> yes, the is that structs and classes are mostly hacks for some level of sanity when dealing with a dynamically typed lang
<White_Flame> no, it's to give an access interface if there's any change in the underlying
* Alfr wonders why we don't have cr?
<White_Flame> even for very simple things
<White_Flame> Alfr: (defun cr (foo) (identity foo))
<White_Flame> plus check type for listp I guess?
<Alfr> White_Flame, but that doesn't check it's a list.
<Alfr> White_Flame, :)
thomaslewis has joined #commonlisp
ecomcon has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
<cedb> yes defstruct :type list is a huge hack, youre abstracting away a list but still get an "object" with type "list"
<cedb> its useful sure, i use it, hack is not necessarily bad mind you
karlosz has quit [Remote host closed the connection]
<_death> it's the other way around.. :type list is when you have a list and want to generate accessors/constructor without too much boilerplate
<cedb> in fact thats like the best example of abstraction leak i could not think of :)
<cedb> i dont know what "direction" youre talking about, youre doing some abstraction like White_Flame said so that if the underlying struct changes implmentation (aka list) youre accessors still work. But you still don't get a proper type, thats why there is :name.
<White_Flame> if you need a type, you make a type
<ecomcon> in Ada, the `new` keyword can make a distinct type incompatible with its base type e.g. `type Amount is new Integer;` and the program could discriminate based on that type. is there a similar facility in CL?
<White_Flame> but if you want flexibility of type, it's important to have an access protocol
<aeth> yeah, which is why I tend to make macros to define such things rather than rely on defstruct
jmdaemon has joined #commonlisp
<aeth> because defstruct when defining a sequences leaves out the most important part, the type
<cedb> White_Flame: okay... so whats the point of :type list then instead of just defstruct?
<White_Flame> because it's compatible with other list-based tools
<White_Flame> or list-based data
<aeth> list-based data should be parsed with destructuring-bind imo
<cedb> White_Flame: right so youre access protocol is coupled with the implementation
<White_Flame> not really for single-field access, and you don't want to repeat the destructuring-bind field list everywhere either
<cedb> your, gmdnit irc english
<White_Flame> wat
<aeth> if you're doing single-field access on a list, you're using the wrong data structure, at least if it's not the CAR
<White_Flame> the protocol exists irrelevant of the way it was manifested (eg defstruct :type, vs defuns, vs defmacro generating a bunch of stuff)
<aeth> because now you've just admitted to using a random-access usage pattern on an O(n) data structure
<aeth> and comp sci algo professors everywhere are going to be disappointed in you
<cedb> hehehe
<White_Flame> aeth: why woudl that automatically be a problem?
<White_Flame> if you're getting list data, and need to peform occasional access of it's fields, that's the sort of thign you use
<White_Flame> none of this assumes that you're defining a datastructure
<cedb> you dont want occasional random field access to be linear ...
<White_Flame> this is all about accessing existing data
<_death> for example clauses in a macro might be lists like (foo bar zot) .. so are you saying (defstruct (clause (:type list)) foo bar zot) is a problem?
<aeth> yes?
<_death> how come?
<cedb> well not a big one for n=3 ofc but why do you want a list interface for clause in the first place
<aeth> a macro is a perfect example of where you'd want destructuring-bind if you don't just destructure it in the macro lambda list itself (which you can't do if it's a list that requires iterating over or something).
<aeth> in general, anyway
<White_Flame> it's just microoptimization, something you don't want to do early on
thomaslewis has joined #commonlisp
<cedb> but you cant do it later on cause you comitted to :type list
<White_Flame> and of course, as stated, this is for when there are multiple accesses to some given list, not just one scope where destructuring-bind would suffice
<aeth> not sure why using e.g. a hash table is a microoptimization
<cedb> ^^^
* White_Flame headdesks
<aeth> requires basically no thought to have a basic toolkit of three data structures (list, vector, hash table) instead of always leaning on a list
<White_Flame> no, there's no communication here, where the entire proposed situation is where you're given a list
<cedb> its 2022 and people still think everything in a lisp needs to be a list
<White_Flame> as the example of where defstruct :type list would come in
<White_Flame> cedb: please stop
<aeth> ah, so when you have to deal with a Lisper who decided that everything should be a list :-p
<White_Flame> no, when you're dealing with external data
<White_Flame> and data in combined use
<aeth> I just never see this come up
<White_Flame> anyway, there's some serious heels in ground here, not even talking about the answers to stuff brought up, so whatever
<White_Flame> right, defstruct :type list is not used that often
<_death> I am talking about a clause in a macro form.. you don't want to start complicating clause syntax with fancy data structures.. that's just poor style
<White_Flame> this is the example of where it is
<White_Flame> and it's an example of the spec acknowledging named field based access to other things as an abstraction instead of hitting the datastructure directly, as opposed to claiming this was some external OO-only practice
<aeth> _death: yeah, in a macro I would prefer to destructure in the macro lambda list, and then failing that (e.g. if it's a list of foos instead of a one-foo-only thing) I'd use destructuring-bind to basically match expectations with the rest of the macro (i.e. destructure the macro clause the same way as the rest of the macro). 95% of the time, if not 99% of the time
<White_Flame> and heck, defstruct :type vector is the exact same thing, but without the precious microoptimization losses
<aeth> uh, defstruct is inherently OO, just a simpler form of OO than defclass
<White_Flame> right
<White_Flame> it's not a Java-style OO import style
thomaslewis has left #commonlisp [#commonlisp]
<White_Flame> in terms of accessors, getters/setters/etc, which was why this came up
<White_Flame> the context isn't _that_ long gone
<_death> aeth: you are making too many assumptions about the hypothetical macro.. I'm asking, can you imagine how this choice of a :type list defstruct makes sense
<cedb> White_Flame: the context was all about setting up getters/setters instead of using slot names directly
<White_Flame> right, and the accusation was that this was some sort of leak from worse & more modern OO style
<White_Flame> but no, it existed as recommended style in lisp basically forever
<cedb> my point was simple, theres no point in being dogmatic about "encapsulation" or wtv if youre using :type list cause youre already leaking the implementation big time anyways
<White_Flame> the accessors do not leak the implementation
<cedb> no :type list does
<cedb> now i get your point, if someone passes you a list
<White_Flame> :type list is not part of the access protocol
<cedb> and you want nice names, but keep the list interface, sure defstruct :type list makes sense
<pjb> cedb: You know that only if you call type-of on it.
<pjb> someone passes you something.
<cedb> well also if you pass the struct back to someone
<White_Flame> right, and as I mentioned, it's not used very often, but it is an example that this is lisp style of creating access protocols instead of exposing raw type-specific access
<White_Flame> but, I think this has circled around enough
karlosz has joined #commonlisp
<White_Flame> there will always be good abstraction style recommendations from any language, whether they're naturally expressed in it or not
<cedb> s/from any language/from any language users
<White_Flame> sure, language community, libraries, support APIs, and documentation
<White_Flame> and these recommendations are there for a purpose, because stuff broke in hard to fix ways without them :)
<cedb> well idk why this thread reads like a flame, i asked for a simple reasonable (imo) library to do something that would be useful and I got "bad style" because "design principles"
<White_Flame> the issue sparked up from decrying the notion of not using slot names directly
<White_Flame> that gets people in many languages
<cedb> (dot object field) is still scoped properly, it wont break unless you change the field/slot name... which would change the name of the generated accessor anyways
<White_Flame> accessor names do not have to match slot names
<White_Flame> they do by default in defstruct, but defclass is the far more recommended tool
<cedb> okay let me clarify
<White_Flame> *slot accessor names do not have to match slot names
<cedb> (dot POD field1 field2 field3)
tyson2 has quit [Remote host closed the connection]
ecomcon has quit [Ping timeout: 252 seconds]
igemnace has quit [Remote host closed the connection]
thomaslewis has joined #commonlisp
<cedb> i mean i guess the thread would have been avoided had i said (dot nested-hash-table field field field) or (dot nested-assoc-list field field field) but i like having type info
thomaslewis has left #commonlisp [#commonlisp]
<cedb> and its perfectly reasonable to me to have types that are just a data structure
thomaslewis has joined #commonlisp
<cedb> "class" and "struct" are the way to do that in most dynamically typed langs, that doesnt imply that that "class" has to be an OOP class
<White_Flame> specifying a path like that is perfectly fine, but yeah each traversal step needs to know what it's doing; json, xml, objects, etc were all brought up
thomaslewis has left #commonlisp [#commonlisp]
<cedb> okay silly python example, some_dict["field1"]["field2"]["field3"]
<White_Flame> by each being an accessor name, that leaves it to clos dispatch to find the right method, which is fine
<cedb> but dont you see from my perspective writing a rest api that consumes json how much of an overkill that would be to just access different values within the json object i received?
<_death> there's a saying here, "what doesn't come through the head, comes through the legs".. some people (cultures? generations?) just need to make the mistakes to figure out what others have already figured out long ago (abstract data types, information hiding)
<cedb> omg how patronizing can you be
karlosz has quit [Quit: karlosz]
<_death> infinitely
<cedb> obv
<cedb> what im talking about is standard idiom in ocaml
<White_Flame> if you're traversing a json object, then each step would be a nested array or object reference. you should be able to statically determine that on a path-following macro
<White_Flame> hmm, no, only if that path is literal. It's still going to be almost just as runtime searchy as python
<_death> right, gratuitous pattern matching encourages these sort of issues
<cedb> _death: have you heard of algebraic data types?
<White_Flame> notsure what else you want from it
<White_Flame> (json-traverse "field1" "field2" "field3")
<White_Flame> (json-traverse obj "field1" "field2" "field3")
<cedb> _death: right cause ocaml idioms are so brittle people decided to write most theorem-provers in it
<_death> I think ocaml is offtopic here, anyway
<cedb> im bringing up the fact that people ingrained in OOP thinking seem to always think types="classes with abstracted implementation behaviour something"
<cedb> which is just not the case
<ldb> still in the dot syntax argument?
<cedb> led astray alast
<White_Flame> types in CL are far more abstract than classes
<_death> anyway it reminded me of that Steingold article, chuckle
<White_Flame> and I think in many of these CL situations and examples, you probably meant class instead of type anyway
<cedb> okay how can i define a type that involved compounded data in CL apart from a class?
thomaslewis has joined #commonlisp
<cedb> or a struct
<ldb> that's not a type but a schema
<White_Flame> the nature of the storage object is its class
<White_Flame> types can describe unions, tests, ranges, etc of varying elements
<ldb> and there are tools for verify data against a schema
thomaslewis has left #commonlisp [#commonlisp]
<cedb> ldb: thank you
thomaslewis has joined #commonlisp
<ldb> no reason to bind the concept of schema to type or class, I think
<White_Flame> so yes, when you're defining some new storage chunk category that contains multiple slots custom to it, that's a new class
<White_Flame> whereas (or my-class nil) is a type, and can't be expressed as a class
thomaslewis has left #commonlisp [#commonlisp]
<cedb> this kind of stuff is explicitly implemented with def-struct in steele's book: data Expression = Number Int | Add Expression Expression | Minus Expression Expression
<White_Flame> that's more related to BNF
<cedb> no thats a type definition that has nothing to do with syntax
<ldb> so if you want some constraint on data, no we don't do that by type/class here in CL, and which TS or Haskell they usually ended up in doing intense "typing body exercise" when more real world things are involved
<cedb> its not just a "constraint", its gives me a schema and names to refer to fields in the
<cedb> ah wtv
<ldb> you mean ADT gives your an induction hypothsis? ;)
thomaslewis has joined #commonlisp
<cedb> lol
<cedb> calisse
thomaslewis has left #commonlisp [#commonlisp]
<cedb> i knew i shouldnt use a recursive example
<cedb> ldb: anyways g2g and stop line noise, thanks for the links/recomandations
cedb has left #commonlisp [WeeChat 3.6]
Fare has joined #commonlisp
<_death> it's not difficult to come up with some utility to translate json data into a saner internal representation, here's some old code showing how it can look like https://plaster.tymoon.eu/view/3358#3358
<_death> this would create CLOS instances (of classes like PLAYLIST or SOUND) .. you could extend it to do some fancy validation while you're at it
<ldb> maybe json is such an abused choice that tools directly avaliable from xml get reinvented again
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
<_death> could of course go the usual approach and so something like https://plaster.tymoon.eu/view/3359#3359 (but use initargs, not slot names, ugh..)
<pjb> _death: you clearly need a macro to do both defclass and define-json-mapping!
<_death> you could (or use the MOP).. sometimes it's convenient, other times it's not (think separate authors, files, multiple mappings, etc.)
tyson2 has joined #commonlisp
<_death> I remember such conflation when writing Go (it has some weird stringy annotations)
Oladon has joined #commonlisp
dlowe has joined #commonlisp
aartaka has quit [Ping timeout: 268 seconds]
jeosol has joined #commonlisp
thuna` has joined #commonlisp
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
cage has quit [Ping timeout: 252 seconds]
<jcowan> List/vector based structures are O(1), because their size is fixed
frgo has quit [Remote host closed the connection]
<pjb> jcowan: list based structures still have O(n) n = number of slot access times to the slots.
<jcowan> If the size of your struct is 5, then access time is O(5), which = O(1). Only *unbounded* lists have access time O(n).
<pjb> jcowan: this is the finite universe argument. Remplace O() by the operation count.
thomaslewis has joined #commonlisp
<pjb> jcowan: the number of slots is unbounded. at least, when you use lists and possibly structures or objects (there's no SLOT-COUNT-LIMIT). For vector structures, there's the ARRAY-SIZE-LIMIT.
thomaslewis has left #commonlisp [#commonlisp]
<_death> as the length increases, accessing the last element takes more time
<_death> I'm guessing jcowan talks about list based defstruct-likes (tuples?)
<jcowan> Yes.
<jcowan> But "as the length increases" is incoherent when dealing with a fixed-size object. Its length by definition does not increase.
<_death> right, I'm not talking about a particular object
<_death> although length for a particular list could increase over time ;)
Dynom has quit [Quit: WeeChat 3.6]
frgo has joined #commonlisp
kami_ has joined #commonlisp
<kami_> Hello #commonlisp
<kami_> I'm trying to quickload :net.didierverna.clon from QL dist of 2022-04-01 with sbcl 2.1.1 and get 'Component :NET.DIDIERVERNA.CLON.TERMIO not found'
frgo has quit [Ping timeout: 268 seconds]
<kami_> My asdf has version 3.3.1
karlosz has joined #commonlisp
<kami_> I'd appreciate if someone with an open repl and (almost) matching versions could do a (ql:quickload :net.didierverna.clon)
Devon has quit [Read error: Connection reset by peer]
ldb has quit [Ping timeout: 268 seconds]
Devon has joined #commonlisp
karlosz88 has quit [Ping timeout: 252 seconds]
artchad has quit [Ping timeout: 268 seconds]
frgo has joined #commonlisp
<kami_> With ccl 1.12, I get the same error. Heading to clon's issue tracker. Sorry for the noise.
_cymew_ has joined #commonlisp
<kami_> Thank you, good night.
kami_ has left #commonlisp [ERC (IRC client for Emacs 27.1)]
morganw has joined #commonlisp
ldb has joined #commonlisp
ldb has quit [Read error: Connection reset by peer]
ldb has joined #commonlisp
ldb has quit [Client Quit]
_cymew_ has quit [Ping timeout: 268 seconds]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
ec has joined #commonlisp
thomaslewis has joined #commonlisp
cosimone has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
karlosz_ has joined #commonlisp
karlosz_ has quit [Remote host closed the connection]
Oladon has quit [Quit: Leaving.]
Oladon has joined #commonlisp
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
shka has quit [Ping timeout: 268 seconds]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
sjl has joined #commonlisp
Oladon has quit [Read error: Connection reset by peer]
Devon has quit [Ping timeout: 268 seconds]
frgo has quit [Ping timeout: 268 seconds]
<masinter> jcowan I think it started with the Interlisp record package... which turned into DATATYPE ... not sure whether DATATYPE preceded DEFSTRUCT but I think it did
<jcowan> Makes sense
<masinter> I think I made the record package on Lisp/360 and brought it to Interlisp in 73
gxt has quit [Write error: Broken pipe]
ec has quit [Write error: Connection reset by peer]
azimut has quit [Write error: Broken pipe]
anticomputer has quit [Remote host closed the connection]
frgo has joined #commonlisp
gxt has joined #commonlisp
azimut has joined #commonlisp
anticomputer has joined #commonlisp
ec has joined #commonlisp
frgo has quit [Read error: Connection reset by peer]
frgo has joined #commonlisp
azimut has quit [Ping timeout: 268 seconds]
azimut has joined #commonlisp
<jcowan> So another of the (few) contributions of Interlisp to CL. The one I know about is (car nil) = (cdr nil) = nil.
<masinter> LOOP
<masinter> the "iterative statement" was also brought over from Lisp/360
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
pve has quit [Quit: leaving]
lisper29 has joined #commonlisp
lisper29 has quit [Client Quit]
irc_user has joined #commonlisp
eddof13 has joined #commonlisp
<Kingsy> Hi, any sbcl users in here managed to get the stepper working in emacs?
karlosz_ has joined #commonlisp
attila_lendvai has quit [Ping timeout: 252 seconds]
karlosz_ has quit [Client Quit]
eddof13 has quit [Quit: Textual IRC Client: www.textualapp.com]
eddof13 has joined #commonlisp
random-nick has quit [Ping timeout: 268 seconds]
ebrasca has quit [Remote host closed the connection]