IRC channel logs
2021-11-21.log
back to list of logs
<robin>KE0VVT, well, i don't know much about the gnome hig, but i'm the main author of guile-emacs, yes <wkmanire>robin: Is guile-emacs the emacs port to guile? <KE0VVT>robin: How is it working so far? <KE0VVT>robin: I see it can read Emacs Lisp. <KE0VVT>drakonis: There is still a "guilemacs" package in Guix. <robin>KE0VVT, it's entirely compatible (modulo the occasional bug) with a now-old version of emacs, although noticeably slow as correctness was the first goal <robin>the guile-emacs package is actually broken right now (freezes during a certain build step, generating some i18n data iirc), but definitely worked in the past, so i'll need to figure out what changed <robin>iirc the performance problems mostly boil down to not implementing enough of elisp in pure guile/guile-elisp (and using FFI, etc. to maintain full emacs compatibility). buffer-local variables are fairly tricky, for example, and aren't implemented directly in guile-elisp yet (although i have a mostly complete separate implementation) <robin>drakonis, sort of, yes! gregg sangster rebased the guile-elisp branch onto guile 3 (which had a few dozen patches on top of guile 2.x) <robin>the next step is to rebase the guile-emacs repo; it's currently based on emacs 24.x which is ~5 years old <drakonis>how viable is it to merge it into upstream emacs? <robin>drakonis, it'll require significant performance improvements for that to be viable for everday use, and probably both excellent performance and new language features to be at all politically viable imo (since it's such a substantial change to emacs itself) -- fortunately guile should be able to provide both in the long run :) <robin>(i'd guess something like a year of full-time work to make it a viable drop-in emacs replacement, give or take a few months -- the point where users shouldn't realize there's a difference, other than hopefully being a bit faster, unless they type M-: (featurep 'guile-emacs) RET :)) <robin>and it should be interesting to see how guile's compiler compares to the emacs native-comp branch (which uses libgccjit) once the basic performance problems specific to guile-elisp are fixed <robin>i'll be busy with c# and cl hacking for at least a couple months, but if the stars align wrt timing and funding, it might well be done sometime in 2022 <robin>after that comes the fun part, hopefully: closer guile/emacs integration and modernizing emacs and elisp concurrently (expanding elisp's numeric tower, for instance, or improving threading support) <apteryx>if guile comes to emacs (which I hope it will!), I hope the guile debugging experience will be greatly improved; as currently it pales in comparison to what edebug can do <robin>apteryx, edebug unfortunately wouldn't be much help with scheme code, iirc it basically has its own elisp evaluator :/ but there are definitely possibilites for a lispm-esque scheme development environment, especially if emacs can be 'lispified' thoroughly enough <apteryx>right; I meant it in the way that in order to compete with Elisp (viable politically), Guile would need to refine its debugging experience by a lot <apteryx>Although I understand guile-emacs is not about replacing elisp with guile (yet) <apteryx>but it'd at least provide the incentive to author new Emacs packages in Guile, if the core was Guile :-) <apteryx>as it'd support it natively, and Scheme is more powerful/cleaner than Elisp. <robin>apteryx, i'd also like to see elisp become more powerful and cleaner than elisp ;) something closer to CL, maybe, which is in line with elisp changes over the last few years. it'd definitely be interesting to provide decent multilingual interoperability for scheme and elisp and see what happens <robin>(i'll have to dig into symbolics manuals and see how they handled their polyglot environment; i might be misremembering but i think one could switch dialects within an expression, something like (/ FUTURE-COMMON-LISP:::(* 11 2) SCHEME:::7). seems like a sane approach for members of the same basic PL family; i wonder what they did with prolog, c, fortran, etc.) <drakonis>if i'm getting pinged the instant you join, then there's something going on! <ArneBab>re "ah, scheme has finally clicked for me <ArneBab>how did it click for you? Do you know what caused it? Can we replicate it for others? :-) <drakonis>i was trying to implement a cipher algorithm on the weekend and was having some trouble figuring out how to generate a circular list because i kept passing a list to the procedure <drakonis>so it made a circular list containing a list <drakonis>i used apply instead and it generated the list using the contents of the list <drakonis>the secret here is giving people some exercises to implement with their scheme of choice <drakonis>its not always about reading how great lisps are, its about how to teach them ways they can solve problems better <drakonis>what might be missing here is a book that covers up scheme with r7rs-large changes <drakonis>basically, i referred to srfis, gauche and guile docs <drakonis>guile's good but gauche's better organized <drakonis>its generally similar to racket's documentation <ArneBab>Are there low-hanging fruits to improve Guile’s docs to get closer? <lilyp>"oh yeah, read this paper by wingo, it totes makes sense" <lilyp>And I've used sxml-fold before <drakonis>let me see if i can find the words for it <drakonis>its less so the docs and more the approach gauche has taken for some things <drakonis>gauche supports lots of srfis and builds on top of these <drakonis>the documentation indicates where its own extensions do that <drakonis>hm, this is giving me an idea on how to solve a specific problem <drakonis>it provides a measure of guidance on which libraries you can use to actually do something <drakonis>instead of having to peruse which srfi or ice-9 module you need <ArneBab>That’s pretty cool — more focussed on helping in use-cases than explaining what’s there <ArneBab>drakonis: that looks interesting — like something I’d wished to have in Guile with GOOPS <drakonis>gauche also has its own oop equivalent, lovingly stolen from common lisp