IRC channel logs
2015-10-09.log
back to list of logs
<paroneayea>especially applicable to lispers, who make little to no distinction between data and code :) <mark_weaver>paroneayea, ArneBab: that's great news. thanks for working on it! :) <daviid>mark_weaver: fi, just sent an email to devel wrt guile-gnome gcc 5.2 make check fails... <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. <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.” <csed>jchmrt: Cheers for the link, I'll take a look. <amz3>it's the scheme version of file descriptor <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>IIRC unknown_lamer worked on a recent scsh port to Guile quite recently <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>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>I tried contacting the guile port's author but no response.. <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>wow, symbolic links aren't in posix, I never knew! <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>(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>then the title should be a plain string, too <davexunit>is there no form for a string that isn't in a list? <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>it doesn support recursive parser like (define enclosed (parser-each parser (parse-one-or-more parse-any-char) parser))) <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 <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 <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>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>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 <amz3>there is middle ground between logic programming and parser combinators, logic programming can think over arbirary data, this is only 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 <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 <davexunit>seems that 'enclosed' can be implemented in terms of parse-char-set <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>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>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>scheme@(guile-user)> (define res (split-at '(1 2 3) 2)) <nilg>scheme@(guile-user)> res <nilg>(sorry for pasting guile shell here, any better place?) <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>nilg: one such way is via 'call-with-values' <davexunit>(call-with-values (lambda () (values 1 2 3)) list) <nilg>awesome thanks! (years of scheme, not knowing that LOL) <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)