IRC channel logs


back to list of logs

<paroneayea> was my contribution to that
<ArneBab>that article was great!
<paroneayea>especially applicable to lispers, who make little to no distinction between data and code :)
<ArneBab>yes :)
<ArneBab>I provided some of the raw use cases:
<mark_weaver>paroneayea, ArneBab: that's great news. thanks for working on it! :)
<ArneBab>I posted my article on that to Hacker News :)
<daviid>mark_weaver: fi, just sent an email to devel wrt guile-gnome gcc 5.2 make check fails...
<nalaginrut>morning guilers~
<paroneayea>hi nalaginrut
<rekado>yesterday I checked out the guile-scsh code from CVS, as I think I could spend some time to make it work with the latest version of Guile.
<rekado>I wonder what the best approach to modernising the code is.
<rekado>how can the commit history be imported to git?
<rekado>should it be its own separate library, developed outside of the guile tree or should it be on a branch of guile?
<rekado>when looking at the code I also see that it's based on the upstream sources targeting Scheme48; I wonder how close to the upstream sources this is supposed to stay.
<rekado>should the code only be minimally modified to make it work? Should it stay compatible with upstream to make future updates easier?
<rekado>or is the amount of bit rot sufficient reason to permit wider changes, as long as it all works?
<rekado>I wondered the same about the SXML sources --- much of the work is done in the upstream sources which are minimally modified and imported by a layer of guile-specific code, seemingly to avoid altering Olegs original work.
<rekado>is this necessary?
<civodul>Hello Guilers!
<wleslie>happy Friday civodul!
<civodul>yeah, happy Friday wleslie :-)
<csed>So in
<csed>It talks about ports. What uh, what does that mean? Are we talking about actual networking ports?
<jchmrt>csed: The formal definition of a port is very generic: an input port is simply “an object which can deliver characters on demand,” and an output port is “an object which can accept characters.”
<jchmrt>csed: copied from:
<csed>jchmrt: Cheers for the link, I'll take a look.
<amz3>it's the scheme version of file descriptor
<csed>amz3: Ah, alright.
<amz3>basicaly ;)
<amz3>things can be interfaced via "port" it's not limited to networking and files
<rekado>I guess I'll better send my questions re scsh to the mailing list.
<civodul>rekado: guile-scsh?
<civodul>IIRC unknown_lamer worked on a recent scsh port to Guile quite recently
<rekado>oh, I didn't know.
<rekado>I downloaded guile-scsh from CVS yesterday.
<rekado>wanted to make it work with a later version of Guile, but if there's a newer port this may not be necessary anymore.
<paroneayea>rekado: redoing a scsh port may be needed
<rekado>is it because of licensing?
<paroneayea>since some of the guile-scsh files have a needlessly added "typical gpl notice, including not for commercial use"
<rekado>I think I read something like that earlier here.
<paroneayea>or something
<paroneayea>it's not present in the original scsh
<paroneayea>just the guile port
<rekado>oh, the one from CVS?
<paroneayea>I tried contacting the guile port's author but no response..
<paroneayea>rekado: I think so yes
<rekado>that's just sad.
<paroneayea>I'd like to have scsh in guile though
<paroneayea>it seems like cool softwrae
<paroneayea>and it would be great to combine scsh with g-expressions.... now that would be interesting ;)
<rekado>unknown_lamer: are you still working on porting scsh to Guile?
<paroneayea>ACTION opens the scsh manual
<paroneayea>wow, symbolic links aren't in posix, I never knew!
<civodul>rekado: did you try this one?
<rekado>no, I haven't tried it. The Guile manual only mentioned the CVS source.
<davexunit>rekado: I almost have a skribe reader integrated into haunt core.
<rekado>nice! I'm looking forward to replacing my leaky ad-hoc plumbing with your code ;)
<davexunit>I just need to make a procedure to account for metadata
<davexunit>I'll probably make a <skribe-document> type for this
<davexunit>(document '((tags . (foo bar baz))) (h1 [hey rekado]) (p [this is a skribe doc]))
<rekado>yes, that would be good. It's very ugly to have a separate global definition of metadata as it is done for my blog right now.
<davexunit>yeah I'm trying to come up with a syntax that works well with Skribe
<davexunit>quoted alists aren't so nice
<davexunit>maybe a procedure with keyword args
<davexunit>(metadata #:title [Getting started with GNU Guix] #:tags (list [foo] [bar]))
<civodul>davexunit: [foo] is short for '("foo")
<civodul>for tags you probably want plain strings
<davexunit>good point
<davexunit>still learning this Skribe thing :)
<davexunit>then the title should be a plain string, too
<davexunit>is there no form for a string that isn't in a list?
<davexunit>doesn't seem so
<davexunit>amz3: I'm trying to parse (no pun intended) your email about parser combinators, but I'm afraid it's hard for me to understand.
<davexunit>what I gathered was that you want to negate a parser.
<amz3>what I say, is that markdown parser AFAIK can not be implemented using only the procedure that are in parser-combinator
<amz3>among other things...
<davexunit>I am not sure that's true.
<amz3>it doesn support recursive parser like (define enclosed (parser-each parser (parse-one-or-more parse-any-char) parser)))
<amz3>without that ^
<davexunit>why would you expect (parse-one-or-more parse-any-char) to do anything but consume the whole stream?
<amz3>or parser-not, parser-and, parser-or I can't do it i you prefer
<davexunit>parse-each is equivalent to AND
<amz3>parse-each consume the input stream, parse-and doesn't
<amz3>only one parser consume the stream in parser-and, whereas parser-each every parser consume the input stream one after the other
<amz3>because of this strange semantic (only one parser consume) I did not implement and IIRC but parser-if instead
<amz3>which is what guile log does
<amz3>yes, I expect that the parser find the correct parser combination that makes it work
<davexunit>that definition of parse-and does not make sense to me
<davexunit>that's an OR
<davexunit>not an AND
<davexunit>which is what parse-any does
<amz3>let's forget parser-and
<amz3>((parser-if parser-aaa parser-bbb) stream) succeed, if (parser-aaa stream) succeed, and reutnr the result of (parser-bbb stream)
<amz3>anyway, this is a hack i guess
<amz3>I think, (parser-one-or-more a) should be equivalent to (parse-alt (parser-each a a a a a ... n times) (parser-each a a a ... n-1 times) ... (parser-each a a a)) where n is the size of the stream
<amz3>this would make writing parser-enclosed much more neat imo, but I meay be wrong
<amz3>actualy it's possible to easily backtrack on failure in parser-each LML
<amz3>well i'm confused
<amz3>I should have written parse-one-or-more instead of parser-each
<amz3>which indeed does what it should, that's not where the backtracking should happen
<amz3>IMO the following should be valid ->
<amz3>otherwise, it break the declarative paradigm, it too difficult to declare the grammar in terms of "don't", instead it should constrained by "dos" which is the case of this snippet
<amz3>there is an interpretation of the code which leads to the correct answer, but I don't know how to translate it into an implementation
<amz3>I'm saying for you to do it
<davexunit>that may be valid for a logic programming language
<davexunit>but this API isn't logic programming
<davexunit>so it cannot be done this way.
<amz3>there is middle ground between logic programming and parser combinators, logic programming can think over arbirary data, this is only streams
<amz3>finite streams
<davexunit>making that code work introduces huge complexity
<amz3>i think that's what the trampoline does, in GLL, each time something is parsed, it adds a partial solution to "a todo list" and if a the current solution fails, it pop something from the todo list
<davexunit>in that now there may be more than 1 way to parse something
<davexunit>so just use guile-log
<amz3>that's a generic version of Earley parser or something with tabled solutions
<davexunit>I do not want to deal with a grammar in which there is more than 1 way to parse something
<amz3>well, I need anyway
<davexunit>seems that 'enclosed' can be implemented in terms of parse-char-set
<davexunit>well, in the simple case anyway
<amz3>guile-log *parse* doesn't support that feature out-of-the-box IIRC, because stis gave me the solution of the enclosed and it wasn't recursive
<amz3>it use f-not and f-if
<amz3>that's where come from those parsers
<amz3>now I understand better the interest of the trampoline or whatever does GLL
<davexunit>that's for left-recursive grammars specifically
<amz3>or maybe I will use minikanren do to that :D
<amz3>the website is up again
<amz3>so I could buy the book, but... I'm working small layer on top wiredtiger to make it a little simpler
<amz3>Earley parser is used to parser ambigious grammar so everything makes sens
<nilg>guys, this one is driving me crazy:
<nilg>scheme@(guile-user)> (split-at '(1 2 3) 2)
<nilg>$7 = (1 2)
<nilg>$8 = (3)
<nilg>scheme@(guile-user)> (define res (split-at '(1 2 3) 2))
<nilg>scheme@(guile-user)> res
<nilg>$9 = (1 2)
<nilg>(sorry for pasting guile shell here, any better place?)
<davexunit>nilg: split-at returns 2 values
<davexunit>what did you expect (define res (split-at '(1 2 3) 2)) to do?
<nilg>I didn't know a scheme function could return multiple values...
<nilg>how do I collect them all?
<davexunit>try yourself: (values 1 2 3)
<davexunit>nilg: one such way is via 'call-with-values'
<davexunit>(call-with-values (lambda () (values 1 2 3)) list)
<davexunit>=> (1 2 3)
<nilg>awesome thanks! (years of scheme, not knowing that LOL)
<sirgazil>nilg: More info at
<please_help>srfi-8 receive (I think it's ice-9 receive in guile) is cleaner I think.
<taylan>I also frequently use let-values. receive is the "one pair of variable-list and expression" special-case of let-values: (let-values ((vars expr)) body) = (receive vars expr body)