IRC channel logs
2026-02-20.log
back to list of logs
<mwette>dsmith: quit wasting all that bandwidth :) <janneke>hmm, has haunt become stricter? istm that i need to wrap < and > in backticks to avoid an "unknown node" error in node->sxml <janneke>wondering how to use a < without going to verbatim mode? <jab>I think it would be pretty cool if guile had an #lang apl <dthompson>the lesson to learn from racket is that #langs don't compose <dthompson>they're all basically their own little islands. <mwette>Do you have an example of where that was/is a problem? <identity>APL-in-Lisp is better implemented as a macro <dthompson>I just know that I would like to be able to compose languages together in guile <old>there is a good use case for #land <old>#lang* and it's at the begining of the file <old>so that you don't need to rely on file-extension for determining the reader <old>I can have: `blueprint' with `#lang wisp' <old>instead of relying on glob-matching `blueprint.scm` or `blueprint.w` <old>other than that, I don't see why someone would use #lang many time in the same file <old>and I guess it would kind of be trivial to add `#lang` today as a reader hash-extension?/ <mwette>^ a while ago I created a hash-reader-macro for inline expressions <old>But is this a use case? <old>I mean, is there a real case for embedding other language within a Scheme file for example <mwette>dthompson: by composable you mean any language can inline any other language? <old>I think he's refering to cwebber talk on List is Clay at FOSDEM <mwette>I think I understand a bit of it. e.g., prompts are composable, call/cc is not. <ArneBab>old: cwebber showed inlining wisp, so for example you could have script-blocks like enter-three-witches embedded within regular scheme without introducing an optimization barrier. Or maybe even inline plantuml for state machines. <ArneBab>I’m not sure whether that’s the way to go, but it is a usecase. <old>ArneBab: Wisp is probably the only language that can compose well with lisp because it has the same semantic <old>I don't see someone embedding a piece inlined python code in Guile tho <ArneBab>old: yes -- so that may be a contrived example. <old>I don't see the use case * <old>But maybe there is. With Hoot maybe it makes sens to inline some JS? Idk <ArneBab>I personally have no problem with keeping languages separated by files (also because that makes it easy to turn wisp back into regular scheme) <old>So I guess it can make sens to have: #lang:js(some_js_function();) ? <old>right. I think also it's better to seperate language <ArneBab>kind of like in org-mode: src_js{....}? <old>but the principal use case for me with #lang would be to specify the language to use at the top of the file <ArneBab>Or like embedding Javascript and CSS in HTML <old>so you don't need to rely on matching suffix of files for a language <mwette>one use case is SXML in scheme in SXML ... <old>Is SXML a language? Is it not just s-expr? <ArneBab>but that brings a very long tail of dependencies: every tool then has to support multi-language files. <jab>mwette: thanks for the link! <ArneBab>For the editor there’s # -*- scheme -*- -- for the execution there’s exec guile --language=lang -x extension <mwette>funny that before XML there was sgml which used scheme (dsssl) as it's translation language <ArneBab>and matching the language via the extension makes sense, because you have that information already in the directory listing, so you don’t have to look into every file that may have the correct basename. <old>ArneBab: but what we are missing is `loading` <ArneBab>mwette: and XSLT becomes much easier to understand if you think about it as a lisp with very verbose syntax. <old>the current primitive-load-path is kind of broken in that respect <old>I mean that if you have your main program start in Scheme <old>it load a file in Wisp, but that Wisp file load a module in Scheme that in turn load a Wisp file <old>in my experience, this does not work greatly <ArneBab>I use that with import (not with load), but it requires makefile fiddling to ensure that guild compile runs with the correct language for each file. <old>mwette: but it's not in Guile definition. There is no associated reader with SXML AFAIK ? <mwette>the reader is quote or quasiquote <mwette>ArneBab: good way to think of it <mwette>fyi, nyacc has several parsers for languages (e.g., c, matlab, tcl, javascript); the parsers all output sxml as intermediate langages; it's been nice to work that way <ArneBab>mwette: I had the fun task to work on xslt transformations at work ☺ -- not actually fun, but the reason wasn’t the syntax, but that for such an "industry standard" it’s crazy that half the complex tasks don’t work as the documentation claims. <dsmith>I had some fun with xslt some years back. Wasn't bad except for the nasty xml. You can get hurt on all those pointy <'s and >'s. <ieure>XSLT can be okay, it is awfully verbose. <ieure>I had a job in the 2000s that involved taking large quantities of XML content and using XSLT to convert it to XHTML for the web. <ieure>XSLT part was usually okay, the XML I had to convert was always extremely jank. Lots of it wasn't even well-formed enough to parse without manual correction, lots was "HTML with an <?xml?> added at the top," mostly had no schemas at all. Ugly. <dsmith>When I moved from sylpheed to gnus I used xslt to convert the xml address book to bbdb. Was fun. <ieure>Everything in a random undeclared character set, sometimes multiple encodings in the same document, HTML entities used in XML documents, etc etc. <dsmith>ieure, I hope you are fully recovered from the trauma <ArneBab>ieure: yikes! Compared to that my work was childs play ☺ <ieure>ArneBab, I've had some tough jobs, my first was filling in at my grandfather's one-man janitorial service company. Waking up at 3:00am to clean the bathrooms in a small town bar, or mop the floor of the K-Mart a few towns over. <ieure>Computer stuff is very easy in comparison.