IRC channel logs


back to list of logs

<robin>drakonis, very interesting! some of these features sound quite hard to implement in strict ansi cl...
<drakonis>but it doesnt need to be strict ansi cl, does it?
<drakonis>vernacular seems to be pretty light on dependencies
<drakonis>besides overlord's dependencies
<robin>or in close-to-ansi-cl :) looks like an impressive effort either way
<drakonis>i'll admit that i like cl's libraries
<drakonis>there isnt a shortage of libraries for every paradigm
<robin>cl is probably my favorite lisp dialect (considering just the language and not implementations), though it's certainly imperfect in various ways. i'd like to see cl support in guile someday, although usable cross-language interaction would be tricky ofc
<drakonis>the most interesting thing about cl will always be that ansi cl is effectively complete and you have a wide range of libraries that paper over anything missing
<drakonis>its all ~complete~
<drakonis>its so weird when coming off other languages that run in the perpetual treadmill of maintaining code
<lilyp>That seems awfully similar to the completeness of Scheme.
<lilyp>Just ignore how there's still SRFIs adding stuff :P
<drakonis>i mean
<drakonis>the srfis establish portability across implementations, yeah?
<drakonis>portable interfaces
<drakonis>the libraries all generally work across implementations
<drakonis>unless you need to use something that's non portable
<lilyp>Well, there's the RnRS which are portable*
<lilyp>and then there's the SRFIs, which are portable**
<drakonis>the heavy lifting has to be done beforehand
<drakonis>its not so much "write once run (almost) everywhere"
<drakonis>targeting the rnrs and srfis requires a subset of code
<drakonis>but this isn't even an argument in favour of either approaches
<drakonis>either approach
<lilyp>Well, given that we have cond-expand, it's more like C's "write once, #ifdef the rest"
<drakonis>if i recall correctly, cl's srfi equivalent seems to be seeing a revival of sorts.
<drakonis>that also exists in cl i suppose
<drakonis>features i think?
<lilyp>yeah, I don't think you can consider a language complete without a committee approving of changes
<lilyp>There was a talk in cppcon "We are finally up to Bjarne's spec from 30 years ago. Now let's add pattern matching."
<drakonis>that's something lol
<drakonis>oof on the amount of ways to read args with just ansi cl
<drakonis>per implementation
<robin>drakonis, would that be CDR (which seemed sort of like 'SRFI for CL') or some other project? i remember when CDR was started but it didn't seem to have much activity early on
<robin>neat, i'll have to check it out again
<drakonis>there was an email sent out addressing cl folks about restarting it
<drakonis>as well as getting in contact with existing cdr authors to publish the existing CDRs on zenodo
<drakonis>it will be certainly quite interesting to watch it
<drakonis>but enough gushing about cl, its already offtopic as it can be
<robin>definitely. i'm curious to see whether they'll be primarily cleaning up ANSI CL (known bugs, underspecified things, etc.) and maybe standardizing a few widely-used extensions, or adding new functionality a la SRFIs. or both!
<drakonis>being able to improve the language without needing someone foot the bill is always good
<drakonis>the first one was CLOS and MOP
<drakonis>so neat.
<Wezl>with (oop goops), is it possible to define-method where one of the parameters could be of several classes?
<Wezl>e.g. I want to be able to do (define-method (foo (arg <classA> <classB)) bar) instead of (define-method (foo (arg <classA>)) bar) and then repeat that for classB, but I don't think I can make <classA> and <classB> both subclasses of another class
<Wezl>I can see why I wouldn't be able to though
<lilyp>Wezl: you could define the generic case for foo as a match-lambda which does the OOP checks, but other than having a function %foo and handing (foo (arg <A>)) and (foo (arg <B>)) off to it, I don't think it'd work
<lilyp>i.e. there's no templates as in C++ and you'd have to translate interfaces and concepts to class types
<tohoyn>what do you think about this:
<robin>tohoyn, thanks for pointing that out! (others are better-qualified than me to actually fix it, but i'm unfamiliar with the guile 3 vm though not vms in general, so trying to reproduce and analyze in qemu or so could be a good learning experience...)
<robin>my first thought is that perhaps it's a bug in gnu light(e)ning or guile's usage of it, given that it's doesn't seem to be all that widely used, but that could be totally wrong (idk if it even supports those platforms)
<tohoyn>I have fixed the cumulative time measuring in statprof.scm. Do you want to integrate this in guile upstream?
<dsmith-work>Hey Hi Howdy, Guilers
<robin>buenos días, dsmith-work
<robin>the language tower talk from earlier reminds me that i should really at least skim smith's 3-lisp research, or at least herzeel et al.'s less abtruse exploration of similar ideas
<robin>i "scanned" a 3-lisp book with a phone camera *ages* ago at a local uni library, but lacked the background at the time to really dig into it
<dsmith-work>A 3-lisp? What's the extra bit?
<dsmith-work>Or is that just a name?
<lilyp>a lisp-3 is where a variable can be a variable, a function or a variable function :P
<lilyp>s/variable/symbol on the first occurence
<jpoiret>shouldn't guile's exec procedures also disable automatic finalization?
<jpoiret>otherwise, we get the (revered) "Error in finalization thread: Success"
<jpoiret>with pthread support on
<civodul>jpoiret: i'm surprised we still get that one, i thought i fixed it twice already!
<civodul>first by getting the right errno value (instead of Success), and then something else i forgot
<jpoiret>but there shouldn't be an errno, right? since the read succeeds, just that it couldn't read a byte because the pipe was closed
<jpoiret>we could separate it into a data.n == 0 and data.n < 0, with the first case cleanly exiting the thread
<tohoyn>are there any plans to backport guile 3.0.7 to debian stable (bullseye)?
<civodul>jpoiret: FWIW i was referring to 1fbe89f7bdbf35408ec2df8de755c2f1323016a6 (i thought there was another one, but maybe not?)
<civodul>tohoyn: that'd be a question for rlb, who maintains the Guile packages in Debian
<jpoiret>oh, right, but here there's actually no error, `read` can return 0 bytes without erroring (ie if the pipe closes)
<jpoiret>which is what happens on exec
<jpoiret>or, rather, on mass fd-closing before exec i'd say
<civodul>oh right, got it
<civodul>but the finalization thread is supposed to be closed before exec'ing
<wingo>lol somehow i was on wingo_ which was quieted in this channel
<wingo>have been typing things in here for days
<wingo>but it didn't make it out
<wingo>hoist by my own petard, or so
<wingo>anyway happy new year everybody :)
<jpoiret>civodul: well, i don't see how it would happen by reading the execlp source, but I don't understand how the GC works so I'm not sure
<robin>dsmith-work, just a name iirc, might have a deeper meaning but it's unrelated to lisp-1 vs. lisp-2, i believe
<lloda>oof hny wingo
<dsmith-work>robin: Ahh, ok. Thanks.
<robin>dsmith-work, actually, from a paper it appears that 1-lisp = 'regular lisp' (not explicitly defined), 2-lisp = 'a semantically rationalised dialect', 3-lisp = a procedurally reflective lisp based on 2-lisp, supporting an arbitrarily 'tall' interpreter tower (or maybe more of an interpreter tree)
<robin>i think herzeel et al.'s work ("reflection for the masses" iirc, maybe other papers) is more or less 3-lisp's ideas reformulated with modern terminology and technology, so probably a better starting point for whatever smith was getting at
<civodul>hey wingo, happy new year and all!
<civodul>i've noticed that when i'm under "civodul`" i'm quieted too, never understood why
<civodul>jpoiret: in libguile we'd call scm_i_finalizer_pre_fork & co. before calling fork+exec
<civodul>that's for the case where users call open-pipe & co.
<robin>feliĉan novan jaron! 🎉
<civodul>hey robin :-)
<robin>hi civodul!
<robin>or in a more universally understood language: (make <gnu-year> #:happy? #t) ;)
<dsmith-work>civodul: I think you need to register civodul` with the nickserv or whatever
<drakonis>you can group up nicknames iirc
<wingo>funny things i have found over the past few days
<wingo>(* 1 'foo) => 'foo
<wingo>(< +nan.0) → #t
<civodul>wait, is that... a JavaScript dialect?
<wingo>(ash 1 -100) → 0
<wingo>(ash 1 -100.5) → 0
<wingo>(integer-expt 'foo 0) → 1
<civodul>woow, does it have to do with generics?
<wingo>(integer-expt 0 -1) → +nan.0 (a v strange choice)
<wingo>civodul: sorta?
<wingo>dunno if you recall around 10 years ago or so mhw was working on different number types
<wingo>using goops of course. an outcome of that was that some identities should hold for any type
<wingo>(some things like the ash thing are just bugs of course)
<civodul>hmm i see
<wingo>regarding the 3.0.8 question. i feel good about it, open question are just the inlining issue, and that i would like to land something that removes the need to set gmp allocators and removes the need for finalizers
<wingo>is inline digit allocation for bignums. abi-compatible, and will get better when we can break abi (3.2)
<wingo>a couple days away from being able to do that
<jpoiret>if 3.0.8 is in the works i'd like to address as well
<civodul>wingo: removing finalizers for bignums would be great
<lilyp>jpoiret: I see your patch from december and raise mine from march:
<lilyp>bonus points for deadnaming myself
<lloda>i thought i had fixed a couple ash bugs, but maybe i added more :-\
<lilyp>It's never too late to introduce a new one :)
<lloda>i mean (ash 1 -1) gives 0...
<lloda>not even 100
<lilyp>well, if you shift 1 by one bit to the right...
<lloda>you're right, it's defined as floor(...)
<lloda>iirc one of the bugs was with gmp, you have to be conservative with the range bc gmp may abort if the values are too large and there's no way to check in advance what the valid ranges are
<lilyp>lloda, wait you meant too generate a divide by two for real values with that?
<robin>lloda, yeah, that's a general problem with the high-level gmp api, the low-level api doesn't have that problem tho, afaik (although it's less convenient to use, ofc)
<lloda>lilyp: not really i think i just misunderstood wingo's example
<lloda>robin: i c
<wingo>robin: yeah. so the thing i am doing is basically representing a bignum as struct { scm_t_bits tag; mpz_t z; mp_limb_t digits[] } and wiring the mpz_t to point to the inline digits
<wingo>we need the mpz_t there to preserve abi b/c currently the situation is struct { scm_t_bits tag; mpz_t z } as you know
<wingo>in 3.2 we can simplify to just store number of limbs and not have a limbs pointer there
<wingo>but, one funny thing with this strategy is that you can make a mpz_srcptr (a const mpz_t) alias the inline digits in a bignum
<wingo>so you can use the mpz_t api on these values. or rather you can use them as source operands
<wingo>and incrementally we can switch to using the mpn api instead as and when we find it useful
<wingo>but every switch from mpz to mpn is a chance to introduce bugs so i am trying to do more of a refactor than a rewrite currently
<wingo>and for functions for which a switch to mpn wouldn't gain us any performance, it's nice to be able to keep using the mpz api
<wingo>lilyp: lloda: (ash 1 -100) is obviously zero, for guile's definition of ash. but that you can pass -100.5 is a bug
<dsmith-work>What? No half-bit shifts?
<lilyp>that breaks my quantum computing setup
<lilyp>wingo, lloda: for the sake of fixing it, any real value smaller than 1 works
<lilyp>It appears there's an optimization going on where Guile already knows it doesn't make sense to shift 0 by anything
<wingo>yeah. have it fixed in a branch i think
<robin>wingo, sounds like a reasonable strategy, and a good hack for abi compat :)