theruran has quit [Quit: Connection closed for inactivity]
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` has joined #lisp
<pjb>
fiddlerwoaroof: instead of renaming imports, you have define-symbol-macro; but indeed, this works only for variables.
Codaraxis has quit [Read error: Connection reset by peer]
Nomenclatura has joined #lisp
Oladon has joined #lisp
synaps3 has quit [Quit: Leaving]
shifty has joined #lisp
lemoinem is now known as Guest90750
Guest90750 has quit [Killed (tolkien.freenode.net (Nickname regained by services))]
lemoinem has joined #lisp
<fiddlerwoaroof>
defmacros work for functions, I guess
<pjb>
there are various defalias macros. For functions, (setf (symbol-function 'foo) (symbol-function 'bar)) can be used.
<pjb>
(or fdefinition for setfers).
Nomenclatura has quit [Quit: q]
narendraj9 has quit [Remote host closed the connection]
Grauwolf_ has joined #lisp
Grauwolf has quit [Read error: Connection reset by peer]
davr0s has quit [Ping timeout: 252 seconds]
davr0s has joined #lisp
bitmapper has quit [Ping timeout: 240 seconds]
pjb` has joined #lisp
pjb has quit [Ping timeout: 276 seconds]
synaps3 has joined #lisp
synaps3 is now known as duckbot
duckbot is now known as synaps3
pjb` has quit [Quit: ERC (IRC client for Emacs 26.1)]
pjb has joined #lisp
pjb is now known as Guest36095
Guest36095 has quit [Remote host closed the connection]
pjb` has joined #lisp
pjb` has quit [Remote host closed the connection]
pjb` has joined #lisp
pjb` has quit [Client Quit]
pjb has joined #lisp
EvW has quit [Ping timeout: 276 seconds]
<LdBeth>
yes set can do that
<LdBeth>
but cl lexicon provides more features such as late binding
ricman has joined #lisp
libertyprime has quit [Ping timeout: 265 seconds]
mindthelion has quit [Quit: Drops mic, and fucks off back to wherever he crawled out of.]
khisanth_ has quit [Ping timeout: 268 seconds]
toorevitimirp has joined #lisp
Oladon has quit [Quit: Leaving.]
<pfdietz>
(looks at cl-strings) This doesn't preserve element-type. That's very important: SBCL base strings use as little as 1/4 the space of general strings.
<pfdietz>
It would be better to implement those functions as methods that specialize on the string argument(s).
<pfdietz>
Interesting aside: the standard allows a lisp reader to produce base strings when reading string constants, if all the characters in the constant are base chars. When SBCL Is tweaked to do this, some failures occur in quicklisp. Some people assume the strings are always element-type CHARACTER.
libertyprime has joined #lisp
khisanth_ has joined #lisp
semz has quit [Ping timeout: 264 seconds]
theBlackDragon has quit [Ping timeout: 240 seconds]
theBlackDragon has joined #lisp
semz has joined #lisp
semz has joined #lisp
libertyprime has quit [Ping timeout: 240 seconds]
raghavgururajan has quit [Read error: Connection reset by peer]
libertyprime has joined #lisp
mindCrime has joined #lisp
synaps3 has quit [Ping timeout: 268 seconds]
mindCrime_ has joined #lisp
mindCrime has quit [Ping timeout: 264 seconds]
mindCrime has joined #lisp
mindCrime_ has quit [Ping timeout: 276 seconds]
mindCrime has quit [Ping timeout: 268 seconds]
gioyik has joined #lisp
gioyik has quit [Client Quit]
ArthurStrong has joined #lisp
abhixec has joined #lisp
davisr has quit [Remote host closed the connection]
davisr has joined #lisp
abhixec has quit [Ping timeout: 240 seconds]
davisr has quit [Read error: Connection reset by peer]
abhixec has joined #lisp
pfdietz has quit [Ping timeout: 260 seconds]
Kevslinger has quit [Quit: Connection closed for inactivity]
Bike has quit [Quit: Lost terminal]
karlosz has joined #lisp
toorevitimirp has quit [Ping timeout: 240 seconds]
<beach>
Good morning everyone!
<loke>
Hello beach!
<loke>
beach: I have a question about cluffer
<beach>
Sure.
<loke>
Question 1: WOuld you be able to put it on Quicklisp, in order for users to not have to manually download it?
<beach>
That's a good idea. I must have totally forgotten to do that.
<loke>
Question 2: Do you have a suggestion how to implement ranges? (similar to how Emacs implements text properties and overlays)
<beach>
Not really. I haven't given it any thought.
<beach>
Sorry.
ycjung has joined #lisp
<loke>
I was thinking of implement a rangeusing two cursors. That would track the start/end of the range properly. However, I need an efifcient way to find all ranges that cover a given cursor position.
<beach>
I see, yes.
<beach>
How many such ranges do you have?
<LdBeth>
loke: text property it attached to each characters
<ck_>
sounds like a job for an interval tree
<loke>
The root problem is that I need to be able to attach metadata to ranges of text.
<loke>
LdBeth: Yes, but that would use a _lot_ of memory for a large document.
<ck_>
but maybe you'll want to read the discussion on that during the xemacs / gnu emacs diverging. I believe there's a balancing tree for intervals in emacs since then.
<LdBeth>
loke: no, that can be shared between characters
<beach>
ck_: It might be more difficult than that, given that individual cursors can change independently, and that text can be inserted and deleted anywhere.
<loke>
LdBeth: exactly. Emacs implements this using ranges.
<LdBeth>
a character with properties could also be a pair of the codepoint and a reference to the properties
<LdBeth>
I don’t think emacs does this with ranges, since text properties can be preserved even cut and paste from a buffer to another
<loke>
LdBeth: text properties are implemented behind the scenes in Emacs using ranges
<loke>
But the ranges are not directly accessible. The API presented to the user is simply a set of text properties per character.
<beach>
An interesting idea would be to exploit the open/closed line idea of Cluffer. Conceptually, each character would be what LdBeth suggests, namely a pair of code-point and properties. But when a line is closed, a more compact representation could be computed.
theBlackDragon has quit [Ping timeout: 276 seconds]
<loke>
beach: So the ranges would be computed per-line?
<loke>
I guess that's a reasonable compromise.
<beach>
Yeah, something like that.
theBlackDragon has joined #lisp
<beach>
It sounds likely that there will be little variation within a line.
torbo has quit [Remote host closed the connection]
<loke>
Well, the peorperties describe things like fonts/colours/etc, as well as arbitrary other things), so there is a lot of variations.
karlosz has quit [Quit: karlosz]
<beach>
Within a single line?
<beach>
Such text would be very hard to read.
<loke>
beach: Think syntax highlighting.
<beach>
Oh, you wouldn't want to put that in the buffer itself.
<beach>
It is best to do that as a result of parsing.
<beach>
So it would be a property of the "view" instead.
<beach>
Otherwise, you will have to scan the entire buffer for each character you insert or delete.
<loke>
beach: that's what Emacs does :-)
<beach>
I am sorry to hear that.
<loke>
Well, not the entire buffer. It scans backwars to some synchronisation point (usually the beginning of the defun)
<beach>
Another reason to write a replacement.
<loke>
Indeed
<beach>
Yes, and that's a terrible idea.
<loke>
Clearly I want to make best use of your parser. I should probably take a look at its API to make sure I understand it.
<beach>
Sure. There is a paper describing it too.
<loke>
Link? :-)
<beach>
*sigh*
<beach>
Hold on...
asarch has joined #lisp
<beach>
metamodular.com/incremental-parsing.pdf
Oladon has joined #lisp
<loke>
beach: I note there is a Cleavir and Clearvir2
<loke>
The paper mentions Cleavir only.
<beach>
That's because Cleavir2 was created after the paper was written.
<loke>
Should I stick with 2?
<beach>
I don't think it matters much.
<beach>
But yeah, 2 might replace 1 one day.
<beach>
The parser does not depend on Cleavir though.
<beach>
But it will depend on Eclector, once scymtym adds the functionality to Eclector that I need.
<beach>
Then, if you want to do further analysis, you need Cleavir or some native analyzer.
gravicappa has joined #lisp
<loke>
I think it's time for my fifth (or so) rewrite of the editor core.
<beach>
Sounds like normal procedure to me.
<beach>
It is impossible to imagine a complete specification of things until different ways are tested in real code.
<loke>
So far, my “view” has been the visual representation of the buffer content on a line-by-line basis. I.e. every line in the cluffer buffer has a visual representation that has a given height.
<beach>
I think you need very different representations of different views for different kinds of text you are editing.
<beach>
For code, I think the parser idea is the best.
<loke>
Yes.
<beach>
And it may be right for many other things as well, like HTML, markdown, and other stuff with some syntax imposed.
milanj has quit [Quit: This computer has gone to sleep]
<beach>
I think you just gave me some of the reasons why I prefer to invent my own solutions before looking at what was done in the past. I do not want to be influenced by solutions that may have been appropriate in one context, but that aren't in others.
<loke>
Yeah. I've built something that is modelled on what GNU Emacs does.
<beach>
I see, yes.
<beach>
GNU Emacs is old technology now.
<loke>
Yes.
<beach>
1983 or 1984 as I recall.
<beach>
Of course, with my preferred way, I then occasionally re-invent something that has already been done.
<beach>
But it happens less often than one might fear.
<LdBeth>
> Norvig, in his GHWB impression, says &AUX is "bad! bad!"
<loke>
I'm pretty sure that concepts such as overlays are newer than that, but yes.
<loke>
The core is that old.
<ArthurStrong>
like xterm :)
<ArthurStrong>
which predates Internet
<beach>
loke: I think they may have cooked up solutions to problems based on what they had to work with, i.e. the old core.
<beach>
ArthurStrong: Do you have some data to support those dates?
<beach>
ArthurStrong: Actually, forget it. It's off topic.
<LdBeth>
Actually James Gosling invented many things of emacs on Unix by his own
<beach>
LdBeth: Not any great solutions as I recall.
<ArthurStrong>
beach: no, just IMHO
<LdBeth>
:D
<loke>
My current work has been a learning experience, and has taught me a lot. That's the nicest thing I can say about it :-)
<ArthurStrong>
"Xterm originated prior to the X Window System. It was originally written as a stand-alone terminal emulator for the VAXStation 100 (VS100) by Mark Vandevoorde, a student of Jim Gettys, in the summer of 1984, when work on X started." ( https://en.wikipedia.org/wiki/Xterm )
<LdBeth>
Yes, there’s no code doesn’t perish
<beach>
loke: I totally agree. There is no reason to feel bad.
<beach>
ArthurStrong: Actually, forget it. It's off topic.
<beach>
We already had Multics Emacs as a model when Gosling did his work.
<beach>
There was no reason to do it any other way.
zmt00 has quit [Read error: Connection reset by peer]
<LdBeth>
I believe parser combinator has been reinvented several times
zmt00 has joined #lisp
Posterdati has quit [Ping timeout: 250 seconds]
vlatkoB has joined #lisp
Posterdati has joined #lisp
<ricman>
do ECL (embeddable common lisp) support CLOS?
<beach>
Sure.
<beach>
ECL is an conforming implementation of the Common Lisp specification.
jeosol has quit [Quit: Connection closed for inactivity]
<beach>
ricman: Did you have reasons to think otherwise?
<ober>
beach: be nice
<beach>
ober: ?
dale has quit [Quit: My computer has gone to sleep]
<ricman>
beach: cool, thanks
<beach>
ricman: I am still interested in the reason for your question.
shifty has quit [Ping timeout: 265 seconds]
<ober>
well a lot of stuff on ecl won't build. like mop-utils in ql
<beach>
I don't know ECL in that level of detail, but technically, the MOP is not part of the Common Lisp standard.
<beach>
I guess jackdaniel would have to address that issue. He is the current ECL maintainer.
<no-defun-allowed>
I'm pretty sure ECL supports the MOP.
<ober>
so I'm interested in why if it's not in the standard, the statement that it's compliant with the standard would apply to a question about it...
Posterdati has quit [Ping timeout: 240 seconds]
<beach>
ober: Too many "it"s in your utterance. I can't figure out what each one refers to.
<beach>
ober: There is a part of CLOS that is in the Common Lisp standard, but the MOP has many more features than that, some of which are even contradicting the standard.
<loke>
beach: What part of MOS contradicts the standard?
<loke>
MOP
<beach>
loke: I don't remember by heart.
<beach>
loke: There are not many such items, and they are minor, but still.
ggole has joined #lisp
Posterdati has joined #lisp
<beach>
I doesn't look like my questions are going to be answered today. Oh well.
<aeth>
loke: I think it's something small like something that's normally a function, but with MOP is a generic function instead or something. But apparently that isn't against the standard, so I have to be misremembering the details
<beach>
aeth: That is not right. The standard allows for every function to be generic.
<aeth>
yes
Oladon has quit [Quit: Leaving.]
jeosol has joined #lisp
MightyJoe has quit [Ping timeout: 265 seconds]
cyraxjoe has joined #lisp
asarch has quit [Quit: Leaving]
abhixec has quit [Quit: leaving]
<beach>
It may have been small stuff like one saying "the consequences are undefined" and the other one that "an error is signaled".
DGASAU has quit [Read error: Connection reset by peer]
DGASAU has joined #lisp
mabox has joined #lisp
<mabox>
The guy did suggest at Cristosan.com
<beach>
mabox: What?
<no-defun-allowed>
beach: That is some kind of spammer.
<no-defun-allowed>
The website redirects you to a tweet by what I assume is a markov chain.
<beach>
I refuse to follow a link unless the person who posted it explains what it is about.
<beach>
Hence my "What?"
<no-defun-allowed>
I don't think whoever came up with the spam bot programmed it to explain itself, sadly.
<beach>
I am not looking for an explanation. I am looking for the absence of one, so that I don't have to follow the link.
<White_Flame>
LdBeth: one interesting use of &aux that I've found is computing derived struct slot values in the declared BOA constructor without needing a function body
<loke>
BOA Constructor?
<White_Flame>
but yeah, other than that syntactic trick, it's quite obsolete
<loke>
Wow. I didn't know that was possible. And even though I now know about it, I don't think I'll ever use it.
<loke>
:-)
* White_Flame
likes shortcuts when possible and fits the intent. Plus, with Lisp it's pretty easy to unroll into "full form" if it gets past the scope of the shortcut
mabox has quit [Ping timeout: 268 seconds]
<loke>
To be honest, I rarely if ever use DEFSTRUCT :-)
<loke>
I prefer DEFCLASS
synaps3 has joined #lisp
synaps3 has quit [Changing host]
synaps3 has joined #lisp
toorevitimirp has joined #lisp
gareppa has joined #lisp
femi has quit [Ping timeout: 240 seconds]
femi has joined #lisp
q[corwin] has quit [Ping timeout: 268 seconds]
raghavgururajan has joined #lisp
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
toorevitimirp has quit [Read error: Connection reset by peer]
toorevitimirp has joined #lisp
synaps3 has quit [Quit: Leaving]
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
mulk has joined #lisp
aindilis` has joined #lisp
aindilis has quit [Ping timeout: 268 seconds]
hh47 has joined #lisp
varjag has joined #lisp
hh47 has quit [Ping timeout: 250 seconds]
milanj has joined #lisp
benkard has joined #lisp
mulk has quit [Ping timeout: 250 seconds]
benkard is now known as mulk
dddddd has quit [Remote host closed the connection]
manualcrank has quit [Quit: WeeChat 1.9.1]
toorevitimirp has quit [Remote host closed the connection]
jeosol has quit [Quit: Connection closed for inactivity]
X-Scale` is now known as X-Scale
toorevitimirp has joined #lisp
ricman has quit [Read error: No route to host]
shifty has joined #lisp
jonatack has joined #lisp
shka_ has joined #lisp
cartwright has quit [Remote host closed the connection]
libertyprime has quit [Ping timeout: 265 seconds]
cartwright has joined #lisp
libertyprime has joined #lisp
hhdave has joined #lisp
kajo has quit [Ping timeout: 264 seconds]
seok has quit [Remote host closed the connection]
bars0 has joined #lisp
bars0 has quit [Quit: leaving]
bars0 has joined #lisp
bars0 has quit [Client Quit]
bars0 has joined #lisp
bars0 has quit [Client Quit]
bars0 has joined #lisp
synaps3 has joined #lisp
synaps3 has quit [Changing host]
synaps3 has joined #lisp
toorevitimirp has quit [Quit: Konversation terminated!]
toorevitimirp has joined #lisp
Josh_2` has joined #lisp
Josh_2 has quit [Read error: Connection reset by peer]
femi has quit [Ping timeout: 265 seconds]
femi has joined #lisp
synaps3 has quit [Ping timeout: 276 seconds]
gxt has quit [Quit: WeeChat 2.6]
pfdietz has joined #lisp
gareppa has quit [Quit: Leaving]
jprajzne has quit [Quit: jprajzne]
m00natic has joined #lisp
kajo has joined #lisp
superkumasan has quit [Ping timeout: 240 seconds]
bahadirh has joined #lisp
jmercouris has joined #lisp
<jmercouris>
Ok, so yesterday we established that we can't do FFI to C++ because the ABI is not standard in C++ world
<jmercouris>
my question then is, how do the Smoke/QT4 bindings work?
<jmercouris>
If we can't invoke C++ code from Lisp, how can we use Qt?
bahadirh has quit [Ping timeout: 268 seconds]
<phoe>
AFAIK, smoke generates C bindings to *all the functions*
<phoe>
and these can be called
<jmercouris>
Okay, so C can call C++?
<jmercouris>
I thought yesterday someone said that C->C++ is not possible
<phoe>
of course it is
<phoe>
you generate an extern "C" binding in C++
<jmercouris>
Aha!
<phoe>
and inside your C++ object you get a C binding with a known C symbol
<jmercouris>
The final piece of the puzzle, I get it now
<phoe>
and this C function calls C++ code
<jmercouris>
Ok, I get it now, thank you
<jmercouris>
I've been thinking about this for so many hours
grabarz has joined #lisp
xuxuru has joined #lisp
superkumasan has joined #lisp
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
brettgilio has quit [Quit: Quit]
FreeBirdLjj has joined #lisp
jonatack has quit [Ping timeout: 240 seconds]
DGASAU has quit [Read error: Connection reset by peer]
milanj has quit [Read error: Connection reset by peer]
DGASAU has joined #lisp
jonatack has joined #lisp
toorevitimirp has quit [Ping timeout: 240 seconds]
amerlyq has joined #lisp
milanj has joined #lisp
toorevitimirp has joined #lisp
hiroaki has joined #lisp
jmercouris has quit [Ping timeout: 268 seconds]
shka_ has quit [Ping timeout: 240 seconds]
libertyprime has quit [Ping timeout: 240 seconds]
libertyprime has joined #lisp
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shka_ has joined #lisp
bitmapper has joined #lisp
bars0 has quit [Ping timeout: 268 seconds]
grewal has quit [Quit: leaving]
<beach>
Funny that so few people see the obvious solution to that dilemma.
<Shinmera>
beach: Abandon everything?
<beach>
Program in Common Lisp instead.
<pjb>
Just say no to FFI!
<no-defun-allowed>
Standardise the C++ ABI? That would be half-polite of the – well, sure. No good if you want to use Qt though.
<beach>
But yeah, abandon everything and grow vegetables instead is another possibility.
<beach>
no-defun-allowed: It is possible to adjust what you want.
<no-defun-allowed>
Absolutely.
<beach>
But I will be quiet now because I am not adding anything new that I haven't already said.
<no-defun-allowed>
I agree life is much simpler if you are able to avoid FFI completely or avoid it as much as possible, or if you grow vegetables; but there may be reasons one wants to use Qt.
FreeBirdLjj has quit [Remote host closed the connection]
<no-defun-allowed>
My favourite reason is to use the Qt WebEngine to load documents off a CL server, and implement the UI in HTML/CSS/JavaScript. Then use your favourite C->JavaScript transpiler to run Qt in the browser, and repeat until you get bored.
shka_ has quit [Quit: Konversation terminated!]
nowhere_man has quit [Ping timeout: 265 seconds]
shka_ has joined #lisp
<no-defun-allowed>
But seriously, it may be less effort per individual to bite the bullet and work with Qt than to test/port/develop/&c a CL toolkit, even though all the time taken to accomodate for foreign code would probably add up to more than enough required to make that toolkit work.
<pfdietz>
Presumably Clasp would make interoperating with C++ easier.
zagura_ has joined #lisp
zagura is now known as zagura_s
zagura_ is now known as zagura
xuxuru has quit [Quit: xuxuru]
gabiruh has joined #lisp
shka_ has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
*less initial effort, not effort per individual
milanj has quit [Quit: This computer has gone to sleep]
shka_ has joined #lisp
ebrasca has joined #lisp
gabiruh_ has joined #lisp
gabiruh has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 276 seconds]
libertyprime has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
shka_ has quit [Quit: Konversation terminated!]
milanj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
EvW has joined #lisp
pfdietz has left #lisp [#lisp]
q[corwin] has joined #lisp
toorevitimirp has quit [Ping timeout: 245 seconds]
Kevslinger has joined #lisp
jonatack has quit [Ping timeout: 240 seconds]
``Erik_ has joined #lisp
orivej has joined #lisp
``Erik has quit [Ping timeout: 268 seconds]
grabarz has joined #lisp
toorevitimirp has joined #lisp
lucasb has joined #lisp
nika_ has joined #lisp
milanj_ has joined #lisp
Bike has joined #lisp
milanj has quit [Ping timeout: 246 seconds]
ebzzry has quit [Ping timeout: 240 seconds]
ebzzry has joined #lisp
orivej has quit [Ping timeout: 265 seconds]
<beach>
I am convinced we represent an instance of the prisoner's dilemma. The optimal solution is to collaborate to create Common Lisp solutions to our collective software needs, but individually, it is better to take the FFI route.
<beach>
As a result, everybody pays the price of increased development and maintenance burden. Except those who can and do choose to work on something that can be done entirely in Common Lisp.
<Shinmera>
Those bear the burden of enormous maintenance burdens too, just in CL
* Shinmera
ogles his 100 libraries, a lot of which would need more work
makomo has joined #lisp
<beach>
FFI solutions require a different kind of maintenance, namely catching up with moving targets, like Qt versions, LLVM versions, Gnome versions.
toorevitimirp has quit [Remote host closed the connection]
<beach>
Or not, as it usually is, and the "solution" just bitrots.
toorevitimirp has joined #lisp
ravenousmoose has joined #lisp
FreeBirdLjj has joined #lisp
milanj_ has quit [Quit: Leaving]
milanj has joined #lisp
<Xach>
I wrote pure lisp stuff for gifs and pngs because I was frightened by the thought of foreign code crashing my long-running server.
<Xach>
or crashing as i developed
<beach>
Sounds like a good reason.
<Xach>
i hate crashing more than i needed it right away or to be super super fast
<beach>
Mhm.
<_death>
I didn't write OpenCV in pure lisp because it would require tens of thousands of man hours or more..
<beach>
_death: I think that is the very essence of the prisoner's dilemma.
<beach>
Anyway, having identified the reason for the state of things, I now understand much better what is going on, and I know that it would usually be futile to try to influence someone's choice.
<_death>
beach: but you could also flip it, so that the utilitarian solution is to use the language where most effort has already gone to, and the choosing Lisp is the egoistic individual choice
pelides has joined #lisp
pelides is now known as achilles
<beach>
That might have been true if the "utilitarian solution" were effortless or nearly so. The many questions and problems related to FFI solutions that are discussed here suggest otherwise.
achilles is now known as achilles^
nowhere_man has joined #lisp
igemnace has quit [Ping timeout: 240 seconds]
<beach>
Ultimately, if you are right, there is no reason to use Common Lisp at all.
LiamH has joined #lisp
achilles^ is now known as achiLLes
achiLLes is now known as AchiLLes
<_death>
there is reason, but it is an egoistic reason.. I like CL better than C++, so I don't mind putting effort into making the rest of the world work with CL.. only a small group of people may benefit from this choice
<beach>
_death: You don't need an excuse to choose the FFI solution ("tens of thousands of man hours or more"). Like I said, it is perfectly clear to me now why this solution is optimal to the individual.
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FreeBirdLjj has quit [Ping timeout: 250 seconds]
<beach>
_death: I think that is a very good idea, i.e. create a Common Lisp "wrapper" for an existing foreign library. However, what I usually observe is a badly documented wrapper library that requires the user to understand both the foreign library, the foreign language it is written in, *and* the undocumented code of the wrapper.
<beach>
I am not saying this is the case with yours of course. I haven't looked at it at all.
AchiLLes is now known as doom`
doom` is now known as mage
<_death>
beach: I definitely agree with this observation.. I think it's difficult to design good interfaces, and the Lisp standard is a high one.. it's much easier to ape the foreign library's existing interface.. in the past I did that, but also did the harder work at times
Bourne has joined #lisp
mage is now known as morph
<_death>
beach: it also has to do with means and ends.. if utilization of this library is just a means to an urgent end, then it's likely the initial solution would involve less thought about the interface
morph is now known as oracle
nadare has quit [Quit: leaving]
oracle is now known as rubick`
<beach>
Yes, but then it is not really usable by a wide audience. And we are back to the prisoner's dilemma.
manualcrank has joined #lisp
FreeBirdLjj has joined #lisp
rubick` is now known as meepo
meepo has left #lisp ["ERC (IRC client for Emacs 26.2)"]
makomo has quit [Ping timeout: 265 seconds]
clothespin_ has quit [Quit: Leaving]
igemnace has joined #lisp
nowhere_man has quit [Ping timeout: 276 seconds]
jonatack has joined #lisp
makomo has joined #lisp
nowhere_man has joined #lisp
dale_ has joined #lisp
dale_ is now known as dale
Xach has quit [Quit: leaving]
toorevitimirp has quit [Quit: Konversation terminated!]
achilles^ has joined #lisp
achilles^ has quit [Client Quit]
achilles^ has joined #lisp
achilles^ has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
bitmapper has quit [Remote host closed the connection]
achilles^ has joined #lisp
Lycurgus has joined #lisp
achilles^ has quit [Remote host closed the connection]
Lycurgus has quit [Quit: Exeunt]
makomo has quit [Ping timeout: 250 seconds]
milanj_ has joined #lisp
EvW has quit [Quit: EvW]
milanj__ has joined #lisp
milanj has quit [Read error: Connection reset by peer]
Inline__ has joined #lisp
milanj_ has quit [Ping timeout: 245 seconds]
random-nick has joined #lisp
nowhere_man has quit [Ping timeout: 246 seconds]
Inline has quit [Ping timeout: 264 seconds]
nika_ has quit [Remote host closed the connection]
shifty has quit [Ping timeout: 240 seconds]
nika_ has joined #lisp
xuxuru has joined #lisp
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #lisp
hh47 has joined #lisp
kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
Josh_2` has quit [Remote host closed the connection]
xuxuru has quit [Quit: xuxuru]
aindilis` has quit [Remote host closed the connection]
fookara has joined #lisp
aindilis has joined #lisp
slyrus__ has joined #lisp
slyrus_ has quit [Ping timeout: 265 seconds]
nika_ has quit [Remote host closed the connection]
nika_ has joined #lisp
gareppa has joined #lisp
makomo has joined #lisp
dddddd has joined #lisp
t3rtius has joined #lisp
smazga has joined #lisp
pfdietz has joined #lisp
<Shinmera>
Speaking of UI, though, here's another brief demo for Alloy I put together today https://youtu.be/oLRBZrdzJS0
<phoe>
SBCL, CCL, ECL, CLISP and ABCL all seem to return 6 in that case
<pfdietz>
17 years ago, I should remember this crisply...
<phoe>
yes, exactly this; I am sorry about that
<phoe>
does anyone on #lisp know which part of the standard specifies the rationale for these tests? In particular, that X is not supposed to be set anywhere outside (INTEGER 1 5)?
<phoe>
And that it is not supposed to be 6 when it is returned?
<pfdietz>
"In an iteration control clause, the for or as construct causes termination when the supplied limit is reached. That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
<pfdietz>
So, 1.41 may be wrong
<White_Flame>
phoe: the definition of stepping says that the variable itself is updated in anticipation for the next iteration
<White_Flame>
by that, X would legitimately be 6, and the declaration of (integer 1 5) is wrong
<phoe>
pfdietz: it seems that passage is from CLtL2 though
<Bike>
it's in 6 1 2 1 1
<pfdietz>
It is in the CLHS
<Bike>
"For these clauses, iteration terminates when a local variable reaches some supplied value or when some other loop clause terminates iteration." is in 6.1.2.1, too
<White_Flame>
"is reached" is problematic with those examples, if taken to be "is equal to". The examples clearly show overshooting the target "to 10" value, not reaching it exactly
<White_Flame>
the first paragraph does say that the variable is stepped after each iteration, with no exemption for the final iteration
<phoe>
White_Flame: which examples do you mean?
<White_Flame>
in 6.1.2.1.1: (let ((x 1)) (loop for i from x by (incf x) to 10 collect i)) => (1 3 5 7 9)
<phoe>
isn't this equivalent to (loop for i from x by 2 to 10 collect i)
<phoe>
isn't the BY-form is only evaluated once
<phoe>
isn't the BY-form only evaluated once*
<pjb>
(let ((x 1)) (loop for i from x by (incf x) to 10 collect i into is finally (return (values is i)))) #| --> (1 3 5 7 9) ; 11 |#
<phoe>
pjb: yes, I am aware what implementations do
<phoe>
my question is if this is what they are supposed to do
<phoe>
because then ANSI-TEST are faulty
<phoe>
(loop for i from 1 by 2 to 10 collect i into is finally (return (values is i))) is equivalent
<pjb>
I cannot find where it says that the loop variables scope covers the finally expressions…
cosimone has quit [Quit: Quit.]
<White_Flame>
to my reading of the spec, regarding the definition of stepping (that it affects the variable itself), and that stepping happens at the end of each iteration, yes the test is wrong
gareppa has quit [Quit: Leaving]
cosimone has joined #lisp
<White_Flame>
within pretty much every LOOP clause but FINALLY, the variable is in (integer 1 5), but it does go past that after the final iteration
<White_Flame>
so it's not a proper description of the variable itself
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<White_Flame>
if each loop clause had (locally (declare ((integer 1 5) x)) ...) that would be another thing
<phoe>
LOOP is expanded into bindings and block and tagbody, and inside this there is a prologue, body, and epilogue
<phoe>
this means that the epilogue is inside the bindings, which implies that the variables are accessible
<pjb>
Note that 6.1.2.1 says that: Stepping assignments are made in the loop body BEFORE any other forms are evaluated in the body. and Stepping assignments are made in the loop body BEFORE any other forms are evaluated in the body.
<phoe>
6.1.2.1.1 states "iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
<pjb>
It doesn't say whether the test occurs before or after the incrementing.
<phoe>
so the value var must not exceed the limit
<phoe>
so if I loop for x below/to most-positive-fixnum, then x can be set to most-positive-fixnum but must never exceed it
<White_Flame>
the verbiage ends up contradictsory
<White_Flame>
-s
Josh_2 has joined #lisp
<phoe>
well shit, not the first or the last time
<phoe>
who's up for creating the CDR
<pjb>
Therefore one could expect (if (= x last) (loop-finish) (incf x)) and x being 5 in the epilog. Of course, this would require x to be initialized to -1, so the type would still be broken.
<jackdaniel>
I like the world "contradictsorry" :-)
<jackdaniel>
word*
<White_Flame>
yes, that is a good alternate world
<phoe>
initialized? why?
<White_Flame>
pjb: but again, there are examples where it overshoots and never exactly matches the "to" clause, yet still halts
t3rtius has quit [Ping timeout: 246 seconds]
<White_Flame>
I don't think the tests happen anywhere outside the clauses such as for/while/until
<jackdaniel>
one could argue, that do doesn't have such problems thanks to intelligible specification ;) good night and good luck
<phoe>
:D
rixard_ has joined #lisp
<phoe>
jackdaniel: good night
<pfdietz>
I am vaguely recalling being conflicted about all this, 17 years ago.
<pjb>
White_Flame: But we can test: (if (<= x (- last increment)) (incf x increment) (loop-finish))
<White_Flame>
pjb: that avoids stepping, which would be against the spec too
<pjb>
the spec doesn't specify the order between the test and the step. (incf x increment) is my step.
<White_Flame>
but it is stepped on each iteration. Now, what is an "iteration"?
mathrick has quit [Ping timeout: 264 seconds]
rixard has quit [Ping timeout: 268 seconds]
<White_Flame>
if a test fails, is that not an iteration?
<phoe>
well, it isn't
<phoe>
iteration implies evaluating a loop body
<phoe>
if you don't evaluate a loop body then you ain't doing an iteration
<phoe>
(loop repeat 10 do (foo)) performs ten iterations
aindilis has quit [Remote host closed the connection]
<phoe>
so the way I understand it, it is stepped on each iteration
<phoe>
what if you test after the last iteration but before the next iteration - is this permitted by the spec?
aindilis has joined #lisp
<phoe>
because then you could check that the next X is going to pass the boundary, and do not pass GO, do not collect $200, go straight to epilogue
techquila has joined #lisp
<pjb>
White_Flame: an iteration is when the body is executed.
techquila has quit [Remote host closed the connection]
<pjb>
so you can test first, and not execute the body. Then you must not increment. This shows that x should never be 6.
techquila has joined #lisp
<phoe>
okay - I will need some support
<phoe>
do we have a conclusion now, because my brain is fuzzy after discussing this on #ccl #ecl and now here
<White_Flame>
pjb: the tests are in the body, though
<phoe>
White_Flame: he means the implicit tests inside the LOOP body, not ones in the body
<phoe>
I replied to a post that you made a while ago, I didn't notice that I scrolled up
<phoe>
gah I'm unfocused now
<phoe>
s/inside the LOOP body/inside the LOOP but outside the body/
<White_Flame>
pjb: semantically, in order to get the result I think you want, you'd have to test the current value (in case its equal), test the hypothetical value that it would take on if it were stepped, and then step if that hypothetical value was still in range
<White_Flame>
but given the conflicts within the text, I don't think that's the implication
<White_Flame>
or at least, I don't think that's the overall implication
<White_Flame>
it all comes down to what it means by "reached" when you're talking about overshooting a threshold
<beach>
As I recall, I made SICL LOOP pass those tests.
jeosol has joined #lisp
<beach>
MIT loop has some other problems of conformity as well.
<beach>
Like clause ordering.
<phoe>
White_Flame: what are the options when it comes to "reached"?
<phoe>
I'd assume that a value "reaches" a threshold when it becomes equal or more than it
<phoe>
(equal or less if we iterate downwards)
cyraxjoe has quit [Ping timeout: 240 seconds]
<White_Flame>
"to 10" means exclusive. So the body still runs when it's 10, but not higher
<phoe>
that is literally inclusive though
<White_Flame>
(the threshold being tripped is exclusive of equalling 10, I guess that's confusing wording from me)
<phoe>
to 10, inclusive - less or equal to 10
<phoe>
to 10, exclusive - less to 10 but not equal
<phoe>
if the threshold permits another iteration on equality, we then iterate once more and terminate
<pfdietz>
Additional problems when STEP is not +-1
<phoe>
and it permits if it is inclusive and the var is equal to the threshold
<White_Flame>
and a related question is does the test occur against a hypotehtical value, or against the stepped value of the variable itself
<phoe>
if we iterate from 0 by 1 to 9.5 then the last iteration must be 9
<phoe>
if we iterate from 0 by 1 below 9.5 then the last iteration must also be 9
<phoe>
White_Flame: it doesn't really matter much - we do not have side effects here
<phoe>
so we can theoretically test as much as we'd like
<phoe>
we only consider numeric iteration here
<White_Flame>
the iteration is a side effect on the variable
<White_Flame>
and that affects is value in FINALLY
<White_Flame>
*its value
cyraxjoe has joined #lisp
fookara has quit [Remote host closed the connection]
<phoe>
and only in FINALLY
<phoe>
so the question is, is the variable in FINALLY supposed to ever overshoot the threshold
<phoe>
or, in other words, if LOOP.1.40 is correct
<phoe>
or if it is supposed to stay at 5
<White_Flame>
I believe it's supposed to overshoot
<White_Flame>
but this is admittedly interpreting the scriptures
<phoe>
and I believe it is not supposed to overshoot
<phoe>
which means trouble for me
<pfdietz>
Clearly we should try to read the CLHS in the original Aramaic.
<phoe>
well shit, it's time for a schism then
asarch has quit [Quit: Leaving]
lucasb has quit [Quit: Connection closed for inactivity]
mulk has quit [Ping timeout: 240 seconds]
mulk has joined #lisp
newcup has joined #lisp
<phoe>
going away from the orthodox and going for the practical now - if it does not overshoot, then it makes sense to iterate e.g. on fixnums
<phoe>
since then the variable will be never set to (1+ most-positive-fixnum)
<phoe>
and that could both be unsafe due to possible overflows and slow if LOOP must expect that a fixnum variable cannot be expected to be a fixnum
<phoe>
and therefore typecheck for bignum on each iteration
<White_Flame>
which specific wordings do you believe to imply no overshoot?
* phoe
scrolls up
<phoe>
19:34 < phoe> 6.1.2.1.1 states "iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
<pfdietz>
I would have specified it this way: the variable visible in the body and the finally is bound to successive values in the indicated range, but is never incremented. Its value is incremented, but that is not stored into the variable before the test for termination.
<phoe>
19:34 < phoe> so the value var must not exceed the limit
<phoe>
19:34 < phoe> so if I loop for x below/to most-positive-fixnum, then x can be set to most-positive-fixnum but must never exceed it
<White_Flame>
however, it's stepped before the iteration. In "to 10", when it "is stepped to the .. inclusive limit supplied by form2", the iteration is still supposed to run
<phoe>
pfdietz: if it is incremented, then you could run into type issues as well - if you iterate on a fixnum variable, then the hidden variable must be an integer
<White_Flame>
so that puts the fencepost on "until"
<phoe>
what prevents the tests from running before the stepping occurs?
<phoe>
so either after the body but before jumping to the beginning for the next iteration, or between the beginning of the iteration and the stepping?
<White_Flame>
that's what I replied to pjb with: You'd need to test existing, test the would-be stepped value, and then save the increment as 3 separate steps
<phoe>
hmmm
<phoe>
so we would nonetheless need to typecheck in order to test the would-be stepped value?...
<pfdietz>
phoe: that is an implementation detail. One could test before adding to it, converting (<= (+ x step) limit) to (<= x (- limit step))
<phoe>
oh, or this
<phoe>
White_Flame: but anyway, if that is what is required to make it correct, then why can't we do this?
<pfdietz>
the problem is the specification is not clear
<White_Flame>
phoe: because I don't think it's correct ;)
<White_Flame>
at least, with everything the spec says about it, I think it contradicts the least to overshoot it
<phoe>
;__;
<phoe>
yes, I understand this
<phoe>
so if the spec contradicts itself, I could assume that the implementations are free to do whatever they can and therefore the behaviour is undefined
<phoe>
so these ANSI-TEST tests would need to fly out of the window
<phoe>
that is yet another conclusions
<phoe>
s/conclusions/conclusion/
<White_Flame>
I woudld agree with that conclusion
<phoe>
pfdietz: does that sound sane?
gioyik has joined #lisp
gioyik has quit [Read error: Connection reset by peer]
<phoe>
to classify this as undefined behaviour?
gioyik has joined #lisp
gioyik has quit [Read error: Connection reset by peer]
<beach>
note to self, specify the behavior of the for-as-arithmetic subclause behavior better in WSCL.
cosimone has quit [Remote host closed the connection]
<Posterdati>
every revision that come out is still broken
zulu-inuoe has quit [Read error: Connection reset by peer]
mikecheck has joined #lisp
varjagg has joined #lisp
<Posterdati>
Posterdati: the c-toolchain code cannot get the value for $CC resulting in using cc which is NOT gcc
enrio has quit [Ping timeout: 265 seconds]
milanj__ has quit [Quit: This computer has gone to sleep]
<ober>
doesn't ports have a patch for that on obsd?
<ober>
Posterdati: just pkg_add gcc and set CC
raghavgururajan has quit [Read error: Connection reset by peer]
matijja` has joined #lisp
sjl has joined #lisp
<Kabriel>
phoe: The very last sentence of 6.1.2.1.1 clarifies the exclusive range:
<Kabriel>
The range is exclusive if form3 increases or decreases var to the value of form2 without reaching that value; the loop keywords below and above provide exclusive limits. An inclusive limit allows var to attain the value of form2; to, downto, and upto provide inclusive limits.
<Kabriel>
test 1.39 should succeed, becuase x should *not* be set to 6
<Kabriel>
I think test 1.40 is very similar, except it is testing the inclusive ranges (to, downto, upto, etc), where the value of var should take on the value of form2.
cosimone has quit [Quit: Quit.]
<Kabriel>
In SBCL it exceeds it, and I suspect this is the case in most implementations using a derivative of the MIT loop.
<phoe>
Kabriel: CCL ECL ABCL CLISP all fail this test.
<phoe>
Kabriel: thanks.
<phoe>
White_Flame: ^
ggole has quit [Quit: Leaving]
<ober>
phoe: which test?
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<White_Flame>
yeah, that's part of the conflicting part. Does that talk about the value of the variable visible within the body?
<White_Flame>
or does that constraint extend out to the full lifecycle of the epilogue and such?
Inline__ has quit [Quit: Leaving]
<White_Flame>
because that paragraph starts with "In an iteration control clause, .."
<White_Flame>
and teh sentence before that one is also a very ambiguous one "That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
Inline has joined #lisp
<White_Flame>
especially if you take the inclusive forms, that sentence makes no sense regarding the intent
<dlowe>
stepped is usually not a transitive verb
<phoe>
ober: LOOP.1.39 ANSI-TEST
<phoe>
LOOP.1.40 as well I think
<dlowe>
or "stepped to" rather
random-nick has joined #lisp
random-nick has quit [Max SendQ exceeded]
gravicappa has quit [Ping timeout: 240 seconds]
raghavgururajan has joined #lisp
<White_Flame>
it also doesn't help that "iteration" doesn't seem to be explicitly defined, specifically with regards to the fenceposting of "iteration continues until"
Jesin has joined #lisp
EvW has quit [Ping timeout: 250 seconds]
<Kabriel>
White_Flame: I see your point that it is ambiguous. I tend to think of "iteration" as the body (i.e. execution clauses). I would like to say that the epilogue should be included in that, too, but the terms aren't defined.
Cymew has quit [Ping timeout: 268 seconds]
<White_Flame>
my main point derives from a bottom-up reading of the mechanics and stepping, which would imply overshoot. The top-down statements like this might be taken to imply no overshoot.
milanj__ has joined #lisp
random-nick has joined #lisp
grabarz has joined #lisp
<Kabriel>
White_Flame: I definitely agree from a mechanics standpoint; the test would always be done after the stepping of var, so the last value of var will not satisfy the test (i.e. in the epiloge). To do otherwise requires extra stuff.
<Kabriel>
I was thinking about this last week, which is how I stumbled on beach's ELS presentation.
<White_Flame>
the glossary entry for step as well: "to assign the variable a new value at the end of an iteration, in preparation for a new iteration."
bitmapper has joined #lisp
<pfdietz>
I have no strong emotional attachment to these tests. I've conditionalized tests for lesser reason.
<White_Flame>
(which again begs what an "iteration" even means in that context. One time around the LOOP body? One pass through that clause?)
<pfdietz>
At the end of the day, it's up to the implementers to make their decisions. They should, I think, document how they interpret this part of the standard.
<Kabriel>
Me either. I am interested to hear what beach has to say, since he implemented sicl loop facility differently.
<pfdietz>
I doubt it has any practical importance.
rgherdt has joined #lisp
lavaflow has quit [Quit: I can't even]
<phoe>
me too
<phoe>
I'd just like it to be consistent across the Lisp universe
<phoe>
even if consistency means that we all agree for this to be undefined and therefore impossible to depend on
<aeth>
All of this talk of iteration makes me wonder why CL hasn't added iterators as an extension yet... or has it? Is that part of that extensible sequences thing that no one uses?
<dlowe>
I think SERIES is essentially that
<aeth>
In particular, though, it seems like it would be useful for using the implementation's sort algorithm
<dlowe>
one of my someday-maybe projects has always been to make an SERIES implementation that actually integrates gracefully into sbcl
<dlowe>
I'd probably never use loop again
<pfdietz>
Aeth: ITERATE supports that sort of extension.
<pfdietz>
I know some people who prefer it to LOOP. I'm annoyed it breaks Waters' COVER package, but that's mostly COVER's fault.
<aeth>
pfdietz: I want to like ITERATE, but it's not LOOP-compatible enough so I'm going to eventually write a DO-LOOP that at its base is basically just LOOP with parentheses added around the clauses and keywords required (rather than accepting any symbol package)
<aeth>
Sort of a compromise between the two approaches.
goofist has joined #lisp
<aeth>
pfdietz: Does ITERATE support sorting? #'sort is pretty weak. It doesn't even accept start and end points.
<pfdietz>
What do you mean by "support sorting"?
EvW1 has joined #lisp
<aeth>
pfdietz: An iteration macro could support sorting in a range, at least on vectors, perhaps even composing with the other functionality to determine the start and end range instead of having to know the indices in advance... and combined with iterators, it would be able to sort arbitrary things, not just the built in (whole) sequences that #'sort does.
<aeth>
Slightly unrelated to pure iteration, but they usually do have things like sum, anyway.
<pfdietz>
That doesn't really seem to be what ITERATE is about. I suppose merging of two generators could be an interesting capability.
<pfdietz>
Or collecting into a sequence, destructively.
<aeth>
Well, maybe I am looking at it differently, but to me it seems like the natural extension in functionality past things like summation.
<aeth>
And, yes, collect.
<pfdietz>
So, collecting into a heap, then serializing at the end?
shifty has joined #lisp
gareppa has joined #lisp
<pfdietz>
Some sort of accumulator abstraction.
<aeth>
Possibly. Perhaps the correct way to look at things is (1) providing the primitives for vector and list (and arbitrary iterator) sort and (2) providing the extensibility so that it can be added in
Bike has quit [Quit: Bike]
<aeth>
rather than viewing it as a basic iteration in itself
<pfdietz>
Like making a header cons cell with tail pointer for RPLACD accumulation of a list, and returning the actual head at the end.
kajo has joined #lisp
<phoe>
well
<phoe>
I am exhausted
<phoe>
pfdietz: should we comment out those LOOP tests with the rationale that the spec is contradictory and the behaviour is undefined, then?
<phoe>
I'd suggest commenting them out, because someone in the future might notice this and reignite the religious dispute
mathrick has joined #lisp
<pfdietz>
There's also a note facility for marking contentious tests.
<pfdietz>
(inspired by Bruno Haible's feedback r.e. clisp)
<pfdietz>
aeth: ITERATE does allow one to define new gathering clauses
t58 has joined #lisp
t58 has quit [Remote host closed the connection]
<phoe>
pfdietz: oh? What is it?
<pfdietz>
In the version of RT that's with ansi-test, see the macro DEFNOTE.
<pfdietz>
There is a file notes.lsp that defines various notes.
<pfdietz>
When a test is defined, notes can be attached. The function RT:DISABLE-NOTE allows tests with that note to be disabled and not run by RT:DO-TESTS
<phoe>
it is somewhat short on description and theoretical but perhaps could be of use to you
raghavgururajan has quit [Remote host closed the connection]
<fiddlerwoaroof>
I'm trying to find resources to show my coworkers how to design programs using multimethods
<phoe>
1) find an action that you want to do
<phoe>
e.g. frobnicate
<fiddlerwoaroof>
We're using Clojure, but I've found that a lot of these CL resources are really helpful when writing Clojure
<phoe>
2) find all prerequisite objects that are needed to properly frobnicate - e.g. foo, bar, and baz
<phoe>
3) (defgeneric frobnicate (foo bar baz ...)) where ... is any optional/keyword parameters and data that the function will/may need
<phoe>
4) specialize for all valid class combinations of foo, bar and baz
<fiddlerwoaroof>
Yeah, I'm more interested in system-level design
<phoe>
oh, I see - that's a level above
<phoe>
you could use existing materials for system level design, except that many design patterns go out of the window since Lisp has better ways of solving those
<phoe>
and a lot of design patterns were made to work around foo.bar(baz) style of method calling
<phoe>
where methods are on classes and not on GFs
<fiddlerwoaroof>
Yeah, but I think what Lisp does have is this concept of defining your system in terms of a set of generic functions
<fiddlerwoaroof>
So that, for example, you can specialize the functions one way for testing and then another way for produciton
ebrasca has quit [Read error: Connection reset by peer]
<phoe>
basically, it describes things like protocol classes and protocol functions
<phoe>
protocol classes must be instantiated and protocol functions are GFs whose methods may specialize on concrete classes
ebrasca has joined #lisp
amerlyq has quit [Quit: amerlyq]
<fiddlerwoaroof>
thanks
sjl has joined #lisp
<phoe>
this is kinda equivalent to Java interfaces and interface methods
<phoe>
except obviously the Java way does not know or use GFs
<fiddlerwoaroof>
Yeah, and ultimately results in ungainly system design because of Java's type system
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
freebird has quit [Remote host closed the connection]
<phoe>
yes
<phoe>
but Java being a pile of #<unreadable object> isn't the topic here - was just trying to make an analogy
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shifty has quit [Ping timeout: 246 seconds]
<fiddlerwoaroof>
yeah
<fiddlerwoaroof>
I just hesitate to compare anything to Java because the people I'm talking to like to criticize Java
<Shinmera>
fiddlerwoaroof: mixins are another important piece that make CLOS so amenable to protocol design.
synaps3 has joined #lisp
varjagg has quit [Ping timeout: 240 seconds]
<fiddlerwoaroof>
Yeah
smazga has quit [Quit: leaving]
pfdietz has joined #lisp
<pfdietz>
fiddlerwoaroof: you'll also want to consider uses of method combination
<phoe>
pfdietz: if he wants to explain that to his coworkers then that would be not the first nor the second or third thing he'd speak about
<pfdietz>
True
quazimodo has quit [Ping timeout: 246 seconds]
quazimodo has joined #lisp
dented42 has joined #lisp
synaps3 has quit [Ping timeout: 240 seconds]
mindthelion has joined #lisp
jfb4` has joined #lisp
jeosol has quit [Quit: Connection closed for inactivity]
techquila has quit [Ping timeout: 264 seconds]
orivej has joined #lisp
<no-defun-allowed>
pfdietz: Method combinations are no good if you're working a language without them.
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jfb4` has quit [Quit: ERC (IRC client for Emacs 26.3)]
jfb4 has joined #lisp
<fiddlerwoaroof>
pfdietz: yeah, there's a library that implements CLOS-style generic functions for Clojure, but I think that's a bridge too far for now
<fiddlerwoaroof>
And, method combinations will make people think of AspectJ, which isn't good where I work
<phoe>
(it isn't good regardless of where one works)