v88m has quit [Read error: Connection reset by peer]
<beach>
The WITH-OUTPUT-TO-STRING is the important part.
<mivanchev>
I mean if there's a shorter version of alexandria:read-stream-content-into-string's name :d
<beach>
Well, if you had mentioned that to begin with, I could have saved some effort.
<mivanchev>
I am sorry, it was making sense in my head
<mivanchev>
thank you still !
<beach>
Sure.
<jackdaniel>
(setf (fdefinition 'rscis) #'alexandria:read-stream-content-into-string) is one way to make the name shorter
<jackdaniel>
if you replace 'rscis with 'r it will be even shorter!
<mivanchev>
or just slurp ¯\_(ツ)_/¯
chomwitt has joined #commonlisp
<jackdaniel>
technically speaking "r" is shorter than "slurp" and that's what we are optimizing for
<mivanchev>
I understand the idea and subscribe to it but this is for an article and the code has to presentable because it's a pro-lisp article to be revealed shortly
<mivanchev>
and i'll also ask you all for some feedback
<mivanchev>
right now the purpose of the task is masked by somewhat longer symbols
<jackdaniel>
Paul Graham proposed defabbrv macro or something like that in "onlisp"
admich1 has quit [Ping timeout: 248 seconds]
<Shinmera>
hooray, #elsconf has been reclaimed. It'll stay the channel for ELS discussions (especially for live chat during the conferences) going forward
<jackdaniel>
you may read whole section where the author seems to have a similar insight to yours
<beach>
Shinmera: Excellent!
<mivanchev>
it's not my insight, it's just for this use case :) but i'm reading!!!
tuck has joined #commonlisp
admich1 has joined #commonlisp
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
JuanDaugherty has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]
<flip214>
Can I check whether a form has side-effects? I've got a macro that expands to some symbol-macros, and some expand to (ldb (byte x y) ,input) -- so it might be good to warn if input has side-effects like with (aref vec (incf i))
<flip214>
because of setf on the symbol-macros I can't just have a gensym get the value of the incoming form...
<flip214>
I guess it's a documentation issue
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
decweb has joined #commonlisp
v88m has joined #commonlisp
King_julian has quit [Read error: Connection reset by peer]
v88m has quit [Read error: Connection reset by peer]
brainfunnel has quit [Remote host closed the connection]
brainfunnel has joined #commonlisp
King_julian has joined #commonlisp
livoreno has joined #commonlisp
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
veqq has joined #commonlisp
tjbw has joined #commonlisp
<beach>
Well, whether a form really does have side effects is undecidable. You can make a decidable conservative approximation of that, but you would still have to know whether each function being called, directly or indirectly, might have a side effect. And you probably can't know that in general.
<beach>
For instance, if some form contains a call to an implementation-specific function, perhaps indirectly when a standard macro contains that call in its expansion, you would need to know what that function does.
bpanthi977 has joined #commonlisp
v88m has joined #commonlisp
mgl_ has quit [Remote host closed the connection]
bpanthi977 has quit [Ping timeout: 252 seconds]
admich1 has quit [Read error: Connection reset by peer]
admich1 has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
<_death>
well, depends on how conservative the approximation is.. e.g., you can start with a set of non-side-effecting operators and everything else is suspect.. you can let the user extend this set at their own peril.. but seems your actual problem is more specific.. maybe not expand to ldb then
<beach>
Sure, you can make the conservative approximation always assume that it has side effects and always answer "yes".
gorignak has joined #commonlisp
v88m has joined #commonlisp
reb has quit [Remote host closed the connection]
<_death>
it sounds like the issue is multiple evaluation.. maybe get-setf-expansion can help
v88m has quit [Read error: Connection reset by peer]
veqq has quit [Quit: veqq]
bpanthi977 has joined #commonlisp
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
eddof13 has joined #commonlisp
v88m has joined #commonlisp
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
nytpu has quit [Remote host closed the connection]
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
mivanchev has joined #commonlisp
<mivanchev>
hey, any shortcut for importing many symbols from a package?
<beach>
I strongly advise against importing symbols, and instead suggest the use of package-local nicknames.
<mivanchev>
can you give me an example beach ?
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
<beach>
There are tons of examples. Let me see if I can find a representative one.
<mivanchev>
does the package have to define a nickname?
rtypo has joined #commonlisp
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
<beach>
If you want package A to use a symbol from a package (say) BBBBBBBB, then the package A must be defined using say (:local-nicknames (#:B #:BBBBBBBB)) You can then say B:mumble instead of BBBBBBBB:mumble in A.
<beach>
BT is a local nickname for CLUMP-BINARY-TREE.
<mivanchev>
tnx, that's really useful :)
<beach>
Great!
bpanthi977 has quit [Ping timeout: 248 seconds]
molson has joined #commonlisp
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
bpanthi977 has joined #commonlisp
livoreno has quit [Quit: Connection closed for inactivity]
v88m has joined #commonlisp
bpanthi977 has quit [Ping timeout: 245 seconds]
<tuck>
mivanchev: otherwise, you can use functions such as (do-external-symbols (s source-package) (import s destination-package))
<flip214>
beach: _death: thanks. Yeah, get-setf-expansion might be possible -- I'll just document that users need to be careful about PLACE. Thanks!
ingeniot has joined #commonlisp
<tuck>
mivanchev: Let's say that a good style in CL is to define packages with declarative forms. export and import are normal, run-time functions. When you modify packages with them, (even if you take care to do it in the compilation environment as you should), the compilers don't necessarily take good note of it, so they may have difficulty checking the symbols at compilation-time. Hence beach's advice (even if in this specific case,
<tuck>
package local nicknames is an extension, not standard CL).
<tuck>
I had to spend a couple of weeks unmessing a mess of spaghetti-packages that were defined at run-time with export/import into a clean set of defpackage…
eddof13 has quit [Quit: eddof13]
eddof13 has joined #commonlisp
bpanthi977 has joined #commonlisp
triffid has quit [Ping timeout: 264 seconds]
ingeniot has quit [Ping timeout: 244 seconds]
bpanthi977 has quit [Ping timeout: 265 seconds]
kevingal has joined #commonlisp
kevingal has quit [Client Quit]
bpanthi977 has joined #commonlisp
tuck has quit [Ping timeout: 265 seconds]
triffid has joined #commonlisp
stanrifkin has joined #commonlisp
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
<aeth>
it's _really_ tempting to export that way, more so than importing... if you're generating a lot of functions.
<aeth>
but, yes, I wouldn't trust compilers to handle it optimally
tjbw has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ixelp>
It's really inconvinient that `fmap` is not a parser · Issue #4 · fosskers/parcom
<mivanchev>
it's a parser for git log output, can someone share their thoughts on how to make it more "representative" for lisp ?
bpanthi977 has quit [Ping timeout: 248 seconds]
<trannus_aran>
building drakma the old-school way with just asdf, and it complains there's no puri
bpanthi977 has joined #commonlisp
<trannus_aran>
no prob, grab the latest tarball and throw it in .local/share/common-lisp/source
v88m has quit [Remote host closed the connection]
v88m has joined #commonlisp
<trannus_aran>
but here's the rub: now it needs CL-base64, which I *can* find a git repo for, but curiously it's a clone of a git forge that doesn't exist anymore, which is also the upstream source for the debian cl-base64 package
<trannus_aran>
I presume it's just cached on debian's build servers or some such? and I suppose base64 encoding is pretty much a "it's solved" kinda task in this case, so no need to update
<trannus_aran>
but just thought it's curious that the official .deb's source goes to rotted link
bpanthi977 has quit [Remote host closed the connection]
sveit has joined #commonlisp
JuanDaugherty has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
gorignak has quit [Ping timeout: 265 seconds]
bpanthi977 has joined #commonlisp
gorignak has joined #commonlisp
thuna` has joined #commonlisp
v88m has joined #commonlisp
ecraven- is now known as ecraven
v88m has quit [Read error: Connection reset by peer]
yitzi has joined #commonlisp
<sveit>
There are applications where a single concrete object (for a simple example I will use a number, 7) can be viewed as several different types (7 could be an integer or an element "mod 9", etc), which should change how it should act under various operations (like addition). How is this typically handled in Common Lisp? In Haskell and C++, one uses type wrappers all over the place, but they are "free" in terms of performance. In Common
<sveit>
Lisp I guess I see two solutions: type wrappers (which I believe add a runtime cost) and eql-dispatch on generic functions (in this example, one would have a signature (g+-bin module e1 e2) where the "module" argument specifies how addition should behave)
<sveit>
there are also other options. I am curious how people solve this problem in practice
bpanthi977 has quit [Ping timeout: 252 seconds]
bpanthi977 has joined #commonlisp
v88m has joined #commonlisp
soweli_iki has joined #commonlisp
<dlowe>
explicitly different functions
<dlowe>
defining mod-+, mod--, mod-*, mod-/ etc
<beach>
mivanchev: I am not sure what you are asking.
<dlowe>
With basic common lisp functions, the need for automatic dispatch can be avoided by calling different code on the same data
<dlowe>
beach: they want to change the effective type of a datum and have everything dispatch on the effective type.
<beach>
dlowe: I think that's what sveit might want. But what about mivanchev?
<dlowe>
whoops, I didn't read that far back
v88m has quit [Read error: Connection reset by peer]
JuanDaugherty is now known as ColinRobinson
admich1 has quit [Ping timeout: 252 seconds]
<beach>
I try not to get involved with discussions about types.
<dlowe>
oh, mivanchev seems to want us to think hard about their code and refine it.
<beach>
They are usually about mimicking the behavior of some statically typed language.
admich1 has joined #commonlisp
<beach>
Oh, now I see the code. Sorry for the noise.
<sveit>
dlowe: that is indeed what I want, but it adds a strange and somewhat random boundary between generic and non-generic code, determined laregely by programmer mood :]
<sveit>
beach: but on occasion the behaviour of a statically typed language can be desirable, no?
<beach>
mivanchev: I am off for tonight, but that code needs a lot of work, so if you are around tomorrow morning (UTC+2) we can continue the discussion.
<beach>
sveit: Possibly. But most of the time types come up in #commonlisp or #clschool, it is not one of those occasions, so I keep wasting my time by trying to understand.
<dlowe>
sveit: you say programmer mood, I say programmer judgement born by long years of experience and gray hairs
<dlowe>
Though this strange boundary between generic and non-generic code exists within common lisp itself, so it's not so surprising
<aeth>
sveit: If you want types to be disjoint, you have to do something like wrapping them in a struct of one slot (cheapest access).
<dlowe>
To complicate the matter, the meaning of generic and non-generic is swapped in CL and statically typed languages
<dlowe>
Because a non-generic CL function will take any data without reference to its type.
_whitelogger has joined #commonlisp
<sveit>
aeth: but implementation-wise they could be distinguished at some point well before any inner loop, and a specialized or at least cached set of methods could be called to do any math. and probably most similarly to Haskell newtypes, if all the wrapping and unwrapping is happening in a single function it could be "free" and only used by the compiler to choose functions.
v88m has joined #commonlisp
<aeth>
You can't use type erasure to make the necessary defstruct have zero cost becaue the type exists at runtime, boxed on the heap. (Technically, you can. Sometimes. Certain double-float and (unsigned-byte 64) and (signed-byte 64) stuff are not boxed on the heap in certain implementations under certain conditions even when they "should" be. But I don't think anyone unboxes a struct of one slot and unboxing a
<aeth>
standard object would be even more difficult.)
v88m has quit [Read error: Connection reset by peer]
<aeth>
sveit: Implementation-wise, you _could_ (probably only in SBCL) if it was a common enough idiom to define a struct of one slot to e.g. distinguish between the three meanings of (simple-array single-float (4)) I gave (vec4, quat, mat2x2) or the infinite different things a single scalar could mean. It's just not done, so it's not optimized.
<aeth>
sveit: What I personally do is I write my own little language inside of a macro that distinguishes between the runtime values and my own compile-time type inference (distinct from what the implementation's own inference may or may not do)... then I can have as many disjoint compile-time-types as I want with the same runtime representation.
<sveit>
aeth: do you have an example of such a little language in a macro? I'm curious how extensible/practical such a thing is
ColinRobinson has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]
rgherdt has quit [Ping timeout: 252 seconds]
rgherdt has joined #commonlisp
v88m has joined #commonlisp
<mivanchev>
beach, I'll tune in :)
pranav has quit [Remote host closed the connection]
mivanchev has quit [Quit: Leaving]
<aeth>
sveit: not very... the _implementation_ is not very little, and isn't complete
pranav has joined #commonlisp
Guest47 has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
chomwitt has quit [Ping timeout: 265 seconds]
<sveit>
aeth: would still be interested to see an example :) I am getting the sense (based on vec4 vs quat example) that we are trying to deal with similar problems
<sveit>
one of the big advantages of CL for me is quickly prototyping in something that isn't so far from "production" performance quality that I can run non-trivial experiments, and have the confidence that I don't have to make dramatic changes to push the performance. usable generics would just alleviate some amount of mental effort that seems to be necessary for every particular situation (and for all its faults, C++ seems not to have th
<sveit>
particular issue)
brainfunnel has quit [Ping timeout: 252 seconds]
<dlowe>
I'd like to point out that the CL language itself, when faced with a similar problem (strings are vectors are sequences) solved it by providing different interfaces to each interpretation.
<dlowe>
It's not some unnatural niche opinion, it's the lisp norm
<dlowe>
You might be more comfortable with coalton, which is built on top of common lisp.
<dlowe>
(though I haven't been tracking its liveness)
<aeth>
dlowe: yes, but a (simple-array character (*)) isn't a (simple-array (unsigned-byte 32) (*)) as well. Because it has the "character" abstraction with the special case for specialized arrays even though they're normally only for homogeneous numeric types (in fact, only characters/strings are special cased)
<aeth>
which is a good thing because there'd be a decent chance of it ending up as (unsigned-byte 16) instead
<aeth>
but you don't have this ability.
<aeth>
Even though, "under the hood" (in the actual bytes), except for the type prefix at the start of the array, a (simple-array character (*)) is probably a (simple-array (unsigned-byte 32) (*)) in modern implementations.
v88m has joined #commonlisp
ingeniot has joined #commonlisp
<sveit>
this is actually a nice example which is different from mathematics that illustrates my concerns/annoyances. one might want to execute the same algorithms, but efficiently, on strings encoded in different ways (unicode, ascii, whatever). so conceptually it's clear that there should be functions on strings which go beyond their nature as vectors or sequences. that's fine. but there should be a few generic primitives that are used
<sveit>
efficiently in other algorithms, and I think it makes sense to make the dispatch as efficient as possible, at least in typical usage
<sveit>
so even in this case I wouldn't agree that "providing different interfaces to each interpretation" actually solves the problem. at a high level, you are still "forced" to use generic operations if you want to handle different string types. but at that point you might as well have used generic functions all the way down (if what you care about is the performance penalty.)
<sveit>
and what's so frustrating is that the amazing SBCL work makes everything so tantalizingly close! for example, if one defines an interface now for each string, and passes this interface as unpacked arguments to more complicated algorithms, SBCL will optimize unbelievably well
v88m has quit [Read error: Connection reset by peer]
<aeth>
sveit: I can't really share what I have because it's not ready. But I basically do my own monomorphization and, using the same mechanism, type erasure of disjoint types with the same underlying representation.
<aeth>
It requires walking through the entire macro, though, so it's a separate language at that point. Just one that looks like an extended CL subset.
<sveit>
It just seems surprising that this sort of application/design appears to have been overlooked by the designers of CL and SBCL. Rather I am assuming that I am missing something about how THEY imagined these problems would be solved in practice...
<aeth>
sveit: Well, the design of CL stopped in 1994 and was mostly done by 1984.
<aeth>
it was also _Common_ Lisp, so they might have imagined various industry vendors extending the common baseline in different directions on their distinct Lisp Machine platforms
brainfunnel has joined #commonlisp
v88m has joined #commonlisp
livoreno has joined #commonlisp
chomwitt has joined #commonlisp
zwr has quit [Read error: Connection reset by peer]
notzmv has joined #commonlisp
zwr has joined #commonlisp
<yitzi>
sveit: The ANSI committee avoided requiring the usage of generics wherever they could. Generics were seen as very slow then. They rejected the Gray stream protocol for this reason.
<aeth>
My solution requires a lot of both CPU (mostly at compilation time, though) and memory that would've been painful in the '80s/'90s
apac has joined #commonlisp
v88m has quit [Remote host closed the connection]
bpanthi977 has quit [Ping timeout: 244 seconds]
notzmv has quit [Remote host closed the connection]
v88m has joined #commonlisp
notzmv has joined #commonlisp
bpanthi977 has joined #commonlisp
v88m has quit [Ping timeout: 252 seconds]
varjag has joined #commonlisp
eddof13 has quit [Quit: eddof13]
bpanthi977 has quit [Ping timeout: 252 seconds]
kevingal has joined #commonlisp
bpanthi977 has joined #commonlisp
ingeniot has quit [Ping timeout: 260 seconds]
bpanthi977 has quit [Ping timeout: 260 seconds]
stanrifkin has quit [Quit: Leaving]
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
<sveit>
Thanks! Out of curiousity is the prevailing wisdom for the future of Common Lisp that we will have these bespoke "compilers" for various domains, or someone will come up with the "right" library on top of CLOS, or that there will come an implementation that will have optimizations for CLOS/generics?
waleee has joined #commonlisp
mishoo has quit [Ping timeout: 252 seconds]
eddof13 has joined #commonlisp
v88m has joined #commonlisp
v88m has quit [Remote host closed the connection]
v88m has joined #commonlisp
eddof13 has quit [Client Quit]
GalaxyNova has joined #commonlisp
JuanDaugherty has joined #commonlisp
rkazak has joined #commonlisp
rkazak has quit [Changing host]
rkazak has joined #commonlisp
<jackdaniel>
I don't understand the question
<sveit>
jackdaniel: the question is that at least myself, but also many others dance around the CLOS generics at least in part because of either percieved or real performance issues. one way around this is to build a DSL each time, but you end up re-implementing some version of generic often and it feels "wrong" (again, just to me)
<jackdaniel>
beach came up with a JIT for generic function dispatch (implementation technique)
<jackdaniel>
and there are fast generic functions by heisig that optimizes critical paths by sealing and other fancy methods so dispatch can be sometimes inlined
<sveit>
is beach's technique in use in any compiler? or are there plans to include it in, say, SBCL?
<jackdaniel>
clasp uses it, sicl probably too
<jackdaniel>
I've made a poc implementation for ecl a few years back and it waits on my queue to clean it up
v88m has quit [Remote host closed the connection]
<jackdaniel>
I don't think that it is planned for incorporation in sbcl
v88m has joined #commonlisp
eddof13 has quit [Client Quit]
<jackdaniel>
it has a drawback that a cache miss triggers recompilation and that is initially awful for performance; but once the call history contains used combinations it is optimal; and of course adding some threshold for recompilation is up to the implementer to amortize the cost
<jackdaniel>
s/used/all used/
<|3b|>
presumably that "optimal" is still for runtime dispatch per call?
<jackdaniel>
yes, it is a binary search over fixnum tags
<jackdaniel>
to find the right effective functions
JuanDaugherty has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]
* |3b|
wonders if something like a perfect hash + array lookup would be better for large #s of methods (and how large the # would have to be)
<|3b|>
(or even a fairly-good hash, at the expense of some memory)
<|3b|>
though for most of the things where i end up not using clos, i'd probably want the dispatch moved outside of some loop anyway :/
<jackdaniel>
interesting thought (about a perfect hash)
<|3b|>
i guess it is # of combinations actually called, rather than # of methods, not sure if that makes it better or worse or both
<|3b|>
bike: yeah, that's the array lookup
<bike>
but yeah, binary search might not be optimal. in clasp we lower it as a multiway branch and let llvm do whatever it does with those, since it's np-complete or something
ewig has quit [Remote host closed the connection]
* |3b|
also assumes it is an exact match rather than range search
<jackdaniel>
then maybe not optimal, but acceptable :) in any case I'm off to bed, take care
<|3b|>
yeah, sublinear at least, and probably within a few cache lines for many cases :)