<aleix>i just have ((_ (unquote-splicing val)) <aleix>which only generates (1 (2 3) 4). my macro knowledge is very limited and rotten right now. any ideas? <davexunit>aleix: I think we're going to need to restructure the macro to make it work. <davexunit>I've done some basic research into quasiquote implementations, but not enough to produce a working patch. <davexunit>so I just filed an issue when things didn't go as quickly as planned :) *davexunit reads more about writing a simple implementation of quasiquote <Madsy>Working on Guile's quasiquote? <davexunit>no, I'm trying to write my own simple version so that I can understand how unquote-splicing works. <davexunit>I want to patch guile-json to support unquote-splicing in a macro <Madsy>I can use them, but heck if I know what happens under the hood. <davexunit>things that can written using only define-syntax-rule <Madsy>Okay. I haven't used macros a lot under Guile yet. But I feel fairly confident in Clojure ***fangism is now known as fangism-hongry
<davexunit>how would I write a macro that checks the type of an input s-exp before quoting it? <davexunit>like if the syntax-rule were ((_ val) (quote val)) <McBurgerMc>mark_weaver, do you know who came up with using 'she' as the neutral pronoun in the guile docs. <McBurgerMc>I think it's funny. It messes with your expectations. <davexunit>McBurgerMc: it's been a thing that the FSF/GNU have been doing for awhile. <McBurgerMc>It's funny to read these super serious docs poking fun at the normal standard. <davexunit>yeah, it's funny to use a gendered pronoun, but the opposite one than you would expect. <McBurgerMc>I like how our law book uses he everywhere for easy reference and same sex marriage does not apply to being elligible to succession to the throne, so you have sentences like "The King must abdicate if he announces an intention to marry a husband not of a sex opposite to him" or something like that. <mark_weaver>davexunit: yes, you can check the type if you use syntax-case. <davexunit>mark_weaver: ah okay, I was hoping to avoid that, but I see that it's the only way. <davexunit>I'm proposing a patch to fix something that's been bugging me in guile-json. <mark_weaver>for example: (define-syntax my-type-of (lambda (form) (syntax-case form () ((_ val) (number? (syntax->datum #'val)) #''number) (_ val) (symbol? (syntax->datum #'val)) #''symbol))) <mark_weaver>sorry, that's kind of hard to read without formatting it. <davexunit>guile-json was has a 'json' macro that was using syntax-case to do type checks. <davexunit>I decided to try throwing out the type checks and just use syntax-rules instead. <mark_weaver>guile's implementation of quasiquote is near the end of psyntax.scm. <davexunit>yeah I was trying to read it, but it is pretty complicated. <davexunit>I found a really simple version that works only on lists that cky wrote, actually. <davexunit>that really helped me understand at a simple level how unquote-splicing works. <mark_weaver>yeah, it could be made much simpler if it generated less optimal code. <davexunit>yeah, I'm glad it is complicated and optimal. :) <davexunit>but for learning, I needed to find something simpler. <McBurgerMc>davexunit, I don't believe that's entirely the case. <McBurgerMc>As in, the things generated by quasiquote and quote are constants. <McBurgerMc>THere is actually a minute difference between `(1 2 3) and (list 1 2 3) <mark_weaver>things generated by quote are constants. but that's not true about quasiquote <mark_weaver>well, it's permissible for some parts of the data structure returned by quasiquote to be constants. <mark_weaver>no, you shouldn't assume that you can mutate `(1 2 3) <mark_weaver>I believe that `(1 2 3) is permitted to expand into '(1 2 3) <McBurgerMc>What if we mutate the first element of the list that function returns? <mark_weaver>with guile-2.0.x, you are effectively modifying the code. <mark_weaver>literally, if you look at the code in the debugger after mutating a literal list, you'll see the change that was made. <mark_weaver>I hope that guile 2.2 will give an error in that case. compiled literals should ideally be a read-only memory. <McBurgerMc>And if you have twice '(1 2 3) in different source locations, does it then make them eq? <mark_weaver>McBurgerMc: oh, sorry, I didn't look carefully at your example. <mark_weaver>(lambda (x) `(1 2 ,x)) doesn't have anything immutable in it. <mark_weaver>it has no choice but to expand to (lambda (x) (list 1 2 x)) or equivalent. <mark_weaver>in that caes, the tail of the list can be shared and immutable. <mark_weaver>you can see what they actually expand to using ",expand" at the Guile repl. <mark_weaver>if you put '(1 2 3) twice in the same program, the compiler is permitted to combine them into the same list. and in practice, guile-2.0.x does this if they are in the same file. <mark_weaver>and I believe it also shared parts of literals, e.g. '(1 2 3) and '(3 2 3) is permitted to share the same tail, and I believe guile does that in practice if it's compiled to the same .go file. <mark_weaver>McBurgerMc: that means 'cons' from the (guile) module. <zacts>hey mark_weaver, may I ask you later this upcoming week with help on implementing those procedures for my (scheme) book? <zacts>I'm kind of busy tonight, but next week I'll be getting back into the book again <davexunit>looking for some opinions: guile-json does something that I don't like. when it parses a JSON object, it uses a hash table to represent it instead of an alist. <davexunit>the argument for choosing a hash table was that the JSON spec mentions an unsorted container <mark_weaver>davexunit: yeah, I think an alist would be better for that. <mark_weaver>well, alists for more efficient for small dictionaries, and easier to work with. <davexunit>mark_weaver: okay, glad we're on the same page here. <mark_weaver>if you expect a JSON dictionary to be large, you can always convert it to a hash table. <davexunit>I just sent the author a patch for unquote-splicing support in the 'json' macro, but we can avoid that macro all together and just use quasiquote. <mark_weaver>I wrote a simple json parser once that produces alists. <mark_weaver>I don't remember how careful I was about implementing the entire spec; at the time it was just a means to an end for a hack I was doing. <davexunit>I would like to convince the author that this is the best approach, since guile-json is already packaged in guile and used by other projects. <davexunit>it would be nicer to work with, and it would eliminate my unquote-splicing problem, too. <mark_weaver>when you say it's "packaged in guile", what does that mean exactly? is it in the guile repo? <paroneayea>davexunit: json.el in emacs has multiple marshalling options <paroneayea>you can set it to hashmap, alist (and I think something else?) <paroneayea>I can see how alists would be nice, especially if you want preserved ordering (which some people do w/ json) but there have been times wher I have serialized and unserialized some *rather large* structures <paroneayea>and strictly to alists I would find... surprising. <davexunit>I think alist should be the default for guile-json. that way I can use a simple quasiquote to construct a JSON tree much like I already do with SXML <paroneayea>I definitely see how doing the tree would make sense like w/ sxml <davexunit>the hash table detail requires a special macro and re-inventing unquote and unquote-splicing *paroneayea onto chapter 4 of The Little Lisper tonight <davexunit>going to give this JSON stuff a rest for now. I should go to bed soon. <zacts>I finished the little schemer, but I want to redo the last few chapters again <zacts>I still have yet to do the other two books of the series <zacts>I'll probably get thru them this semester, as I'm taking a Philosophy of Logic this semester <zacts>and the last book applies logic to (scheme) <paroneayea>zacts: yeah I didn't pick up the seasoned schemer, but I did pick up The Reasoned Schemer (which according to the back doesn't depend on the seasoned schemer) <zacts>paroneayea: have you ever completed a logic class at college / school? <zacts>I have a dover book on logic that is nice also, with all of the mathematical logic notation <zacts>I'm guessing that completing the reasoned schemer prior to taking a logic class would be the best most intuitive way to learn it. <paroneayea>zacts: I never have, unfortunately... I've done some of it on my own <zacts>then after a logic class re-read the reasoned schemer again <paroneayea>ugh, my guile REPL in geizer is not doing history right <paroneayea>M-p is not going to last command and it's driving me crazy... I should debug it but I'm mid-exercises :) <paroneayea>not happening in any other comint-mode, so that's weird... <zacts>man, I would probably use emacs again, but I really love vim bindings for most stuff <zacts>emacs actually hurts my left thumb from the alt key, perhaps a new mapping would help <zacts>I know of evil-mode, but it's far too slow for me <taylanub>anyone remember what the solution to 'error: possibly undefined macro: AC_DEFINE' is? <bipt>try again? i recently updated the build system so it should finish successfully <taylanub>bipt: I seem to be on the latest state of the repo. trying the wip branch BTW <bipt>until recently it just crashed after building "temacs" since elisp can't be compiled to serializable bytecode yet <taylanub>it fails much earlier, at dispnew.c or so. it is worth reporting this? actually I'm not sure what in my system could make things go wrong. to be fully sure I might remove ~/.guix-profile from my PATH and try with pure Debian stuff, but then I'll have a slightly outdated toolchain. what GCC version etc. do you use? <bipt>gcc 4.9.1-5 from debian, libgc "7.5.0" from...either git or the 7.4.2 tarball, guile from the "wip" branch of git://git.hcoop.net/git/bpt/guile.git <bipt>if you have that guile branch and a recent libgc, then yes, i'd be interested in a bug report <bipt>that's probably the problem. 2.0.x has a four-year-old version of the elisp compiler :) <taylanub>is that GCC from Debian "testing" or "unstable"? are those generally fine? <bipt>and that branch has some changes to guile itself (arbitrary constants in compiled code, guile-snarf bugfixes) that might affect compilation <bipt>yeah, anything recent should be ok <paroneayea>so how much of guilemacs is working then, out of curiosity? is there much left? <bipt>paroneayea, at this point, almost everything works. i'm sure there are some bugs remaining, but i can, for example, load my normal init file, check mail with gnus, run org-mode, and so on with everything running on the guile vm <bipt>and most recent bugs were from packages that make very specific assumptions about the underlying system, like gnus macros that generate raw bytecode for the old interpreter <paroneayea>bipt: are you going to email the emacs devel list with that update soon then? :) <bipt>yeah. i've talked with stefan about it. it just became generally usable about a week ago; before that building it required too much trickery (hacking makefiles to generate autoload files with a preinstalled normal emacs, that kind of thing) <paroneayea>bipt: I'd love to run guilemacs as my default emacs :) <bipt>i'm setting up a debian VM so i can write proper instructions <bipt>the main problem atm is that it's noticeably slower than normal emacs, due to horrible hacks for supporting the various kinds of magic variable bindings elisp allows <bipt>which wouldn't be a problem if most of emacs had lexical binding enabled, but that's only ~200 out of ~1500 files right now. i'm working on extensions to guile fluids that should make it possible to implement buffer-local variables in a cleaner way <bipt>the wip branches of both git://git.hcoop.net/git/bpt/guile.git and git://git.hcoop.net/git/bpt/emacs.git *mark_weaver really needs to learn how to configure and use multiple remotes in git, rather than doing separate clones for each upstream. <taylanub>I actually do separate clones even for branches if I want to test them both often, since compilation dirties the directory. is there a better alternative? <mark_weaver>taylanub: the 'contrib' directory in the git source code has a script call 'git_new_workdir' which allows you to have multiple working directories backed with the same git store. <mark_weaver>one advantage to using a shared git store is that you can do things like merge branches and cherry-pick from one branch to the other. <mark_weaver>basically it works by creating a special .git directory in the new working dirs where many of the items are actually symlinks to the .git in the original clone. <mark_weaver>so the only thing to be careful about is that you don't delete your original working directory, since that's the one where all the git storage actually resides. <paroneayea>it makes the whole multi-remote thing a lot nicer <paroneayea>and it makes a whole lot of things like "ohhhhhhh, so now that's finally useful" <mark_weaver>ah, okay. I do use magit, but I haven't learned how to use most of its features yet. <paroneayea>M a: (adding a remote), give the name, then give the URL <paroneayea>and you can also view all branches, including remotes, with <paroneayea>that should be good enough to get you started with it! <mark_weaver>bipt: where's the upstream emacs git repo that yours is based on? <mark_weaver>paroneayea: is there an easy magit way to create a local branch that will automatically track a remote branch? <paroneayea>the easest I find is actually just to switch to the remote branch and it'll prompt you <paroneayea>it'll ask you if you want to do a local tracking branch <bipt>mark_weaver, yes, the official git mirror <mark_weaver>it's a big repo, I'd rather have only one copy of it :) <mark_weaver>this is very exciting. I don't even care if it's slower. it'll just motivate me to help make it faster if needed :) ***cluck` is now known as cluck
<bipt>i'm glad to hear it :) there's definitely stuff i'll need help with on the guile side of things <mark_weaver>I'd be glad to help. let me know what you need and I'll work on it. <bipt>i just noticed that the current version fails when generating semantic grammars. but not until generating unicode data files, autoload files, etc. so i didn't notice. will push a fix after guile rebuilds <bipt>btw, guile hacking is far, far more fun on something more modern than a low-voltage core 2 duo cpu from ~2008 <mark_weaver>but I'm used to a YeeLoong, so I've been accustomed to slow compiles for some time. This X60 seems blazingly fast in comparison :) *mark_weaver begins the guile build from bipt's 'wip' branch ***george2 is now known as Guest15826