bitmapper has quit [Quit: Connection closed for inactivity]
galex-713_ has joined #lisp
galex-713 has quit [Ping timeout: 265 seconds]
galex-713_ has quit [Ping timeout: 246 seconds]
galex-713 has joined #lisp
Oladon has quit [Quit: Leaving.]
ebrasca has quit [Remote host closed the connection]
galex-713 has quit [Ping timeout: 246 seconds]
galex-713 has joined #lisp
wxie has joined #lisp
shifty has joined #lisp
adlai has joined #lisp
notzmv has joined #lisp
notzmv is now known as Guest94966
galex-713_ has joined #lisp
galex-713 has quit [Ping timeout: 265 seconds]
Guest94966 is now known as notzmv
madage has quit [Ping timeout: 268 seconds]
shifty has quit [Ping timeout: 260 seconds]
sm2n has quit [Ping timeout: 245 seconds]
shifty has joined #lisp
madage has joined #lisp
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
skapata has quit [Remote host closed the connection]
galex-713_ has quit [Ping timeout: 260 seconds]
Oladon has joined #lisp
<adlai>
why did nobody give minion a strongly-worded opinion about duck typing for when I returned?
galex-713 has joined #lisp
mindCrime_ has quit [Ping timeout: 260 seconds]
* adlai
wonders what is the proper extension of "write out at least three samples from the macro's range before writing the defmacro itself" to the problem of fundamental language extensions
<adlai>
e.g., scalpl includes an unspecified, badly implemented version of the "Actor" concurrency model; yet scalpl is arguably no more than two libraries, so there are not enough examples for properly ripping actors.lisp yet
wxie has quit [Ping timeout: 260 seconds]
shifty has quit [Ping timeout: 264 seconds]
<adlai>
meanwhile, my latest bad idea overlaps significantly with the one about duck-typing, although it pertains to the definition of new generic functions, rather than the deliberately concealed abuse of existing ones
shifty has joined #lisp
<adlai>
for those who missed the previous screed: the "deliberately concealed abuse of existing ones", i.e. duck-typing a generic function, would be an extension where you could call generic functions on arguments of indeterminate type, without modifying that function's method list
galex-713_ has joined #lisp
galex-713 has quit [Ping timeout: 265 seconds]
sturm_ has quit [Ping timeout: 256 seconds]
galex-713_ has quit [Ping timeout: 265 seconds]
hendursa1 has quit [Quit: hendursa1]
sjtfre has joined #lisp
slyrus has quit [Quit: Leaving]
hendursaga has joined #lisp
<adlai>
maybe there are already libraries for this kind of idiocy?
* adlai
is referring to the duck-typing idea, and is already aware of there being libraries for the Actor model
shifty has quit [Ping timeout: 265 seconds]
sturm_ has joined #lisp
shifty has joined #lisp
sturm_ has left #lisp [#lisp]
<adlai>
however, I have absolutely no idea how to go about searching for this kind of library; it does not fit into the categorisation usually used for listing recommended libraries, because it's not too popular to refer to such fundamental changes.
sturm_ has joined #lisp
sturm_ has quit [Client Quit]
semz has quit [Ping timeout: 244 seconds]
long4mud has joined #lisp
* adlai
begins by reviewing various libraries that duck-type in the context of sequences
wxie has joined #lisp
Helmholtz has joined #lisp
gitgood has quit [Remote host closed the connection]
mindCrime_ has joined #lisp
gitgood has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
semz has joined #lisp
aartaka has joined #lisp
mindCrime_ has quit [Ping timeout: 244 seconds]
Helmholtz has quit [Quit: Helmholtz]
<Josh_2>
Does duck-typing mean each argument must be quack?
Sheilong has quit []
<adlai>
no
<Josh_2>
sad
<Josh_2>
maybe I should make a library where all arguments must be some variety of duck
<adlai>
in CLese, duck typing means that you could specialise methods on types, in addition to classes
<Josh_2>
well that would be nice
<adlai>
so it's somewhere between a default method, defined by COMPUTE-APPLICABLE-METHODS, that pieces together a monstrous TYPECASE
<adlai>
... and one that pieces together a monstrous CTYPECASE
Helmholtz has joined #lisp
<adlai>
it almost certainly does not go as far as ETYPECASE due to the fact that any CL-spirited implementation of the duck typing philosophy would signal a continuable error instead
<adlai>
the other terrible idea partially-overlapping this one is to break lambda list congruency
<adlai>
essentially, equivalence classes for statically determinable calls, instead of required argument congruency
* adlai
notes, in amusement, that nearly every single cliki page encountered in the initial trawl for libraries that might have examples for such patterns leads to Hexstream's public domain works
<adlai>
bloke doesn't seem to drop by IRC too often, though
DHARMAKAYA has quit [Quit: Turning off a portion of this simulation.]
shifty has quit [Ping timeout: 245 seconds]
mathrick_ is now known as mathrick
<adlai>
this whole "Interface-Passing Style" is quite an excellent concept to have in mind during this thread, because it is a step in precisely the opposite direction
rumbler31 has joined #lisp
<adlai>
i.e., IPS makes the interfaces explicit, and the space of lambda lists becomes an external product against whatever space span the interfaces
<Nilby>
I made a thing which basically just wraps the standard sequence-like functions in generics, so they're extensible. It's a dumb slow idea, but it seems to work just fine for me. LIL/IPS is to fancy for me.
kaiwulf has quit [Ping timeout: 265 seconds]
<Bike>
ideally you'd be able to use the sequences extension or the like for that
<Bike>
let's you do that stuff without messing with performance too badly
rumbler31 has quit [Remote host closed the connection]
<Nilby>
Yes, except that it only works on one? implemetation, and I also added list, string, and character stuff. But it's true I could make some of it run faster on sbcl.
prxq_ has joined #lisp
<Nilby>
What I really wish is that everywhere had extensible loop.
Josh_2 has quit [Remote host closed the connection]
<Nilby>
Bike: Thanks. The fallback code is pretty close to what I did. One could hope that other implementations could do this too.
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
Alfr is now known as Guest60816
Guest60816 has quit [Killed (tepper.freenode.net (Nickname regained by services))]
Alfr has joined #lisp
akoana has left #lisp ["Leaving"]
cods has joined #lisp
wxie has quit [Ping timeout: 256 seconds]
slyrus has joined #lisp
DHARMAKAYA has joined #lisp
Oladon has quit [Quit: Leaving.]
<beach>
Good morning everyone!
cchristiansen has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
Bike has quit [Quit: Lost terminal]
wxie has joined #lisp
<adlai>
it is a mediocre morning, for I have not yet officially adopted the anaphora library, and nobody else seems to find its stated lack of a maintainer troubling.
* adlai
actually uses that library all over scalpl, so taking over as maintainer is not a completely terrible idea
<beach>
I don't know exactly what that library contains, but many of the anaphoric macros in On Lisp encourage direct violations of the "rules" stated on page 13 of the LUV slides, so I don't use them for that reason.
pankajsg has joined #lisp
<beach>
Like, if AWHEN were to be used according to those rules, then IT would always return `true' and no useful value.
<adlai>
it's mostly macros that add one quantum of unhygienity, although they do it consistently with the way that happens in LOOP
<beach>
I also don't use IT in LOOP.
* adlai
has recently encountered the anaphoric-variants library, that purports to make that quantum hygienic, although it still breaks from the exact pattern of variable binding seen in LET etc
rozengla` has quit [Remote host closed the connection]
shifty has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
sauvin has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
shifty has quit [Ping timeout: 246 seconds]
shifty has joined #lisp
rumbler31 has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
rumbler31 has quit [Ping timeout: 256 seconds]
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
kam1 has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
marusich has joined #lisp
sjtfre has quit [Ping timeout: 260 seconds]
shoshin1 has joined #lisp
herlocks- has joined #lisp
herlocksholmes has quit [Ping timeout: 260 seconds]
shoshin has quit [Ping timeout: 260 seconds]
shoshin1 is now known as shoshin
sjtfre has joined #lisp
frost-lab has joined #lisp
hjudt has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
phantomics has quit [Ping timeout: 244 seconds]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
shifty has quit [Ping timeout: 246 seconds]
shifty has joined #lisp
amb007 has joined #lisp
kam1 has joined #lisp
ex_nihilo has joined #lisp
kam1 has quit [Read error: Connection reset by peer]
sjtfre1 has joined #lisp
sjtfre has quit [Read error: Connection reset by peer]
narimiran has joined #lisp
waleee-cl has quit [Quit: Connection closed for inactivity]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
kam1 has joined #lisp
kam1 has quit [Client Quit]
sjtfre has joined #lisp
sjtfre1 has quit [Ping timeout: 256 seconds]
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
sjtfre has quit [Read error: Connection reset by peer]
sjtfre1 has joined #lisp
<lukego>
Hey I just noticed Serapeum's WITH-BOOLEAN macro and it gets me thinking about whether Lisp macros can be (have been?) used to do speculative optimizations like the "specializations" in a tracing JIT?
<lukego>
For example, you write a function and declare that X Y Z *might* be fixnums, and the compiler compiles the code twice - once with fixnum arithmetic and once with generic arithmetic - and then carefully inserts all necessary guards to branch between them based on actual types at runtime
wooden has quit [Read error: Connection reset by peer]
wooden has joined #lisp
<White_Flame>
yep, I've done that. Especially in macros where you can blap in multiple copies of the same code body surrounded by different declarations, it's pretty easy
<White_Flame>
you don't even need type declarations there, since the typecase implies them
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
<beach>
We do something similar in the SICL sequence functions. Not only for types, but for certain combinations of keyword arguments, such as :TEST and :KEY.
sjtfre has joined #lisp
<White_Flame>
and also compiler-macros might be useful if things can be statically determined well enough
ficl has joined #lisp
sjtfre1 has quit [Ping timeout: 245 seconds]
<White_Flame>
however, that same static analysis should be able to collapse away statically known unused paths of the generic macro expansion as well
sjtfre1 has joined #lisp
<White_Flame>
and thus leaving more to the compiler than the macro author
sjtfre has quit [Ping timeout: 256 seconds]
phantomics has joined #lisp
<lukego>
Great to hear that this is a known thing. I need to think a bit more about how it corresponds to the optimizations that LuaJIT does. I guess the main things are that you can chain/nest a bunch of those optimizations and that it aggressively inlines function calls to take advantage of the declarations.
<lukego>
It would be cool if you could implement a "LuaJIT" as a Lisp macro :-) and maybe even better to do the specialization annotations directly rather than to detect them at runtime for the sake of sanity
Klopsch has joined #lisp
sjtfre1 has quit [Read error: Connection reset by peer]
sjtfre has joined #lisp
sjtfre has quit [Ping timeout: 260 seconds]
<lukego>
White_Flame: I think the nice thing about the runtime-dispatched specialization verses the compiler-macro approach is the simplicity. If you have an intuition for e.g. which arithmetic operations are likely to be fixnum then you can just tell the compiler that - make sure there's a fixnum-optimized version of this code available - rather than proving or promising it.
orivej has joined #lisp
<lukego>
but then it interacts non-trivially with the related optimizations that the CPU is doing e.g. that even if you're calling generic arithmetic functions it will speculatively take the fixnum paths and push all the bignum stuff off to the side.
<lukego>
Fun idea to play with in the background anyway.
varjag has joined #lisp
<White_Flame>
right, and as I said the compiler might collapse the runtime version into a single proven static path anyway, in the right contexts
<White_Flame>
without needing compiler macros
varjag has quit [Client Quit]
<lukego>
ah
hjudt has quit [Remote host closed the connection]
<White_Flame>
so it's kind of best of both worlds
<White_Flame>
however, "intuition" can often be shown wrong by metrics, so it's always good to test such assumptions
<lukego>
yeah true I hadn't considered that you could get a double-payoff when the specializations allow compiler macros etc to kick in for the optimized path
<moon-child>
lukego: I don't think it makes very much sense as macro anyway. The whole point of jit is _dynamic_ tracing, adapting and automatically recompiling code in response to hot paths
<moon-child>
I don't think luajit does this, but afaik hotspot will do things like change branch layouts as workloads change
<lukego>
moon-child: I dunno. In practice the dynamic-ness seems to mostly make people sad because it's too unpredictable. I wonder if a static version might even be better.
<lukego>
LuaJIT approach to changing workload is "oh... it would be better if you avoid doing that"
<White_Flame>
moon-child: the only time this is useful is when the benefits of hoisting the typecheck are high, usually containing loops
surabax has joined #lisp
<moon-child>
White_Flame: exactly the sort of thing dynamic analysis helps with; you can't always statically determine which loops are hot
Major_Biscuit has joined #lisp
<moon-child>
(pgo can do that too, granted. I don't think any lisp implementations do pgo, though, but that would be cool)
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
<lukego>
The case where LuaJIT perhaps leveages this optimization the most is actually function calls. If you /think/ that a function definition then instead of making a full call you can make a more direct jump - or even inline - on a fast-path with a "guard" that checks the identity of the function object (and bails to slow path if it's changed)
tiwEllien has quit [Ping timeout: 246 seconds]
tiwEllien has joined #lisp
<lukego>
In that case the JIT is so aggressive that it doesn't even have the concept of a function call. Every call is inlined, without exception, with a bailout from the fast-path if the definition has changed.
schweers has joined #lisp
<lukego>
(nor does it have the concept of a conditional branch - except for "bail out from fast path" - because all control flow is also predicted/specialized)
<lukego>
anyway, I must try to make a one-page specializing compiler as a Lisp macro one day :)
<lukego>
(you know, based on the premise that what SBCL users really need is to make their programs 10% faster at the cost of 10x slower compilation)
sjtfre has joined #lisp
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #lisp
<White_Flame>
yeah, beach is working on call-site optimization for method dispatch
<White_Flame>
the proper runtime variation of it
IPmonger has quit [Ping timeout: 245 seconds]
<White_Flame>
however, it's a self-modification of the call site instruction itself, not an inlining of the commonly found function
<White_Flame>
no lisps that I'm aware of due "full" jit recompilation yet
<White_Flame>
(unless you count ABCL's inheriting of JVM features)
IPmonger has joined #lisp
<White_Flame>
s/due/do/
<White_Flame>
fastpaths for data specialization remain more targeted, manual optimizations for us all
<White_Flame>
at least for now
Major_Biscuit has quit [Ping timeout: 265 seconds]
matryoshka has quit [Ping timeout: 265 seconds]
<lukego>
I've spent quite some years optimizing LuaJIT programs and I have to say that manual static declaration of optimization goals sounds just fine to me. The dynamic stuff is great for prototyping but too much work for productionizing.
Lord_of_Life has joined #lisp
IPmonger has quit [Ping timeout: 244 seconds]
<moon-child>
that's fair
<lukego>
LuaJIT programs have the dubious distinction that they often get /slower/ when moving from prototype to production i.e. optimizations are successively disabled to make the performance more predictable.
random-nick has joined #lisp
sjtfre has quit [Read error: Connection reset by peer]
sjtfre has quit [Read error: Connection reset by peer]
sjtfre has joined #lisp
Demosthe1ex has joined #lisp
DHARMAKAYA has quit [Quit: Turning off a portion of this simulation.]
Demosthenex has quit [Ping timeout: 260 seconds]
albusp has quit [Ping timeout: 256 seconds]
sjtfre has quit [Remote host closed the connection]
hendursa1 has joined #lisp
hendursaga has quit [Ping timeout: 268 seconds]
luni has joined #lisp
pve has joined #lisp
shka_ has joined #lisp
* lukego
prints beach's paper
anticrisis has quit [Read error: Connection reset by peer]
<beach>
lukego: I have come up with several new techniques over the past 7 years, including better generic dispatch, path replication, partial inlining, first-class global environments, etc. But I think this latest one is going to have the most impact.
amb007 has quit [Read error: Connection reset by peer]
sm2n has joined #lisp
amb007 has joined #lisp
hiroaki has quit [Ping timeout: 265 seconds]
sauvin has quit [Ping timeout: 260 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
rumbler31 has joined #lisp
sauvin has joined #lisp
notzmv has quit [Read error: Connection reset by peer]
rumbler31 has quit [Ping timeout: 265 seconds]
hiroaki has joined #lisp
datajerk has quit [Ping timeout: 256 seconds]
shifty has quit [Ping timeout: 245 seconds]
shifty has joined #lisp
sm2n has quit [Ping timeout: 265 seconds]
Nilby has quit [Ping timeout: 264 seconds]
SpaceIgor2075 has joined #lisp
SpaceIgor2075 has quit [Remote host closed the connection]
shifty has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
Jesin has quit [Ping timeout: 276 seconds]
datajerk has joined #lisp
admich has joined #lisp
varjag has joined #lisp
luni has quit [Quit: Connection closed]
wxie has quit [Ping timeout: 260 seconds]
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
frgo has quit [Remote host closed the connection]
shifty has quit [Ping timeout: 264 seconds]
frgo has joined #lisp
shifty has joined #lisp
wxie has joined #lisp
<White_Flame>
beach: ah right, it was for bypassing the dynamism of &key and &optional as well
<White_Flame>
yes, and looking forward to it all :)
OlCe has joined #lisp
cods has quit [Ping timeout: 265 seconds]
ljavorsk has joined #lisp
cods has joined #lisp
yitzi has quit [Quit: yitzi]
yitzi has joined #lisp
schweers has quit [Ping timeout: 244 seconds]
pankajsg has quit [Ping timeout: 256 seconds]
frost-lab has quit [Ping timeout: 245 seconds]
pankajsg has joined #lisp
<beach>
And by "impact" I mean "impact on SICL performance". I have absolutely no reason to believe that any other Common Lisp implementation will adopt this technique.
<Kingsy>
so I am using vlime (as of yesterday) and I havent seen any completion yet. how far can I take vlime on this front?
<flip214>
Kingsy: if you have a Common Lisp connected via swank, and press eg. "(m-v-b<tab>" you should get a list of possible expansions (like multiple-value-bind).
leb has quit []
<Kingsy>
flip214: so. autocomplete wont work without swank connected right?
supercoven has joined #lisp
<flip214>
Kingsy: no. nvim has no idea _which_ Lisp you're using (Common Lisp, Scheme, kotlin, Clojure, ...) and so won't offer anything; you need to connect to a "Lesser Lisp" (in emacs diction).
<Kingsy>
ok 1 second. I have swank running here. I'll connect to it in nvim and see what I can find
<Kingsy>
ah ha! yeah I see this!
schweers has quit [Ping timeout: 244 seconds]
<flip214>
well, my typical workflow is "vim some/file.lisp", then ",rr" to start my lisp, and then I've got .vimrc files in the local directories that allocate ,<F2> and ,<F3> to load the system here resp. run the tests on it.
<flip214>
and <F2> alone remembers the current form and sends it to swank, <F3> sends the current and the remembered form.
<flip214>
so <F2> to "define" a test-form, and <F3> to change eg. a function and to run a test-form with the new definition.
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
mindCrime_ has joined #lisp
lowryder has quit [Ping timeout: 272 seconds]
frgo has joined #lisp
frgo has quit [Ping timeout: 260 seconds]
heisig has quit [Ping timeout: 260 seconds]
lowryder has joined #lisp
ficl has quit [Remote host closed the connection]
lowryder has quit [Ping timeout: 276 seconds]
lowryder has joined #lisp
nullx002 has quit [Read error: Connection reset by peer]
Major_Biscuit has quit [Ping timeout: 260 seconds]
ebrasca has joined #lisp
frgo has joined #lisp
contrapunctus has joined #lisp
lowryder has quit [Ping timeout: 244 seconds]
warweasle has quit [Quit: gotta go.]
lowryder has joined #lisp
sauvin has joined #lisp
aartaka_d has joined #lisp
lowryder has quit [Ping timeout: 260 seconds]
lowryder has joined #lisp
shka_ has quit [Quit: Konversation terminated!]
sauvin has quit [Ping timeout: 256 seconds]
supercoven_ has joined #lisp
supercoven has quit [Ping timeout: 245 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 26.3)]
<dbotton>
Is there a good way to embed a file in your source code?
shka_ has joined #lisp
<Nilby>
dbotton: It depends what you mean by good, and what kind of file, but you can always compress and base64 encode it and stick it in a string.
<dbotton>
That is more or less what I am looking for, question is more is there a resource for doing that?
<dbotton>
Tool or library
<_death>
not tried it, but maybe (defvar *foo* #.(make-array 1234 :element-type '(unsigned-byte 8) :initial-contents ...)) could work.. when you compile-file it, the array may be externalized so that the fasl contains the binary data as-is
kaiwulf has joined #lisp
<Nilby>
dbotton: I don't know of one, but there probably is. But I imagine things like chipz, salza2, and cl-base64 and a few lines of glue code could do it.
luni has joined #lisp
pankajsg has quit [Ping timeout: 260 seconds]
<_death>
I guess the question is, why would you do that.. why not just have an assets directory? and if you want it part of an image, just read it before saving the image
<_death>
in languages that don't support saving an image, I understand why it may be needed (indeed one of my first C programs did just that..)
<jasom>
dbotton: I agree with _death that reading the file in at load-time is probably superior to embedding it in a source file
<dbotton>
Most of the time I agree
<dbotton>
The issue here was to deliver an asset that may change in the future with my code
<dbotton>
I guess in theory could just copy it automatically at compile time
<jasom>
right
<jasom>
compile-time vs load-time probably doesn't matter in practice on many implementatinos since FASLs tend to be not very portable.
<Nilby>
It's pretty common to see base64 blobs in json, but Lisp people seem to like to keep lower overhead and just read binary data directly.
<Odin->
I think that's a niche that largely exists because JavaScript had literally no decent way to handle binary data at all for a long time.
ebrasca has quit [Read error: Connection reset by peer]
<_death>
welp, I just tried my defvar form with sbcl.. indeed a 17563 bytes long binary data resulted in a 17836 bytes long fasl, so that may be a viable solution
<jasom>
_death: you get something like a 3.8x increase in size of the source though, right? (2.8 base-10 digits per byte, plus the space)
<_death>
jasom: no, it was much longer because it was pretty printed :p
<jasom>
Sometimes I wish generalized references could be passed around as values
Alloc has quit [Remote host closed the connection]
Alloc has joined #lisp
<moon-child>
jasom: you can do that with a closure
sz0 has joined #lisp
<jasom>
moon-child: but at a possible performance cost. You cant do e.g. (let ((x (gref (gethash foo bar))) ...) and use X inside the body of the let without (possibly) doing a hash-lookup each time
<moon-child>
that's fair
Alloc has quit [Remote host closed the connection]
<_death>
you could have a macro that does get-setf-expansion then let over lambda dance.. of course that changes the semantics a bit
<jasom>
_death: yeah, I've done get-setf-expansion tricks before which is what made me say it
<_death>
I was sure pjb had some locatives code around.. hmm
<_death>
maybe it was just a usenet post
admich has joined #lisp
<Bike>
seems like there would be some sharp edges there. if it never did another hash lookup (like, it kept the spot in the hash vector around or something) then as soon as you rehashed problems would occur
<Bike>
you could introduce some kind of flag to deal with that but then there'd be some overhead there
hiroaki has quit [Ping timeout: 265 seconds]
refpga has joined #lisp
narimiran has quit [Ping timeout: 260 seconds]
cosimone has joined #lisp
rogersm has joined #lisp
Lord_of_Life has quit [Ping timeout: 256 seconds]
hiroaki has joined #lisp
cage_ has quit [Quit: Leaving]
rogersm has quit []
orivej_ has quit [Ping timeout: 246 seconds]
dbotton has quit [Quit: This computer has gone to sleep]
Klopsch has quit [Remote host closed the connection]
solrize has joined #lisp
<solrize>
if i want a hash table indexed by strings, am i supposed to have to use :test #'equal and is that a bad idea?
refpga has quit [Remote host closed the connection]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
dbotton has joined #lisp
<jasom>
solrize: yes, and it's a good idea
<jasom>
solrize: some implementations (I forget which) also support :test #'string= which may be more optimized for strings, but it's not portable
josh` has joined #lisp
villanella has quit [Remote host closed the connection]
villanella has joined #lisp
<josh`>
I keep tryna use ~ so I can format my format string nicely but I keep getting an error saying unknown format directive character space
<Bike>
use what, exactly?
<jasom>
josh`: are you doing (format t "~ " ...)?
<Bike>
"~ " in a format string is actually wrong
<josh`>
Well no
<jasom>
josh`: you probably want ~A?
<josh`>
its like "~
<josh`>
oops
<josh`>
its "~#\Newline <lots of spaces> the rest of my string"
<josh`>
#\newline is just representing where I would hit return
<jasom>
josh`: for a literal tilde, you want "~~"
<jasom>
josh`: in a format string, that is
<josh`>
Well I don't want a literal tilde, I want to be able to add a newline so I can format my format string nicely
admich has quit [Remote host closed the connection]
<|3b|>
are numbers, characters, etc. ever "otherwise inaccessible" for purposes of dynamic extent? in particular bignums or other variants that are always boxed
zaquest has quit [Ping timeout: 264 seconds]
zaquest has joined #lisp
* |3b|
isn't sure if 1 and 1 are distinct "objects" or not
orivej has joined #lisp
OlCe has quit [Ping timeout: 246 seconds]
<josh`>
Okay fixed it
srji has quit [Ping timeout: 246 seconds]
srji has joined #lisp
pve has quit [Quit: leaving]
<Bike>
what's the context? i mean, the language is set up so that numbers can be distinct objects even if they are equal
<jasom>
|3b|: every object is an otherwise inaccessible part of itself, so I think yes
saturn2 has quit [Quit: WeeChat 1.0.1]
xlei has joined #lisp
<|3b|>
*or
<|3b|>
of if i store a number into another place, is it still the same object
<jasom>
so (let ((x (some-fn-returning-bignum)) (declare (dynamic-extent x)) ...) should *not* return the bignum from x
clone_of_saturn has joined #lisp
clone_of_saturn is now known as saturn2
<Bike>
i'd say that's implementation-defined, and the implementation is allowed to say yes it's the same object
saturn2 has quit [Client Quit]
<jasom>
an implementation could allow you to safely return it, but it would be non-portable to depend on it
clone_of_saturn has joined #lisp
clone_of_saturn is now known as saturn2
shifty has joined #lisp
spacebat2 has quit [Ping timeout: 246 seconds]
spacebat2 has joined #lisp
<|3b|>
context is dynamic extent declarations on arrays, can i return the contents
* |3b|
notes that one of the examples does that
<|3b|>
jasom: but if i can type in that number, does that can't as making it accessible?
quazimodo has quit [Ping timeout: 264 seconds]
* |3b|
can't type today (or most days for that matter)
<|3b|>
*count
<jasom>
I do think it's safe to assume that separately constructed objects are either distinct or unboxed...
<jasom>
otherwise dynamic-extent could never work
surabax has quit [Quit: Leaving]
<Nilby>
"contorted-example"
<jasom>
so (let ((x 1234567890) (declare (dynamic-extent x)) 1234567890) should IMO be safe regardless of whether or not 1234567890 is a fixnum or bignum. That's not to say that some implementations don't do that wrong, but I would push for it to be classified as a bug if they did.
sxmx has quit [Ping timeout: 246 seconds]
sxmx has joined #lisp
<|3b|>
anything that is EQ comparable is always a new object, so dx works for those, and that covers a lot of things
<Bike>
ugh, now you've got me reading the weirdly phrased definition
<|3b|>
and i think it wouldn't affect things much if it did define whether numbers were the same object or not for purposes of DX
<Bike>
"for each value vij that vari takes on, and for each object xijk that is an otherwise inaccessible part of vij at any time when vij becomes the value of vari"
<jasom>
|3b|: and if you construct it separately then it is either 1) interned (so not otherwise inaccessible) or 2) a distinct object
<Bike>
in the example, the number is put into the array after the fact
<|3b|>
you'd just end up with a stack allocated list/vector/whatever containing heap-allocated numbers if they weren't immediate values
<|3b|>
but i'm not sure the spec actually requires that
<Bike>
so maybe its storage isn't implicated
villanella has quit [Ping timeout: 244 seconds]
<|3b|>
but i don't "construct" numbers
<Bike>
i mean, the value of A is that one vector
<jasom>
I think (let ((x (cons 1234567890)) (declare (dynamic-extent x)) (car x)) is disallowed for the case where 1234567890 is a bignum
shifty has quit [Ping timeout: 240 seconds]
supercoven_ has quit [Ping timeout: 240 seconds]
<Bike>
in that case the number is part of the cons when it's constructed, i.e. when vij becomes the value of vari
<Bike>
so yes
<jasom>
for the same reason that a gensym would be disallowed
quazimodo has joined #lisp
<|3b|>
gensyms are EQ though, and can be described as "constructed" by gensym or whatever
<Bike>
but i think based on the definition merely storing a new value into an existing value bound to the variable might not implicate the storage of the new value
motersen has joined #lisp
<|3b|>
2 gensyms are defined to not be EQ, so are definitely not the same object
<Bike>
so dynamic-extent doesn't allow, like, copying objects, so to speak
<solrize>
weird, sbcl has #'string= but doesn't allow using it as a test for hash
<|3b|>
1234567890 and 1234567890 may or may not be EQ, even if bignums
<Bike>
solrize: you can use sbcl's define-hash-table-test extension to do that
<Bike>
solrize: however, as someone said before, make-hash-table only accepts eq, eql, equal, or equalp in the standard
<Odin->
solrize: Isn't that because the CL spec doesn't allow it?
<Bike>
solrize: you need a hash function that works with the predicate, so you can't just put in arbitrary predicates
<jasom>
solrize: string= is part of the standard, string= as a hash-table test function is not
<_death>
do implementations mutate bignums in practice?
<solrize>
ah thanks
<_death>
it would be strange if (incf x) would allocate a bignum each time
<|3b|>
jasom: mostly i'm just wondering whether the spec explicitly says it is safe or not safe though, rather than whether it can be expected to work :)
sm2n has quit [Quit: Leaving]
hendursaga has joined #lisp
<solrize>
_death it would have to copy the bignum unless the compiler knew there were no other references to it
<Odin->
CLHS takes (eq 3 3) as an example of something that may or may not be true, depending on the implementation.
<_death>
solrize: right.. I'm asking if they actually do that
sm2n has joined #lisp
hendursaga has quit [Remote host closed the connection]
<solrize>
well the situatuations were the compiler could tell would be limited
hendursaga has joined #lisp
<|3b|>
Odin-: right, that's what makes it unclear whether two numbers with the same type and value are the same "object" for spec purposed or not
hendursa1 has quit [Ping timeout: 268 seconds]
<Bike>
sbcl has code for mutating bignums, but i think it's only used in internal operators
<Odin->
So I guess it makes sense that it's unclear what the spec says.
<Bike>
e.g. in bignum-gcd it allocates two intermediate bignums and repeatedly mutates them.
<Bike>
(sometimes)
<|3b|>
not even implementation dependent, a particular implementation is allowed to do so sometimes and not others
<_death>
Bike: I expected that.. but what about user code?
<Odin->
Well, from the spec's perspective that's just an implementation choice.
<Bike>
given that sbcl uses these operators manually in its own code, i would guess that there aren't any compiler transformations in place to turn standard operations into mutating operations
<Bike>
i t hink it would be pretty difficult in practice for the compiler to figure out whether bignums are reused
<_death>
Bike: I feel a trivial-bignums coming on :)
<|3b|>
on sbcl, (let ((a (make-array 2 :initial-element (expt 2 66)))) (eq (expt 2 66) (aref a 0))) => 2, which suggests on at least that implementation numbers are "otherwise accessible" by means of constant folding :p
<|3b|>
(if they aren't foldable constants, it returns NIL)
<Bike>
eq returns 2?
<|3b|>
T
<|3b|>
did i mention i can't type? :/
<Bike>
oh yeah ok.
<|3b|>
it at least starts with the right letter?
dbotton has quit [Quit: Leaving]
<|3b|>
so i guess the consensus is that the spec doesn't say, and it is reasonable to assume that it isn't safe to return bignums from a dx container. does it also seem reasonable to say it should be safe to return values from a specialized array?
<|3b|>
(do any implementations have upgraded element types that are still boxed in the array?)
<Bike>
probably not
<Bike>
like why bother at that point
<|3b|>
well, they might not have immediate values for any types, or some subset of the requires specializations
<jasom>
|3b|: sorry had to go afk; like I said two separately constructed bignums are either interned (safe) or distinct (safe), but a single bignum constructed with the container object is not safe
<Bike>
also my reading is rather that it's unsafe for any value that was part of the value assigned to the variable to escape, so (let ((L (list (expt 2 66)))) (car L)) is unsafe but (let ((L (list nil))) (setf (car L) (expt 2 66))) is ok
OlCe` has joined #lisp
<Bike>
and practically speaking i don't think any implementations actually do anything with dynamic-extent declarations except for the initial binding
<Bike>
if i'm wrong i would like to hear about it
<Nilby>
Experiments seem to indicate it's okay to return contents of a dynamic-extent array.
<Nilby>
but don't every return the array
andreyorst has quit [Ping timeout: 265 seconds]
<jasom>
Nilby: I bet most implementations don't recurse into boxed items in the array for doing dynamic-extent, but they *are* allowed to by the spec.
<|3b|>
or does it just not say, and that's what most implementations do
<|3b|>
jasom: does the spec say that though?
<|3b|>
and as shown by above example, "Separately constructed" is ambiguous
<Bike>
sbcl is actually pretty specific about what it does
andreyorst_ has joined #lisp
<Bike>
it gives the example (let* ((a (list 1 2 3)) (b (cons a a))) (declare (dynamic-extent b)) ...) and says that a is also stack-allocated
<|3b|>
and more concerned about values stored (only) in the container within the DX scope
<Bike>
i don't think the spec definition has anything about construction at all
<jasom>
Bike: they don't, but it is implicit
<Bike>
i don't think so
<|3b|>
jasom: unless the compiler folds them to 1, which sbcl does
<Bike>
i think it's about values that are stored in the variable
<jasom>
(eq (expt 2 66) (expt 2 66) <-- if this returns T then the objects are interned, if it returns nil then they are distinct
<Bike>
|3b|: sbcl's manual also doesn't say it ever stack allocates bignums in what looks like an exhaustive list, if you don't mind being mildly sbcl specific
<jasom>
And an object that is distinct from one declared dynamic extent is safe, as is an object that is interned
<|3b|>
ok, so "interned" in your definition includes "constant folding", and doesn't imply it will always be interned?
<jasom>
|3b|: right. If it's constant folded, then it's no longer otherwise unreachable.
<|3b|>
there is no way to access the thing into which it was "interned" in that case, since it happened at compile time
<|3b|>
even if the other use is not accessible after the DX scope?
<jasom>
|3b|: iyup
<solrize>
should this throw an error if i set a non-string key? it seems to let me. (setf ff (make-hash-table :key-type 'simple-base-string :test #'equal))
<jasom>
|3b|: because it's reachable in some manner other than a way declared dynamic-extent
<Bike>
solrize: where did :key-type come from? that's not standard
<jasom>
|3b|: of course if its other use is not accessible after the DX scope, then it can be stack allocated because all uses are determined to be DX (by declaration and by proof)
<|3b|>
so i can file a bug if sbcl both constant folds and flushes a value, and dx allocates another use of the same value?
<|3b|>
jasom: reachable /after leaving the scope of dx/?
<jasom>
I would say (let ((x (some-form-that-gets-constant-folded))) (declare (dynamic-extent x)) (some-form-that-gets-constant-folded)) <-- that must work.
<jasom>
Compare (let ((x (some-form-that-gets-constant-folded))) (declare (dynamic-extent x)) (some-form-that-gets-constant-folded) x) <-- this does not need to wkr.
<|3b|>
but it was "interned" by your definition
<solrize>
Bike, hmm it's in the help message from sbcl
<solrize>
ok i will leave it otu
<solrize>
out
<Bike>
solrize: i just tried (make-hash-table :key-type 'simple-base-string) in my sbcl and got an error that the keyword is unrecognized.
<Bike>
is this new or old or something...
<|3b|>
and right, the first is obviously required, and whether the 2nd is required or not is what i was trying to determine
<Bike>
anyway, it's probably more like a declaration than anything
<Bike>
so if you put in a non-string you'll just get undefined behavior, rather than an error
<solrize>
interesting, maybe different version. ok i should try to follow hyperspec rather than just doing what sbcl says
<solrize>
thanks
<|3b|>
jasom: but it seems like we couldn't find anything in the spec saying whether the 2nd is required or not, so reasonable to assume it is not
<|3b|>
jasom: would you say it is reasonable to expect it to be safe to return (otherwise inaccessible) values from a dx allocated specialized array? (not required to work by spec, but reasonable from a "quality of implementation" perspective and/or "it would be silly to behave otherwise")
<_death>
solrize: you can have a (setf get-the-value) function that checks that the key is STRING before calling (setf gethash)
<solrize>
_death, yeah i don't actually need the runtime checking, i just thought it might happen automatically
<solrize>
is there a simple way to split a string like "foo bar baz" into separate words? i'm trying to do a word frequency exercise
<jasom>
|3b|: I could see an implementation unboxing a small array on the stack if it is declared DX
<jasom>
|3b|: but I think it's currently safe to assume it does not. And it's also going to be safe for an array specialized on an unboxed type, since those will be returned by value
<|3b|>
question is more whether any specialized array could contain boxed values
<_death>
solrize: there is a split-sequence library.. or you can do it yourself with position and subseq
<jasom>
|3b|: there are very few specialized arrays that are guaranteed to exist
<solrize>
_death ok thanks
<|3b|>
(or whether any are silly enough to pass pointers to values inside a specialized array instead of passing it as an immediate or boxing it as needed)
<|3b|>
right, which is why i would consider it silly to add a specialized array type and then store boxed values in that type
<|3b|>
(silly for an implementation to do so)
<|3b|>
so if i dx allocate an array specialized on a type for which u-a-e-t is not T, it would be reasonable (if not required by spec) to assume i can safely return the values in that array from the dx scope
hiroaki has quit [Remote host closed the connection]
* |3b|
is trying to figure out a way to determine which types of arrays are safe to DX allocate for temp variables, without manually whitelisting combinations of types and implementations
hiroaki has joined #lisp
Helmholtz has joined #lisp
<_death>
solrize: there's also sb-unicode:words or library montezuma is your requirements are more complex..
Krystof has quit [Ping timeout: 256 seconds]
<solrize>
_death thanks
Krystof has joined #lisp
shifty has joined #lisp
<|3b|>
hmm, now i wonder if it is possible to "construct" a number with the same value as another that is guaranteed to not be the same object
<|3b|>
if i have an otherwise inaccessible list in a DX container, i can make a copy of it, similarly for gensyms (since it isn't accessible, whoever sees it later can't distinguish the copy from the original)
<|3b|>
but i can't (make-integer some-bignum)
<Bike>
there aren't any operators that guarantee fresh numbers, are there
<|3b|>
right
<Nilby>
You can parse-integer, but even that's not guaranteed not to be the same.
<|3b|>
only thing i can thing of guaranteed to be safe is to return (1+ some-bignum) and then use 1- outside the scope
<|3b|>
*think
<|3b|>
i guess printing to string and then parsing it would also be safe
<Krystof>
brb implementing hash-consing of bignums
<|3b|>
i suppose the other way to make it safe would be to make it otherwise accessible, so if i have a binding outside the DX i can safely store it into that inside the dx?
<Nilby>
But what will this do? (let ((x (1+ most-positive-fixnum))) (1- x))
<Nilby>
or rather with the 1- out of a dx'd let
frgo has quit [Remote host closed the connection]
frgo has joined #lisp
<Nilby>
I think one would like to give the compiler leeway to optimize that
<_death>
Krystof: how about a bignum trie
<|3b|>
ah, i guess storing it in an enclosing variable isn't enough
<|3b|>
that's the same as returning it
shifty has quit [Ping timeout: 264 seconds]
shifty has joined #lisp
contrapunctus has quit [Ping timeout: 240 seconds]
<|3b|>
i guess for my use it is enough to just make sure i never use the initial values in the array, which is probably an acceptable limitation
pranavats has quit [Ping timeout: 240 seconds]
<Nilby>
I'm pretty sure "Universal Lisp" stores at least prime bignums in something like a p-adic tree.
<Nilby>
non-prime that is
DHARMAKAYA has quit [Quit: Turning off a portion of this simulation.]
jonatack_ has quit [Ping timeout: 240 seconds]
shifty has quit [Ping timeout: 264 seconds]
mathrick_ has joined #lisp
aartaka_d has quit [Read error: Connection reset by peer]
mathrick has quit [Read error: Connection reset by peer]
motersen has quit [Ping timeout: 240 seconds]
Helmholtz has quit [Quit: Helmholtz]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
varjag has quit [Ping timeout: 240 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #lisp
aindilis` has joined #lisp
aindilis has quit [Ping timeout: 240 seconds]
anticrisis has joined #lisp
luni has quit [Quit: Connection closed]
aindilis` has quit [Remote host closed the connection]
ebrasca has quit [Remote host closed the connection]