<wleslie>oh oasis is not a language, actually that channel is dead <zacts>isn't that what coyotos used? <wleslie>it was originally created for coyotos, but coyotos was written in C anyway <amz3>héllo nalaginrut and everybody <amz3>I've looked around to implement a markdown parser in guile, I think the quickest safest thing to do is to bind the original markdown parser shipped with debian <amz3>I tried parser combinators, but this requires more time to get right <amz3>anyway, we can't improve that later ***michel_mno_afk is now known as michel_mno
<amz3>or we can use the outline mode of skribillo <amz3>there is not much text right now (except the manual) so I will go with what haunt provides and see next ***michel_mno is now known as michel_mno_afk
<zacts>^ perhaps you could reference this one from racket? <zacts>but it's a BSD license and not GPL <ArneBab_>most BSDs (2-clause and 3-clause) are GPL-compatible ***michel_mno_afk is now known as michel_mno
<davexunit>"The Promise of Relational Programming" with William Byrd ***dsmith-w` is now known as dsmith-work
<davexunit>I'm not going to do it. YAML is too terrible. <paron_remote>davexunit: because sexps scare people and json doesn't allow comments and it's better than .ini files and less work than proper xml? :) <taylanub>why isn't there an amendment to the JSON spec for comments yet? that would solve a big part of the issue... <paron_remote>taylanub: every time I say this people say BUT JSON IS FOR DATA <davexunit>what I've learned is that people are hostile towards "code is data, data is code" <wleslie>"comment" : "this object smells like garlic", <wleslie>if you're really duck typing, that will pass by in many places unnoticed. <davexunit>and that's how we end up with jinja2 YAML templates in Ansible. <paron_remote>davexunit: to be fair, I understand that when serializing state (as opposed to config), you might not want the state stuff to be serialized in a turing complete language, or things with reader macros, etc <paron_remote>so having a subset of scheme that's data-only, it makes sense <dsmith-work>wleslie: Such a sad thing that dsssl went away. xslt is ugly <daviid>mark_weaver: are you a member of the g-wrap-dev mailing list ? <mark_weaver>I don't have time to look at this right now, but I'll try to do so later. <daviid>sure, just wanted to let you know. i should also inform civodul, or maybe you can? <mark_weaver>yes, civodul is the one who changed guile to use bdwgc, so he's the relevant expert on this issue. <daviid>mark_weaver: ok, i see yu've been involved quite a lot in the thread dak refrs to, so ... but now civodul [who i don't know if he's following g-wrap either] will be informed. i was a bit reluctant to foward his mal to guile-devel ... ***michel_mno is now known as michel_mno_afk
***cluck_ is now known as cluck
<davexunit>paron_remote: figure we should continue talking about parsing org-mode with guile here. <davexunit>wingo wrote something that parses a subset of org-mode awhile ago, and I hear that Skribilo has an outline-mode style parser, so we've got something to work with. <davexunit>time to reiterate my desire for parser combinators. I should just upload the thing I hacked together and have people tell me what's wrong with it. :) <amz3>I'm trying to figure guile-log parser combinators, the api is nice. For instance, you don't have to manage line/column (for debug), it's done by the library <amz3>the markdown parser proposed earlier use combinators <dsmith-work>org-mode is wonderful, but I've heard that it's really nasty to parse. <amz3>it explains how to code the grammar/parser <davexunit>I'll have to upload my simple parser combinator library. <amz3>I yes, I'm interested, so far what I've read about it is pretty simplisitic in terms of implementation <amz3>seems like a powerful thing that can be expressed simply (with naive implementation) <davexunit>there's some really hard stuff to implement to handle certain types of grammars <davexunit>I wonder how terribly mine performs since I use srfi-41 streams <amz3>compared to raw parsing it easier to implement, it's just a feeling <davexunit>I use port->stream when parsing from a port to remove any logic having to deal with backtracking in a file <amz3>I lost my sens a long time ago ; ) <amz3>amz3 | I lost my sens a long time ago ; ) >> especially regarding parsing LL thing and stuff was the most difficult course I've done <davexunit>well, I *do* backtrack, but it doesn't require rewinding the port that's being read from <davexunit>I just turn the port into a lazy stream of characters <amz3>I did not know it was possible to backtrack streams <amz3>it's a list that read lazily with a cache, that's it? <davexunit>backtracking is simply holding onto the stream-cons cell that you want to backup to <amz3>I did not see the intereset of that the "memoization" feature of streams <davexunit>streams allow to you represent infinite series in an elegant way, too. <amz3>I'm used to generators, which forget about past values (by default) <davexunit>(stream-cons 0 (stream-cons 1 (stream-map + fib (stream-cdr fib)))) <davexunit>well, you can only calculate so many before your system runs out of ram. <davexunit>but of course values no longer referenced can be GC'd <amz3>I think it's called lazy-seq in clojure <amz3>(define multiples-of-three <amz3> (values n (next (+ n 3)))))) <amz3>the above construct to create infinte lists without memoization <davexunit>amz3: that's caching values, too, a.k.a memoization <amz3>multiple-of-three doesn't cache values <amz3>In python, I like to use it to simplify complex loops <amz3>loops where components must be computed every iteration, like enumerate but more advanced <mark_weaver>davexunit: amz3 is correct, 'multiples-of-three' doesn't do memoization <mark_weaver>amz3: fwiw, if you don't hold a reference to the head of a stream, then the earlier elements can be freed. <davexunit>okay so it doesn't hold onto the computed values <mark_weaver>but it will be recomputed every time. there is no memoization. <amz3>but I did no manage to run it <amz3>even guile-log I had to ask stis for help <amz3>I think he fixed the issue with guile log <amz3>mark_weaver: multiple-of-three construct is meant to be simpler than streams to manipulate (avoid streams-cons and friends) <mark_weaver>amz3: on the other hand, there is a major advantage to standardizing on one stream type, so that all code that produces/consumes streams can interoperate <mark_weaver>it's not obvious to me that your way is simpler, but if it is, it is only marginally so. the interoperability issue is far more important, IMO.