<dbotton>
along the same lines is there a way to call directly which method is called in a series of such overridden methods, not just call-next-method?
<dbotton>
in most langs can just cast the object to an ancestor and make the same call
<dbotton>
(sorry I likely violate many CL terms in that.. trying)
lottaquestions has quit [Ping timeout: 255 seconds]
<hayley>
I don't think you can.
<dbotton>
I know I spent an hour today trying things.. the best I got was using change-class (was a possibility in this case) but that is ugly
<hayley>
I'd be tempted to say something else isn't designed right if you need to skip "customisations" done by one subclass.
<hayley>
...and there isn't a way to skip over that already.
<dbotton>
I think this is the second thing CLOS really is a let down with
<hayley>
Biased, but I think you are shooting the messenger. If it is necessary to ignore methods specialised on some subclass, and the subclass is not able to defer to the superclass already, the inheritance relation seems wrong.
<dbotton>
there are times where a single method needs to skip back a generation
<yitzi>
dbottom: Generic functions in Lisp aren't designed to be a "single call" mechanism. Although less common there are other method combinations. http://clhs.lisp.se/Body/07_ffd.htm
igemnace has quit [Ping timeout: 248 seconds]
jeffrey has joined #commonlisp
<yitzi>
Meant dbotton.
<hayley>
There are?
<yitzi>
Maybe not?
<hayley>
Oh, I was responding to dbotton's message, not anything on "other method combinations".
<yitzi>
Gotcha
<hayley>
It smells wrong to have to "jump over" a superclass, because that sort of behaviour is harder to reason about, if a method can be ignored sometimes, and this is not obvious by, say, the DEFMETHOD form alone.
<dbotton>
It is not that things can not be restructured, it is that it adds complexity to do so. For example I have a grandchild that runs some library as its grandparent but its parent runs a different one. To the user of the objects they don't need to see the underlying code. Yes can pull out the mutual code but it is smoother in this case to just for that method of the grandchild skip the parent.
<Bike>
you could do some mop stuff to impart a different method call protocol that would let you do other stuff, though a c++ style upcast could probably not be done sensibly.
<dbotton>
For sure agreed casting not a good way
<Bike>
i don't understand your example.
<Bike>
"runs some library as its grandparent"?
<dbotton>
I want to say some external say c code
<dbotton>
In a case like this can just move that code to a function and call from grandparent and grandchild
<hayley>
It only appears to be "smoother" in a local sense; trying to reason about some other class in the inheritance hierarchy would be much harder.
<dbotton>
The user of such a hierarchy doesn't see it
<Bike>
no, i mean i don't understand the example you're trying to explain at all. I don't know what it means.
<Bike>
if you mean you have A a subclass of B a subclass of C, and some gf that should do thing 1 on A and C and thing 2 on B, i'd think the usual solution is to rearrange the hierarchy a bit
<Bike>
for example split up B's behavior into two classes, and then have A not subclass the mixin that controls the gf behavior
<dbotton>
That is hardly smoother to the end user of an API
<dbotton>
Let them see a clean interface and hierarchy, internally create the mess, so factoring out the code and A and C call some function with common code
<Bike>
this example is kind of too abstract for me to get a handle on what the API even is here.
<Bike>
i'm inclined to think for example that if the API lets the programmer define a new subclass of A, the programmer is going to be kind of confused if the subclass acts like the grandparent because A does a special override.
<Bike>
i don't know if that is what is meant by "smoothness"
<Bike>
and fundamentally i don't really understand why A even inherits from B
<dbotton>
I think part of the confusion I am creating for others is that the OO hierarchy is used not extended in most cases.
akoana has joined #commonlisp
<dbotton>
OO could perhaps even be replaced with a packaged hierarchy
<dbotton>
but lisp packages are not "modules"
<dbotton>
My issue is still no completely thinking in Common Lisp
karlosz has joined #commonlisp
lisp123 has joined #commonlisp
karlosz has quit [Client Quit]
lisp123 has quit [Ping timeout: 256 seconds]
jeffrey has quit [Quit: Client quit]
igemnace has joined #commonlisp
waleee has quit [Ping timeout: 255 seconds]
lottaquestions has joined #commonlisp
Bike has quit [Quit: Lost terminal]
Bike has joined #commonlisp
<beach>
Good morning everyone!
mixotricha has quit [Ping timeout: 252 seconds]
tyson2 has joined #commonlisp
<semz>
good morning
pranavats has joined #commonlisp
tyson2 has quit [Ping timeout: 240 seconds]
<masinter>
good morning
<hayley>
Good morning masinter!
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 248 seconds]
Bike has quit [Quit: Connection closed]
prokhor_ has joined #commonlisp
yauhsien_ has joined #commonlisp
yauhsien has quit [Read error: Connection reset by peer]
hashfunc1f17 has joined #commonlisp
<hashfunc1f17>
does sbcl have a built-in procedure for flattening a list?
<semz>
hashfunc1f17: Probably not, but Alexandria's FLATTEN is likely preferable anyway since it's more portable.
bilegeek has joined #commonlisp
<hashfunc1f17>
semz: ok thanks
<CodeBitCookie[m]>
Good Morning Everyone!
hineios0 has joined #commonlisp
hineios has quit [Ping timeout: 255 seconds]
hineios0 is now known as hineios
artchad has joined #commonlisp
mixotricha has joined #commonlisp
yauhsien_ has quit [Remote host closed the connection]
artchad has left #commonlisp [ERC 5.4 (IRC client for GNU Emacs 28.1)]
yauhsien has joined #commonlisp
lisp123mobile has joined #commonlisp
lisp123 has joined #commonlisp
<lisp123mobile>
mfiano: With that line of thinking, you may be drifting into typed languages, static typing might be better then
<lisp123mobile>
since it’s a compile time check and not run time
<lisp123mobile>
maybe try haskell?
<mfiano>
lisp123mobile: Um what?
<lisp123mobile>
you said you liked receiving error messages on no application method
<mfiano>
Who doesn't?
<mfiano>
What would be the alternative? UB?
<mfiano>
I like that conditions are signalled and I can handle them as I want, when I want.
<mfiano>
Completely. Dynamically.
lisp123 has quit [Ping timeout: 256 seconds]
<lisp123mobile>
why is my home pc randomly connecting lol
<lisp123mobile>
well sounds like you want type checking based on that pattern
<mfiano>
No as I mentioned, I moved _away_ from static analysis. It's a waste of time for little gain.
<lisp123mobile>
isn’t clos runtime type checking
<mfiano>
It incurs too much of a cost. Additive programming becomes impossible. Modularity suffers. I spend more time typing than programming. The signal to noise ratio decreases.
<lisp123mobile>
(typing on mobile so pardon the shortish messages)
<mfiano>
It is.
<mfiano>
It is also compile time.
<hayley>
"Runtime type checking" is irrelevant to "static type checking".
<mfiano>
Any good CLOS implementation will have a JIT compiler.
livoreno has quit [Ping timeout: 258 seconds]
attila_lendvai has quit [Ping timeout: 256 seconds]
<lisp123mobile>
I feel like overrelying on the condition system to handle runtime exceptions is more obscure vs directly supplying some form of type guards (or other checking of inputs)
<mfiano>
Common Lisp doesn't have exceptions.
<lisp123mobile>
exceptional situations then
<mfiano>
The two checks are not mutually exclusive
<lisp123mobile>
i just don’t see why one should get an error that there is no applicative method in a well designed program
<mfiano>
The condition system is extremely powerful and it's a shame not many people leverage it to its potential.
<mfiano>
You're missing the point.
<mfiano>
Common Lisp is an interactive language. Those conditions being signalled are for the developer.
<lisp123mobile>
ok
<lisp123mobile>
i get that
<mfiano>
If I make a human error during prototypical coding, I would have to add manual exhaustive type checking code to every function if I didn't leverage CLOS so much during that phase of development, if I didn't want garbage input to propagate through the stack where I would have to dig deep to find the root cause.
<mfiano>
CLOS helps me in various ways at being productive, this being a very small example.
<lisp123mobile>
a better CL linter would help a lot there
<lisp123mobile>
but i agree with you on that use case
<lisp123mobile>
i thought you meant in production code
<mfiano>
A CL linter is not practical. It would have to be integral to the implementation.
<lisp123mobile>
in other typed languages, static typing is basically autocomplete
<mfiano>
and even then would be very difficult and not reliable in all cases.
<mfiano>
Well, Common Lisp is not batch compiled.
<lisp123mobile>
if someone tries hard enough, I’m sure they could do something
lisp123mobile has quit [Remote host closed the connection]
<hayley>
A linter for Common Lisp would have to be quite spiffy; presumably it should keep up with new (and often incomplete) information while the user is writing code. I think it is practical, but tricky.
lisp123mobile has joined #commonlisp
<hayley>
One feature I'd like is to see a list of functions I haven't written yet, but have referred to from elsewhere. After writing (defun f () (g 42)) I probably should write a definition for the function G, for example.
lisp123mobile has quit [Remote host closed the connection]
<hayley>
An analysis toolkit for a non-interactive language has been on my list of interesting things to do for a while; the language is dynamically typed, but that does not imply that any type inference is useless.
<hayley>
mfiano: I think a Common Lisp implementation already has enough of its own business to mind. Say, it would not be a good idea for a type inferencer in a compiler to perform inter-procedural type analysis, if it is not possible for the implementation to invalidate code that depends on the inference, after redefining a function. But this could be quite useful for an external tool, and the tool does not have to generate code.
<mfiano>
I am not very interested in discussing this. I was simplying replying to one reason why I like CLOS.
<hayley>
There are some sorts of precise types that don't help a compiler generate better code, but are still useful to reason about, too. And a compiler might have to reason about types that a programmer shouldn't have to see; say, in JavaScript or Self, the compiler might need to reason about "hidden classes" or "maps", but those are an implementation detail, and reasoning about those does not help the programmer write better code.
ttree_ has quit [Ping timeout: 246 seconds]
<hashfunc1f17>
Has there been any attempt in history to develop a system that topologically sorts source code (functions) based off of the functions that said function depends on? Would this be too idealistic/unrealistic? I would appreciate some thoughts on this
<hashfunc1f17>
*greatly appreciate
<hayley>
You are out of luck if there is mutual recursion between functions.
<beach>
You beat me to it.
<mfiano>
You need a DAG to toposort
<hayley>
Well, in practise it's perhaps not an issue, if an arbitrary ordering of mutually recursive functions is acceptable.
<beach>
hashfunc1f17: What are you planning to use this information for?
<ck_>
this isn't common lisp specific, but anytime such a question pops up it amuses me to mention:
<ck_>
man 1 tsort
<lieven>
hashfunc1f17: unix has a tsort utility because historically the linker used that to order functions
<lieven>
heh ck_ beat me to it
<hashfunc1f17>
Does the linker still topologically sort functions? and if so, is there a way to get access to this information?
<beach>
hashfunc1f17: Common Lisp systems typically don't use the Unix linker.
<beach>
hashfunc1f17: And you didn't answer my question.
gxt has quit [Remote host closed the connection]
anticomputer has quit [Remote host closed the connection]
<hayley>
Topological sorting might be good for code locality, I guess. But as beach says, the Unix linker won't help for Common Lisp code.
<hashfunc1f17>
Also, would there be any value in such a system; if the source code maintained an invariant that all functions must be in their correct topological order?
gxt has joined #commonlisp
anticomputer has joined #commonlisp
<hayley>
(Ask me about basic block ordering; or don't, because I still don't understand it, after having written it.)
* beach
feels ignored.
<hayley>
Probably not, because you cannot make a topological ordering for mutually recursive functions.
<mfiano>
beach: This is what happens when the topic diverges. People get emotional and don't pay attention.
<hayley>
I don't see where emotions came into this conversation.
<beach>
mfiano: It's OK. I'll just stay out of the discussion.
<hashfunc1f17>
beach: my fault, at the moment I'm just curious if any attempts have been made to develop such a system
<beach>
hashfunc1f17: But you have been told repeatedly that when functions are mutually recursive, there is not such things possible.
mixotricha has quit [Ping timeout: 252 seconds]
<beach>
hashfunc1f17: However, you seem to ignore this crucial information and just keep asking as if it weren't important.
<hashfunc1f17>
beach: If we ignore the case of mutually recursive functions
ttree_ has joined #commonlisp
<hayley>
That is a big "if".
<beach>
Huge!
<hashfunc1f17>
And that's ok. I don't find myself writing mutually recursive functions everyday. I'm asking in the general day-to-day case
<hayley>
Still, I think that as long as the definitions of mutually recursive functions are close to each other spatially, the ordering doesn't really matter.
<mfiano>
I think the term "mutually recursive" is wrong here.
<mfiano>
That seems to imply a direct relationship, when any cyclic nodes will break the requirement.
<mfiano>
s/nodes/sub-graph/
<hayley>
Wikipedia defines mutual recursion as "where two mathematical or computational objects, such as functions or datatypes, are defined in terms of each other." (Though shouldn't it say two or more?)
<beach>
It should. Or even one or more.
<hayley>
hashfunc1f17: That doesn't sound right, but some have indicated to me that I don't know what the "general case" is anymore.
<beach>
What would be valuable though, would be a graph (which may contain cycles) of run-time dependencies, and perhaps compile-time dependencies with arcs of a different kind.
* hayley
now wonders how to use the who-calls interface of SLIME to generate a who-calls graph, to demonstrate.
<jackdaniel>
the fact that some functions are 'mutually recursive' only tells that the set has only a partial order; they still may be sorted
<beach>
Er, what?
<mfiano>
Yes, hayley pointed that out earlier.
<hashfunc1f17>
hayley: Ok. Do you think there is value in having a system that enforces source code locality? Or would that be too idealistic? For example: if you write a one-page program, and the system then organizes the program itself into their logically localistic files/directores based off of their topological order?
<jackdaniel>
beach: when you have group of mutually recursive functions then you can't order them, but you still can say which go "before" the group and "after" the group
<hayley>
"Enforcing" locality would be hard, because I'm not sure how you would quantify it, in a way that makes everyone happy.
<beach>
jackdaniel: But that's not what "partial order" means.
<jackdaniel>
beach: isn't 'partial order' a relation where you can determine only for certain paris of elements in the set you can say that one precedes another?
<hashfunc1f17>
Ok, I understand this. Now, the question is, should a philosophy be adopted make this system possible? And if the philosophy where adopted and the system developed, would this system be valuable?
<beach>
From Wikipedia "A partial order relation is a homogeneous relation that is transitive and antisymmetric".
<jackdaniel>
I don't see how that contradicts what I've said
<beach>
OK.
<hashfunc1f17>
hayley: For example. If the philosophy enforced that every top-level form be a DEFUN. Would that be a deal-breaker?
<hayley>
It very much would.
<hashfunc1f17>
hayley: Ok, and can you specify why you think that this would be a deal-breaker?
<hayley>
Some people like to declare variables, classes, methods, packages, among other things that aren't functions. Executing some other forms for effect at load-time is also useful. We may want to use macros at the top level. Why wouldn't it be a deal breaker?
<hashfunc1f17>
hayley: But what if you wrapped the variable declarations, classes, methods, packages, etc. within a defun in order for this philosophy to work?
<hayley>
But why the hell would you that?
<hayley>
I don't see the point of this philosophy.
<jackdaniel>
this discussion doesn't seem to go anywhere since there doesn't seem to be a target goal ,)
<mfiano>
Is there a way to force a FORMAT parameter to not be consumed?
ecraven- is now known as ecraven
mixotricha has joined #commonlisp
makomo has joined #commonlisp
ttree_ has quit [Ping timeout: 258 seconds]
<hashfunc1f17>
hayley: So that it would be possible to determine a topological ordering for all forms
<hayley>
That is absolutely not why we can't determine a topological ordering.
<hayley>
Say, (defun f () (g)) (defun g () (f)) are both DEFUN forms, but there is no topological ordering.
<mfiano>
To be able to make something similar to (format nil "~:d file~p" 42) work, instead of duplicating the argument as in (format nil "~:d file~p" 42 42)
<hayley>
Use ~:P instead of ~P (in this case).
<hashfunc1f17>
hayley: I understand that. Then there would have to be a canonical ordering in the philosophy as well; for example alphabetical. So function F would come before function G
<hayley>
There is a more general way to jump around the arguments to FORMAT, but I don't remember it.
<mfiano>
Thanks
<hayley>
e.g. (format nil "~d cat~:p" 5) => "5 cats"
<mfiano>
I completely forgot about that argument
<jackdaniel>
does ~p stands for puke, as opposed to consume? (don't answer that)
<hayley>
hashfunc1f17: Right. So, my next question, why does this idea crucially rely on every top level form being a function definition? Can't we still topologically sort DEFVAR, DEFCLASS, DEFMETHOD, etc by name?
<jackdaniel>
but oh defvar may depend on a function to initialize the variable
<semz>
~* and ~:* are the general ways
<ck_>
those are the ways.
<hashfunc1f17>
hayley: We most definitely could. but for simplicity-sake we would still wrap everything within a DEFUN
<hayley>
I don't see why simplicity is beneficial here.
bilegeek has quit [Quit: Leaving]
mm007emko has joined #commonlisp
<hashfunc1f17>
hayley: If all projects were developed and ordered based off of this philosophy, then all software would have a ubiquitious structure. meaning the velocity for development would improve as well as code comprehension
<jackdaniel>
that's a bold claim that would need to be backed by some data
<jackdaniel>
working on hunches, well, doesn't work
<hayley>
That doesn't explain why simplicity's sake is worth anything here.
<beach>
hashfunc1f17: Such software would not be able to use a huge chunk of what makes Common Lisp an interesting language.
<hayley>
I mean, it is not that much more complex to be able to find the "names" in DEFVAR, DEFCLASS, DEFMETHOD, etc forms.
<hashfunc1f17>
The only subjective part of this philosophy is that all forms be a DEFUN. After that all forms are: Alphabetically Ordered -> Topologically Ordered.
<hayley>
And then why is a topological sort the best way to structure a program? I can tell you that Java programs all have a common structure, but the structure is universally terrible. You need a file for every non-nested class definition, which means that trivial class definitions have to be stored in their own files, and very complex definitions cannot be spread across multiple files.
aartaka has quit [Ping timeout: 258 seconds]
<hashfunc1f17>
Because if the program is topologically sorted then the structure of the code is deterministic. The only thing you need to worry about is...your new function that you are defining
<aeth>
Java basically just sets in stone the trendy way to write C++ in the '90s
<aeth>
I guess Rust does the same thing, but with the '10s
<hayley>
Why is that structure the most pleasant structure to read?
<jackdaniel>
because when you read it you hear the metaphysical gears in your mind
<hayley>
Usually I structure my programs around a few concepts, which are often not reflected in the source code at all.
<jackdaniel>
and the coffee tastes better
MajorBiscuit has joined #commonlisp
<aeth>
a lot of IDEs change the presentation of the source code vs how it's represented on the filesystem these days afaik
<aeth>
the problem with wrapping global definitions inside of a defun is that they could be called multiple times now... which, if mutable, is going to be confusing because you might have just reset some global variable
aartaka has joined #commonlisp
<hashfunc1f17>
It's not about the pleasantness of the reading. It's about the objectivity of source code locality. If the locality of the source code can't be argued about, then there is no room for elitism, faster onboarding of new developers, and the structure of a codebase that is predictable for 10, 20, 50, 100 years from now
<hayley>
There is most certainly room for elitism: who decides what the "objective" decision on how to structure source code is? Apparently you.
<jackdaniel>
hashfunc1f17: that's another bold claim that requires proof.
<pillton>
You may as well get rid of defgeneric.
<pillton>
And the global environment.
<hayley>
Apparently macros hinder "faster onboarding of new developers", but programs without them tend to have painful amounts of code duplication. And it's not like the model of the problem is objective either, so you always have onboarding work.
<hashfunc1f17>
hayley: I have no say in how code is topologically sorted. But You have a say in how you usually structure your programs around a few concepts, which are often not reflected in the source code at all.
<aeth>
hashfunc1f17: or every 20 years the way to structure source code is going to change to some other in-style way, which might be better or might be worse, because software just follows trendy patterns and some of the trends are better and some are worse
<aeth>
assuming this codebase does last 100 years
<hayley>
That's not what I'm saying. Why is topological sorting the best way to structure a program? I have not yet received an explanation.
<aeth>
(of course, maybe it'll just become so messy that nobody will want to really touch it so it never gets refactored)
<jackdaniel>
hashfunc1f17: hayley has a say in his own program while you have a say on how everyone should structure their programs (hint, there is a difference)
<hashfunc1f17>
aeth: which is exactly what this philosophy could solve
<Shinmera>
This may be a hot take, but if your employees quabble about the order of definitions in their sources maybe the problem does not lie with the source code.
<hayley>
↑
<hashfunc1f17>
hayley: because it's an objective way to structure source code. if you have any other sorts that you know of, i'd be glad to hear them
<pillton>
Why are your new developers slow at "onboarding"?
<mfiano>
subjective*
<hashfunc1f17>
jackdaniel: When it comes to a company-wide codebase, I would take the objective approach
<jackdaniel>
and how is your approach objective?
<pillton>
Can you say something concrete?
<hayley>
The definition of toplogically sorting is agreed upon, but why is this algorithm any better than any other algorithm that is "objective"?
<mfiano>
and again with that term
<jackdaniel>
this is certainly a boring discussion, I'll better start doing something interesting
<jackdaniel>
laters
<hayley>
That is a subjective decision.
<mfiano>
This is getting to be amusing.
<hayley>
At least I have an excuse to practise cl-dot.
<hashfunc1f17>
hayley: i'm saying the algorithm is objective. is topological sort the best way to go? i have no idea. but it's a start
<Shinmera>
it's not objective.
<aeth>
is there even really a question about the order of the definitions in the source code? In general, you put the global defines first (maybe sorting constants, mutables, etc., or maybe mixing them up) and then the functions (etc) and they're generally in inside-to-outside order, so the "main" function (if there is one) in the file is at the bottom and you would read the control flow roughly bottom-to-top,
<Shinmera>
your algorithm is biased.
<aeth>
but of course it's not linear so there will be some arbitrariness in the middle
<Shinmera>
algorithms are made by humans. they are biased. your biases reflect in your algorithm.
<aeth>
but the style I'm talking about is just a general consequence of a language with CL-like semantics where you want some things evaluated first in order to show up later in the file and leaves a lot of room to taste
<hayley>
Your algorithm is objectively defined, it is a computer program. But a DECISION ABOUT AN ALGORITHM TO USE better be justified, and is not objective in the slightest.
<lieven>
I've always been a fan of Knuth's Literate Programming where you present your program in an order adapted to the reader. A lot of the trappings of Knuth's implementation are to deal with the very rigid demands of standard pascal but the core idea is sound and works well where I've had the discipline to use it.
<hayley>
"Because the algorithm is objective" provides absolutely no evidence for why I should choose that algorithm, over any other algorithm, because the definitions of all algorithms are objective.
lisp123 has joined #commonlisp
<hayley>
lieven: A live literate document would be interesting, like in <https://blog.bracha.org/illiterateProgramming/out/illiterateProgramming.html>. (The Newspeak language so happens to be very useful for literate programming, because the language has a sensible way to "patch" modules, but that is off-topic.)
<aeth>
I suppose the general (and probably a bit subjective) order for a file would be: defpackage in-package defgeneric defconstant defvar/defparameter defstruct/defclass defmacro defun/defmethod
<hayley>
Graphviz believes it needs to generate a graph that is 32,767 pixels wide, to draw the who-calls graph for Netfarm. Okay, that's no good then.
<aeth>
though a lot of these levels are actually interchangeable or debatable, you could subdivide a file by sections that repeat the structure, and once you start defining your own define-foo-bar toplevel forms via macros you're going to break the ordering
<hayley>
Yet the image is only 689 pixels tall. Surely it could, you know, spread the nodes out a bit more vertically?
<jackdaniel>
wide is a new black
lisp123 has quit [Ping timeout: 240 seconds]
<hayley>
Specifying a ratio= just makes the vertical space between nodes larger, which is not really what I had in mind. sigh
<Shinmera>
graphviz is very annoyingly fickle, yeah.
<hashfunc1f17>
OK. Thanks for all the input everyone. Hearing everyone's thoughts/ideas/criticisms on the topic was very interesting. As usual, there are many intelligent minds in this channel and I always learn something. Have a good night
<hayley>
I could probably "help" it by separating functions into a subgraph for each file, since my file structure is quite okay.
hashfunc1f17 has left #commonlisp [ERC (IRC client for Emacs 26.3)]
<hayley>
Well, now I remember that my rewrite rules for regular expressions has some mutual recursion between what needs to be matched in which constructors, as I had to restructure some code to make mutual recursion work. Otherwise there's no mutual recursion in (some subset of) the call graph.
pillton has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
retropikzel has left #commonlisp [#commonlisp]
<pjb>
hayley: topological sorting of definitions is a good way to structure source files. But it is unrelated to the structure of the program! Now, programmers shouldn't be concerned by the structure of the files or database used by their IDE to store the program. A good IDE should offer a feature of browsing and exploration of the sources independent from file I/O!
<pjb>
(cf. Smalltalk browser vs. Smalltalk source files)
<hayley>
Seems different programs in the Graphviz suite use different algorithms, with different results. "fdp" produces a less vertically challenged graph than "dot", and some parts are even readable.
<rendar>
contrapunctus, thanks
<contrapunctus>
rendar: Common Lisp supports a superset of what `cl-defun` in Emacs Lisp.
<rendar>
i was thinking: since fp is so fond of lists, why support var args, if you can have a function with only 1 arg which is a list of N elements..
<beach>
rendar: ^
<rendar>
ok
<beach>
rendar: But Common Lisp is not considered a language for only functional programming.
<hayley>
As my "software engineering" instructor was so fond of saying (without further explanation), "because it is useful".
<rendar>
beach, it bends things to be more practical i guess
<rendar>
hayley, yeah, good approach :)
<beach>
rendar: It is way more than bending. CLOS is so not related to functional programming.
<beach>
rendar: And CLOS is an important part of many modern Common Lisp programs.
<rendar>
uhm, i see.. CL.. OS?
<rendar>
(sorry i'm very new)
yauhsien has quit [Remote host closed the connection]
<beach>
Common Lisp Object System.
<rendar>
ok!
<semz>
afaik the functional programming people are also more fond of currying than lists of arguments since it simplifies some of their formalisms
yauhsien has joined #commonlisp
<rendar>
well, if CL is not a pure fp, scheme is? haskell?
copec has quit [Ping timeout: 246 seconds]
<beach>
Haskell is a good candidate, but Scheme is not.
<rendar>
i see
<jackdaniel>
I don't think that there are 'pure fp' - you have to print the result at the end of a day
<mm007emko>
Common Lisp is a multiparadigm language. It allows for all sorts of styles. Haskell is purely functional. Scheme is multiparadigm.
<rendar>
jackdaniel, i agree
<jackdaniel>
clojure puts certain emphasis for functional-programming friendly data structures and techniques
<mm007emko>
Much more than Common Lisp however it's not pure functional either.
copec has joined #commonlisp
<rendar>
OCaml, Scala, F# which are all of the ML family, i think are multi paradigm too, since they put emphasis on fp, but they print the result
* hayley
wonders if "fdp" just needs a few more seconds in the oven of simulated annealing, in order to produce a visually pleasing result.
<mm007emko>
Scala? ML family?
<rendar>
mm007emko, isn't that true?
<beach>
Language comparisons are not really on topic here, though.
<hayley>
I was not aware ML programmers had the same issue defining ML, as we do for Lisp.
<mm007emko>
Never thought of it that way. It looks (and feels) very different from F# or Ocaml
<rendar>
mm007emko, hmm, i see, i'll look deeper into that
<mm007emko>
rendar I don't want to dispute that. I had some experience with Scala and F# and they were quite different and therefore I never thought of Scala being an ML family language.
lisp123mobile has quit [Remote host closed the connection]
yauhsien has joined #commonlisp
<lieven>
since linked lists can be emulated with lambda you don't even need them :)
<lieven>
it's a weird question
<ck_>
lieven: was this meant for the other channel?
<lieven>
ck_: yeah sorry
<ck_>
no worries :)
igemnace has quit [Remote host closed the connection]
prokhor_ has joined #commonlisp
prokhor has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 272 seconds]
<mm007emko>
If you use Common Lisp for generating HTML, what do you use for (or what is the way you make) automated tests, please? My situation is: I have an application which uses CL-WHO to create its GUI using HTML (and unit tested by FiveAM). I'd like to automate UI testing, at least to check whether all the elements which should be there are displayed (and
<mm007emko>
possibly in a correct order). What would you suggest? A proper JavaScript-based UI testing framework (yuck!), a library for traversing HTML DOM run within unit tests (which one?) or scr*w it and use CL-PPCRE? Thanks!
lisp123 has quit [Ping timeout: 256 seconds]
MajorBiscuit has joined #commonlisp
<jackdaniel>
crossing fingers and hoping for the best - the most widespread testing technique :)
<jackdaniel>
(for UI)
<jackdaniel>
+ manual tests
<mm007emko>
:-D Yes but especially the "manual tests" is quite a vexing part.
<mfiano>
Funny story. I once talked to Edi about why he didn't include cl-who in Common Lisp Recipes next to the other recommendations, and his answer was simple: cl-who is buggy and beyond repair. That speaks volumes if the author himself cannot even recommend it.
lisp123 has joined #commonlisp
<mm007emko>
Never realised that, thanks for the heads up:) . He uses CL-MARKUP in the book...
<lisp123>
mm007emko: I suggest ditching CL and using Clojurescript
<lisp123>
Using server-side CL frameworks for web may be a 'fun' hobby, but its really far behind the state of play
<lisp123>
Now, if you can do CL + WebAssembly (hopefully see that soon with DOM manipulation), that will a game changer
<mfiano>
I have worked professionally in both backend and frontend CL web development.
<mfiano>
I think such comments should not be part of this channel regardless
<lisp123>
Benefit of ClojureScript is that it transpiles nicely and is more or less complete subset of Clojure
<mfiano>
This is not a channel for dissuading people from using Common Lisp.
igemnace has joined #commonlisp
<jackdaniel>
true web developers use html with no script, they program in html using butterflies
<lisp123>
Being honest about CL's weaknesses is not a bad thing
<mfiano>
It's only weak because you have not worked professionally with large integrated and capable in-house web systems.
<mfiano>
I have.
<jackdaniel>
and yes, recommending to 'ditch cl' kind of sounds bad on #commonlisp channel
<mfiano>
Therefor your opinion is just that.
<Josh_2>
Modern web dev is a disaster, its a good thing that CL has not fallen into that rabbit hole
<Josh_2>
simple HTML+CSS websites with only a little bit of JS are a pleasant site when compared to the average React/Vue site
<lisp123>
mfiano: Did you really use CL as front-end for 100k users+?
<hayley>
Why does the user count matter?
<mfiano>
Yes, we were responsible for a Snapchat service.
<jackdaniel>
why all font-ends must be for 100k users+? commercial deployment is often for much smaller userbase
<jackdaniel>
pushing for obfuscated technologies to squeeze 1KB / user is google thing
<mfiano>
I dont know how many users we were getting, as I didnt have that information.
<hayley>
I've used org-mode to generate pages read by very many people. Can we make org-mode a trendy web framework?
<mfiano>
But it was "a lot"
leeb has joined #commonlisp
<jackdaniel>
is irc a good communication channel? sure; would it be good had 100k active users been participating here? nah
<hayley>
("very many" is probably too many; "a fair few" is as imprecise but more accurate.)
<mfiano>
Also, I'm in the process of preparing a resume for another Common Lisp web development position I was offered.
<mfiano>
Not that I like the web _at all_, but I am familiar enough with it, and it's CL, so.
<mm007emko>
I had my reasons I switched this project from Clojure to Common Lisp. I'm not trying to badmouth any of these languages. They are awesome. However all I need is client-server GUI over a server application. It will be run on a headless server, checked from Windows, Linux and Android devices. Plus, since it's a part of my Ph.D. thesis, it will be (in
<mm007emko>
a simplified form) used as a teaching device for my lectures. Originally I thought about CAPI or Qt, then I decided to go web. My past experience of writing websites for money is like from 2008-2015, so server-side + a bit of Javascript. Then I went to desktops / backends, then to academia. Guess what, multipage apps + a bit of JavaScript and
<mm007emko>
XMLHttpRequest still work, they aren't slow if you don't use a ton of bloat and for this application (a couple of tables, charts, a network drawn in SVG etc) it will do just fine.
<Josh_2>
What about CLOG?
<jackdaniel>
mm007emko: check out clog by dbotton
<lisp123>
mfiano: In any case good luck with the new role, doing full time work CL is always good
igemnace has quit [Remote host closed the connection]
<lisp123>
mm007emko: See if you are using HTML + JS already, then I don't see the need for CL for front-end - CL-WHO has terrible syntax IMO
<Josh_2>
Spinneret :sunglasses:
<lisp123>
Parenscript is also awkward
<lisp123>
I haven't tried that one
<mm007emko>
Yes, I've tried CLOG and I'll definitely look into it in the future. It's on my list of things to learn.
<Josh_2>
PS is good once you get used to it, however it is missing ES6 features and promises :sob:
<Josh_2>
This is a PITA if you are trying to copy some example code for say the Stripe JS api and it uses Promises
<Josh_2>
Per request JS generation is great :sunglasses:
<lisp123>
What's that?
<mm007emko>
I kind of got used to Parenscript to inline a pieces of JS into pages. If I had to use anything more sophisticated (ES6 really is a far cry from what I was paid for in pre-Chrome-and-V8-engine era) then I'd write in JavaScript and link it to the page.
<Josh_2>
lisp123: same way you can generate different bits of HTML depending on user input you can ofcourse do the same with JS
<mm007emko>
And speaking of CL-WHO and horrible syntax ... well, I don't disagree. That's the reason I kludged a couple of macros and compose the page of these "components".
<Josh_2>
Spinneret makes it very easy to do that, I cannot speak for CL-WHO though
<lisp123>
Josh_2: Ah ok, yeah that stuff rocks
<mm007emko>
I'm looking into Spinneret documentation right now. Yes, it has a couple of goodies, I should have probably do my own research rather than simply picking up "Lisp for the web" and think "yes, that's good enough for me, this will do."
<mm007emko>
Looks like CL-WHO on steroids
<mfiano>
I have been using Spinneret for years, and it is indeed very nice to work with.
<mfiano>
I funded the project during its early development after trying about a dozen others and found it to be the most promising.
Oddity has quit [Ping timeout: 246 seconds]
<lisp123>
does it handle DOM events?
<mm007emko>
If I think of that ... I don't really have that much of HTML code written yet so it's maybe worth switching to Spinneret now rather than later; I sent some money to CLOG project since I hope this one will survive.
<mfiano>
It is for generating HTML, so no?
<mm007emko>
DOM events? HTML generators usually don't do that.
<mfiano>
Yeah, that was a weird question.
<lisp123>
Well any serious website would be handling DOM events....
<mm007emko>
You can use Parenscript for that or include javascript.
<Shinmera>
Things are going to slow down from here, but we should be able to reach the goal (the sooner the better).
causal has quit [Quit: WeeChat 3.5]
trumae has joined #commonlisp
homie has joined #commonlisp
rodicm has quit [Remote host closed the connection]
rodicm has joined #commonlisp
morganw has joined #commonlisp
jkamat is now known as jgkamat
anticomputer has quit [Ping timeout: 240 seconds]
anticomputer has joined #commonlisp
joast has joined #commonlisp
kpoeck has quit [Ping timeout: 252 seconds]
JoshYoshi has joined #commonlisp
Josh_2 has quit [Ping timeout: 256 seconds]
<JoshYoshi>
hmm
JoshYoshi has quit [Quit: Gotta go fast!]
Josh_2 has joined #commonlisp
<dbotton>
mm007emko the underpinnings of CLOG are 12 years old and the work I am doing on CLOG is about tools, and license is bsd so survival is guaranteed.
<dbotton>
mm007emko thanks for the monetary incentive :) It is always a plus (plus ego, plus coffee, plus plus :)
<mm007emko>
You're welcome:) I'd like to help but unfortunately I have no time right now to join a pretty big project.
kpoeck has joined #commonlisp
<dbotton>
is ok when time is right :)
<dbotton>
I should be release the first plug-in soon and work on docs for it
<dbotton>
I am hoping most will like the idea and wrap their CL or JS code as plugins to use in the builder and CLOG in general
orestarod has joined #commonlisp
<mm007emko>
Sounds good
<mm007emko>
I believe that nowadays CL community really needs an open-source truly universal UI framework.
<homie>
that would be amazing
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
<homie>
i ran through the clog tutorials last weekend and am looking forward to watching it grow. very cool stuff, dbotton
ttree has joined #commonlisp
molson_ has quit [Remote host closed the connection]
molson has joined #commonlisp
McParen has joined #commonlisp
tyson2 has joined #commonlisp
MajorBiscuit has quit [Quit: WeeChat 3.5]
<Josh_2>
mm007emko: different McClim backends?
<mm007emko>
Doesn't sound like a bad idea.
<Josh_2>
A McClim for web, windows, mac, linux :sunglasses:
<mm007emko>
Oh yes. Imagine trying to explain to your Windows users that they have to install X11 on their machine to run an application that looks like a bit 30 years out of place on their Windows 11
<Josh_2>
Yes they have to do that now
<Josh_2>
but not if there was a native backend
<mm007emko>
exactly
<Josh_2>
When I'm a millionaire perhaps :joy:
<mm007emko>
If I was a millionaire I would buy LispWorks for all platforms and use CAPI.
trumae has quit [Read error: Connection reset by peer]
trumae has joined #commonlisp
<McParen>
Maybe pursuing Windows/Mac users and their daily changing UIs is a relative waste of time.
<McParen>
The main reason why theyre constantly changing things is because they are aware the competition cant catch up and will always by definition look "outdated".
rodicm has quit [Ping timeout: 256 seconds]
tyson2 has quit [Remote host closed the connection]
<mm007emko>
Question is how much the users really value that. At work, our workstations come with Mate desktops pre-installed. That's ... well ... Gnome 2. That's some 20 years old thing. Guess what - it works and we generally like it (though I use Plasma 5 at home)
<McParen>
The users likely value being "fashionable" a lot, but if you know that you cant win the arms race, the best approach is not to waste limited ressources trying.
defaultxr has joined #commonlisp
<McParen>
90s UIs are still perfectly fine.
leeb has quit [Ping timeout: 256 seconds]
<mm007emko>
Home users usually yes. Ones who use computers as productivity tools not so much. I can imagine I would get away with deploying a McClim based application at work. To home home users, especially those who use Macs and want perfection, not so much.
karlosz has joined #commonlisp
<dbotton>
That is why I choose to use to write my UIs with webkit control to render them (ie clog) my UI looks right always even systems of the future
<mm007emko>
Nowadays that's probably the best thing to do.
<dbotton>
It has been that way for some time
<dbotton>
Skype, Discord, etc
karlosz_ has joined #commonlisp
<mm007emko>
I remember when the first version of Chrome was released. It's not so long ago ... but I feel like a fossil:-D
<dbotton>
The superpower of clog is that you write your UI like you would for gtk, qt, etc not a web page
<dbotton>
and you get remote UIs for free on terminals called browsers :)
karlosz has quit [Ping timeout: 240 seconds]
karlosz_ is now known as karlosz
<McParen>
mm007emko: some of us remember when windows was first released. ;)
pfd has quit [Quit: Client closed]
<edgar-rft>
around 1998 or 1999 I had a Windows demo version on approx. 20 diskettes :-)
<contrapunctus>
Any guesses as to why my program doesn't see certain methods when run from the CL package, and does when run from the package they're defined in?
kpoeck has joined #commonlisp
<ck_>
is this some sort of trick question
<contrapunctus>
ck_: not really
<ck_>
then go inspect the exports of the packages in question and find out what the reason is that way, is my suggestion
<contrapunctus>
Oh, clarification - my program has certain methods called `foo`. When I run my program from the CL package, _some_ of the `foo` methods are run, and others are not. When I run it from a different package, all the methods are run.
<contrapunctus>
methods are * called
<contrapunctus>
Which is bizarre, because they're all defined in as well as called from the same package.
mm007emko has quit [Quit: Client closed]
<ck_>
but do all the specialized parameters refer to external symbols of the package, or only to some
<contrapunctus>
ck_: I think it did have to do with that. I had EQL specializers in the methods, but they used `'symbols`; changing them to keywords seems to have fixed it.
<ck_>
are you using slime?
<contrapunctus>
ck_: yes
<ck_>
the slime inspector can be very helpful in these situations; I recommend inspecting the generic function next time, and looking at the list of methods closely
<contrapunctus>
Ah, thanks. I've been using it to inspect slots, but never thought of inspecting a generic function.
ns12 has quit [Quit: bye]
ns12 has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
<utis>
what does one do to get colour and bold face when printing to the terminal? simply printing \\033[1m doesn't seem to work.
<yitzi>
C style escapes like \033 don't work in Common Lisp.
<dlowe>
Try (format t "~c[1mHello, world~c~%" (code-char #x1b) (code-char #x1b))
<dlowe>
Er (format t "~c[1mHello, world~c[0m~%" (code-char #x1b) (code-char #x1b))
<utis>
dlowe: nice, thank you!
masinter_ has joined #commonlisp
<dlowe>
sbcl supports #\Esc instead of (code-char #x1b)
<dlowe>
probably other lisps do too
morganw has quit [Remote host closed the connection]
masinter has quit [Ping timeout: 244 seconds]
cosimone has quit [Read error: Connection reset by peer]
<utis>
great
kpoeck has quit [Quit: Client closed]
masinter_ has quit [Ping timeout: 240 seconds]
cosimone has joined #commonlisp
karlosz has quit [Quit: karlosz]
kpoeck has joined #commonlisp
Brucio-61 has quit [Remote host closed the connection]
scymtym has quit [Read error: Connection reset by peer]
dra has joined #commonlisp
kpoeck has quit [Quit: Client closed]
cosimone has quit [Remote host closed the connection]
cosimone has joined #commonlisp
masinter has joined #commonlisp
tyson2` has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
trumae has quit [Ping timeout: 248 seconds]
trumae has joined #commonlisp
shka has joined #commonlisp
tyson2` has quit [Remote host closed the connection]
thuna` has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 248 seconds]
<mfiano>
Well, as a last ditch effort, I am asking for someone to look at some rather complex logic for my project that passed all tests but fails to function correctly in production. I didn't write the original code but I haven't been able to contact who helped me write it originally.