<paroneayea>mark_weaver: is it just that the guile 2.2 tests are currently failing? <mark_weaver>paroneayea: well, bipt just said that he pushed a fix and that "make check" should now work, so forget what I said :) <lamefun>Is Guile/Scheme still worth to use or it's been obsoleted by Haskell? <mark_weaver>That's a strange question to ask a channel where Guile/Scheme users hang out. <lamefun>Well, if I posted this on #haskell they'd surely 99% say yes. <mark_weaver>FWIW, I like Haskell a lot, but it's not clear to me that it's the right approach for every program. <mark_weaver>for example, for interactive systems like Emacs or a computer algebra system, where you want to be able to interactively mutate your environment, languages like Lisp and Scheme are more appropriate, IMO <mark_weaver>but it should be extensible. you should be able to add new types of expressions <mark_weaver>but haskell's static typing does not make this natural <mark_weaver>for an interactive system, you want to be able to extend the existing operators to support new types as you add them. <mark_weaver>more generally, although I try to keep it to a minimummutable state is sometimes appropriate in my opinion, <mark_weaver>more generally, I although I try to minimize my use of mutable state, and prefer to write in a mostly purely-functional style, <mark_weaver>I believe that there are some cases where mutable state is appropriate, because the alternatives are worse. <mark_weaver>paroneayea: I suggest that you just disable tests for now, so that you can make progress on guile-emacs <lamefun>That can be read by anything capable of reading Scheme format to generate in-game guides, etc. <lamefun>Or update game wiki pages and generate .po files. <mark_weaver>the other thing I'll say about Scheme is that it is not tied to any particular programming style, but rather gives you the tools to write your program in a style of your choosing <mark_weaver>Scheme allows almost everything to be in libraries, because the base is so flexible and generic <mark_weaver>In the Haskell world, changes to the language are very frequently desired, e.g. due to limitations in the type system that are uncovered by some program <mark_weaver>I think that both approaches are extremely valuable. <zacts>mark_weaver: what are your feelings about dynamic versus static typing? <lamefun>Also I'm under the impression that everyone thinks that languages with changeable variables languages like Scheme or C are going to die because they can't possibly exploit all the abilities of super-parallel quantum/graphene/memristor/etc. computers of the future. <mark_weaver>I'm sorry, I have to go afk for a while. happy hacking! <zacts>ah, ok. catch you laters man! :-) <bipt>paroneayea, works for me...you could run tests in $(git merge-base master wip) to see if it's my fault <bipt>or in master probably (wip is a little over a month out of sync) ***karswell` is now known as karswell
<paroneayea>bipt: ok interesting, I'll see how master works out with it and this package in a few <paroneayea>bipt: I disabled tests in this run, gonna see if it can build emacs successfully, ignoring the popen thing :) <paroneayea>so I disabled make check, now hitting this error <paroneayea>Loading /tmp/nix-build-guile-emacs-20150209.8f2e203.drv-3/source/lisp/emacs-lisp/lisp-mode.el (source)... <paroneayea>Scheme error: unbound-variable, (#<scheme module-lookup> #<scheme Unbound variable: ~S> (regexp-opt) #<scheme #f>) <paroneayea>Makefile:91: recipe for target '../../source/leim/../lisp/leim/quail/TONEPY.el' failed <ArneBab>bipt: corner-case: Some settings in emacs init.el fail when init.el is compiled. <ArneBab>bipt: how can I pre-compile elisp with guile? <arne>Hello from guile-emacs M-x irc! <arne>Guile Emacs took a few minutes to start, but it works! <civodul>wingo: what do you think of announcing ijp's GSoC on sv.gnu.org? <wingo>i can do that tomorrow or so <zacts>oh is ijp really going to do that guile --> JS compiler, or whatever it was? <nalaginrut>wingo: oh, it seems that something is wrong in 2.1, not in 2.0, I have to change my code <nalaginrut>wingo: can you run it in 2.1 and 2.0 ? (define-syntax define-art (lambda (x) (syntax-case x () ((_ name) (identifier? #'name) #`(begin <nalaginrut>(define name 2) (define #,(datum->syntax #'name (symbol-append 'define- (syntax->datum #'name))) 33) <wingo>not sure what the expectation is <sneek>Welcome back wingo, you have 1 message. <nalaginrut>wingo: the meaning of the code is trivial, but it should run <wingo>that's not a bug report anyway :) <wingo>can you paste a well-formatted code sample with expected result and actual result <wingo>to paste.lisp.org if you can <wingo>i have some ideas as to what is wrong but i need a self-contained test case <wingo>nalaginrut: did you read the NEWS section about this <wingo>see the entry titled "** Pseudo-hygienically rename macro-introduced bindings" <wingo>not sure if it bears on this exact situation <wingo>but still your test case isn't self-contained <wingo>can you make sure to include the use of the macro also <nalaginrut>wingo: the test case is simple, just run (define-art ccc), the error in 2.1 is "ERROR: In procedure module-lookup: Unbound variable: define-" <wingo>so please, a full test case would be helpful <nalaginrut>wingo: I'm so sorry, it works now, I think the REPL was broken by me in several experiments of syntax before, I entered a new REPL, and it's fine now... <nalaginrut>wingo: please close the bug report, sorry for bothering <nalaginrut>wingo: anyway, I change my code from define-macro to define-syntax, and the latest Artanis works in 2.0 & 2.1 now ;-) <nalaginrut>but I think there's something wrong when expanding define-macro, anyway, I don't want to use it anymore, if possible *nalaginrut has to go home <dsmith-work>mark_weaver: btw: master has been passing make check for me for quite a while now <bipt`>this program fails in 2.0 and prints 42 in master: (use-modules (ice-9 match)) (export _) (match 42 (_ (display _))) *stis have been bitten by weak tables <stis>the key cannot be part of the value!! <civodul>bipt`: that's expected, because of hygiene extended to top-level bindings in master <zacts>civodul: so what was ijp's GSoC project again, (if I may ask)? :-) <zacts>iirc it had something to do with guile and JS? <stis>civodul: We need better weak hash table documentation <stis>this technical point is not included, and it can create bugs that can be hard to spot <stis>Java weak maps have the same issue, so it looks like a needed deficiency in the gc <stis>yeah! that would be one cool effort! <stis>maybe the weak key issue is a feture, but nevertheless the doc must be clear on the semantic <bipt`>civodul, thanks, that makes sense. i forgot that syntax-rules literals have to be unbound to match <paroneayea>I'm thinking of writing an implementation of the w3c socialwg stuff in racket, and then try to bring it back to guile, partly so I can get a sense of what the racket people are doing webdev wise <bipt`>after fixing a bunch of 'match' forms, guix seems to be compiling successfully under guile master :) <paroneayea>bipt`: are you trying out the guile-emacs stuff I sent? <paroneayea>regardless, glad you're joining the guix collective :) <bipt`>paroneayea, yes, i'm going to try to reproduce the error <davexunit>bipt`: I'm also glad you're giving guix a try. :) <bipt`>and it's a good excuse to finally learn guix *davexunit is wearing his GuixSD shirt today <wingo>stis: it's incredible isn't it <wingo>credible but a really irritating condition, if you run into it :P <stis>wingo: lol, np. I eat iron grabage for breakfast. I manage ;-) <stis>I'm trying to get a functional weak set working somewhat. <stis>I'll just separate the keys from the values internally <stis>It was just so neet to keep a (k . v) in the vhash vector <stis>using a weak vector to store them, then use a weak-key hash table <stis>to manage the kind of key value pair. *stis is heading back to the drawing board *zacts sobs and cries, and throws a fit, and hides behind a rock *paroneayea grabs white shirt, draws rough approximation of guixsd logo on it with a sharpie, hands to zacts <wingo>stis: interesting :) you might want to search for "ephemerons" <civodul>bipt`: i'm interested in the literal '_' patch for Guix :-) <wingo>should guile 2.2 define _ in the root module? <wingo>it's a common catch-all identifier in patterns... <wingo>in the same way that the r6rs defines "else" <civodul>but it's also a common shorthand for 'gettext' <civodul>i guess in Guix we should just switch to G_ instead, something like that <civodul>but yeah, this one's gonna be a problem <wingo>we could make a synonym for _ in match <wingo>dunno what though, or if that could be made compatible :/ <bipt`>i can send it in, but i don't think the new 'match' behavior is actually useful. it's not like it matches things _against_ the existing binding, it just creates an extra binding that won't normally be used <wingo>it was better than my joke bad idea which was the euro sign which i don't know how to make under guixsd :P <davexunit>wait, _ in match isn't going to work right anymore? <stis>wingo: thx, i'm planning to make those for prolog variables in guile-log <wingo>bipt`: it makes it so that you can rename keywords, for one <wingo>auxiliary keywords should usually be defined <wingo>to do otherwise is to invite this kind of bug <wingo>dunno, i would need to pull up better arguments to defend this change more extensively, though it did fix some bugs in our r6rs implementation <wingo>the NEWS has a paragraph on this *wingo pushes more compiler hacks to master, la la <wingo>not interesting from a user perspective yet tho <wingo>just a refactor to start allowing other things <wingo>yes that is probably better :) ***bipt` is now known as bipt