<ijp>just a show of hands, how many people other than wingo have a good handle on the rtl and cps work? <mark_weaver>I'm not sure I'd say I have a "good handle" on it, but I gained some familiarity with it while fixing many bugs in it a few weeks ago. <civodul>our bus factor has decreased somewhat ;-) <ijp>well, I was thinking of going through it and making some notes, and I guess this means I can use civodul as a guinea-pig <ijp>just do be sure, do we associate syntax information with anything *other* than identifiers? <ijp>assuming no, I have a smarter define-macro, following a tip from eli on #scheme ***fangism is now known as fangism-illusion
<ijp>gah, I went from having something that seemed to be working, to having something atht is nowhere near working, and now I don't know who I am, how I got here, and where my lollipop is <ijp>expect a define-macro patch tomorrow! ***banannagram is now known as bananagram
<dje42>Seems like Guile should have vector-map and vector-for-each builtin. <mark_weaver>for example: (vector-ec (: i 10) (* i i)) => #(0 1 4 9 16 25 36 49 64 81) <dje42>There's a lot there alright. <mark_weaver>another interesting approach is foof-loop, quite a bit different than SRFI-42, maybe a bit better, but not an SRFI and not (yet?) in Guile by default. <dje42>Interesting. Thanks. Again. :) <mark_weaver>you're welcome! if you decide you want to use foof-loop instead, in the worst case you could bundle it with your code. <mark_weaver>SRFI-42 has one notable advantage over foof-loop though: SRFI-42 is easier to extend. <mark_weaver>(That could be fixed by rewriting foof-loop to use ck macros, but I digress) *nalaginrut is using his no-key-print hhkb <nalaginrut>typeS is claimed the silence one, but I made the wrong order <nalaginrut>since it has to be shipped from Japan, I don't want to change the order <mark_weaver>a no-key-print keyboard. I don't think I've ever used one of those. <mark_weaver>I think it would take some getting used to. I wouldn't have any trouble finding the usual keys (I touch type), but there are some keys whose exact position is not standarized, and varies from keyboard to keyboard. <nalaginrut>if you can endure no-arrow-keys, I think it's fine for you <nalaginrut>and the special keys could be set, there're several mode on it <mark_weaver>like the function keys, for example. it seems like it would take some practice to know where F8 is. <nalaginrut>but now, can you believe I typed all the sentence blindly <mark_weaver>of course, I live in emacs, and I rarely use the arrow keys. I type ctrl-[ instead of ESC as well, for the simple reason that the key positions are the same on every keyboard. <nalaginrut>maybe the only challenge for you is no-key-print <mark_weaver>but I used to have an HHKB keyboard that looked exactly like that (except mine had key prints :). I don't remember the exactly model number of mine though. <mark_weaver>I don't use mine much anymore, since it has a PS2 interface. So obviously an older model, but basically the same design otherwise. <nalaginrut>alas, it's designed for Emacs I think, so if I can't do all the work in Emacs, I have to plugin a mouse <mark_weaver>It's by far the best external keyboard I ever owned. <mark_weaver>and I really appreciated that the key to the left of A was actually labelled "Control", as it should be :) <mark_weaver>indeed, and I always do within seconds of working with a new keyboard. <mark_weaver>I'm damned near useless on a keyboard where that key is bound to caps-lock. <nalaginrut>I complained the ctrl issue to wingo before, Lispy programming made my little finger crash <mark_weaver>both "crash" and "break" suggest a sudden traumatic injury, whereas I get the impression that the problem you're having is more like a repetitive stress injury (RSI). or no? <nalaginrut>sometimes when I done the hack, the little finger can hardly get unbend <dje42>I use the DataHand KB. Keeps my RSI under control. <mark_weaver>RMS had problems with RSI also. I know that he had typists at various times when it became too much. <dje42>I had a typist once too. It was not productive. She kept asking "Why are you doing it this way?" :) <nalaginrut>someone once said he ever saw a guy was typing crazily, and he thought he's typing mail for some girl, but finally he found the guy is typing lisp code <mark_weaver>I was RMS's typist in the Boston area when he shattered his elbow about 10 years ago. <dje42>[the elbow, not being a typist. :-)] <mark_weaver>He spoke a stream of keystrokes and words, and I simply translated those sounds to keypresses as quickly and accurately as possible. <mark_weaver>well, this was interactive use of emacs: mostly reading and writing emails, so the time delay would completely destroy the interactivity of emacs. <nalaginrut>ah~I guess the mail from RMS is actually you wrote it <dje42>It's late. 'nite. Hopefully (fingers crossed) I'll get my initial gdb-guile patch uploaded to github this weekend. <mark_weaver>dje42: okay, good night! looking forward to seeing the code :) <dje42>[whether it will ever go into gdb without a massive rewrite is still an open question of course] <dje42>[well, not that massive ... there's not much there yet] <dje42>That's the plan. But I needed to get a first pass done. There's still lots to do. <shanecelis>It was going well, but I'm having a lot difficulty with syntax-case. <shanecelis>It's his coroutine code, which works great with things like codefine, same syntax as define, but it can be yielded like a coroutine. <shanecelis>The problem is, codefine* like define* doesn't work. <mark_weaver>well, I'm not sure anyone has yet implemented anything like that for a macro system. <mark_weaver>it could certainly be done. is that what you're trying to do? <shanecelis>Yeah, my success case is, (codefine* (my-coproc a #:optional (b 1) c)) works. <shanecelis>And I know what it should look like, but by syntax-case fu is weak. <mark_weaver>well, for one thing, that 'lambda' on line 98 should be lambda* <shanecelis>I have a helper macro that's supposed to do the work of transforming (a :optional (b 1) c) into (a b c) so that line 98 will work. <mark_weaver>I think 'codefine*' should be the same as 'codefine', except (define -> define*) and (lambda -> lambda*). <mark_weaver>(the "I'm not sure anyone has yet implemented anything like that for a macro system.") <shanecelis>line 98 when expanded becomes (lambda () (my-coproc <shanecelis> a #:optional (b 1) c)) but this isn't for defining the procedure, it's for calling it. It should be (lambda () (my-coproc a b c)). <shanecelis>So, I wrote this strip-optargs macro to try and fix that part. <shanecelis>I want ,expand (strip-optargs a #:optional (b 1) c) => (a b c) <mark_weaver>well, when you insert that . , I think it will misbehave in other ways. <shanecelis>yes, it seems like when I do that, then my recursive macro call won't happen. <shanecelis>(at least, that's what I think is happening. It results in some error.) <mark_weaver>the problem is the 'rest' is bound not to (b c) but rather to (strip-optargs b c) <shanecelis>I don't know how to control when things are evaluated with syntax-case well-enough to make that happen. <shanecelis>What if instead of (v rest), I had something like (cons-macro v rest)? <mark_weaver>first, forget about macros and just write a procedure that converts the list (a #:optional (b 1) (c 2)) to (a b c) <mark_weaver>and here's an important point: syntax-case is just a pattern matcher for syntax objects, and can be used in any procedure, not just ones that happen to be macros. <shanecelis>Ok. so what's the correct way to test this: (strip-optargs-proc #'(a #:optional (b 2) c)) <mark_weaver>okay, strip-optargs should be a normal procedure, not a macro. <mark_weaver>so then the recursive call to 'strip-optargs' in the with-syntax form should be just (strip-optargs ...) with the #' in front. <mark_weaver>and you can test it from the REPL by typing something like (strip-optargs #'(a #:optional (b 1))) <mark_weaver>and, as I said before, #'(v rest) on line 110 should be #'(v . rest) <mark_weaver>you should probably add (keyword? (syntax->datum #'v)) as a guard in some of those. <mark_weaver>on line 134, it should be (with-syntax ((callable-args (strip-optargs #'args))) ;; <shanecelis>mark_weaver: yep. ok, cool. now the strip-optargs macro will just go away right? I'll just strip-optargs-proc the procedure which I call, yep, line 134. <mark_weaver>right, there's no need for the macro. I assumed that 'strip-optargs' would be the name of the procedure. <shanecelis>(strip-optargs-proc #'(a #:optional (b 1) c)) works now, is there a way to strip the syntax off the result? <mark_weaver>you shouldn't strip the syntax. it's very important to keep it there. that's the whole reason we use syntax objects. <mark_weaver>the syntax-case system can be thought of as a fairly minimal replacement for old-style macros, but where the syntactic bindings are preserved, which is what syntax objects do for us. <shanecelis>ok. When I feed it this: (strip-optargs-proc #'(a #:optional (b 1) c)) I get a list of syntax objets. <mark_weaver>ugh, I wrote (identifier? (syntax->datum #'v)) but that wasn't right either. just (identifier #'v) <shanecelis>However, in the codefine* macro, I get one syntax-object. <mark_weaver>you can't count on the syntax object of a list being represented as a list of syntax objects. <mark_weaver>syntax objects are represented in a sort of lazy way. <shanecelis>ok. So I will have to use syntax-case to deal with it. <mark_weaver>the simplest rule is that you should always use syntax-case to destructure syntax objects. <mark_weaver>when you get a bit more experienced with syntax-case, you'll discover than in practice you can get away with assuming that a given syntax object is a list, and I confess I've written code that assumes this, but I can't condone the practice. <mark_weaver>since the code only handles #:optional properly, maybe it should just match for #:optional instead of any keyword. <mark_weaver>the ((_ (v e)) #'(v)) clause is redundant. You already have a base case: '() <mark_weaver>okay, now 'codefine*' has to be a syntax-case macro, because it needs to call the procedure 'strip-optargs'. <shanecelis>$92 = (define* (f #:optional (a 2) (b #f) (c #f)) <shanecelis>hmm... strip-optargs somehow skips every other argument (func a b c d e) -> (func a c e) <mark_weaver>you don't need the cases on lines 106-107 and 113-115 <mark_weaver>and the "(_ (v e) e2 ...)" case should have (identifier? #'v) as the guard. <mark_weaver>you were writing this as a macro before, where 'x' was the entire form of the macro usage. <mark_weaver>in that case, the first element of the list would have been the name of the macro itself, which would have matched _ and then been discarded. <mark_weaver>but this is not a macro anymore, and 'x' is its argument, not the form containing its name. <mark_weaver>why don't you clean it up and show me the result in case there are any remaining issues I might notice. <mark_weaver>okay, again, lines 95-96, 104-105, and 112-113 are redundant. <mark_weaver>and, if you prefer, (with-syntax ((rest (strip-optargs #'(e2 ...)))) #'(v . rest)) could be written as #`(v . #,(strip-optargs #'(e2 ...))) <mark_weaver>in fact, if you want to enforce that a list cannot be empty, you need to write it like this instead: (e e* ...), or maybe (e0 e ...) <mark_weaver>it's a good idea to make a macro fail as soon as possible, for better error reporting. <mark_weaver>it's not good to use 'e' as the labels for these things, because they do not correspond to expressions or anything like an expression. <mark_weaver>I don't know, naming things is hard. I chose 'b' for binding. maybe you should spell it out. <shanecelis>This thing was driving me crazy. Thanks so much for your help, Mark! <shanecelis>That was tough, but I learned a lot going through all that. The clean up was really illuminating. <mark_weaver>shanecelis: okay, now that you've learned something, I see now that this could be solved in a much simpler and more robust way, without using syntax-case at all. <mark_weaver>that is completely self-contained. 'strip-optargs' is not needed. <shanecelis>All right. Going to bed. It was good hacking with you, Mark. ***nalaginrut_ is now known as nalaginrut
<TaylanUB>Hrm, the HACKING file is quite old I presume ? Talks about GCC 2.7 ***add^_` is now known as add^_
<TaylanUB>Some of the README files lying around seem quite old too, I see mention of a guile-tut.texi (Guile tutorial) but couldn't find it. *TaylanUB is poking around to see if there's any pointers on how to hack Guile internals. Can never tell whether one should look into libguile/, module/ice-9/psyntax.scm, module/ice-9/boot-9.scm, or where ... <ijp>I have a half solution, but I keep accidentally introducing a loop <ijp>a lot more complicated than I think it should be, but it works <ijp>my problem was that I was implicitly relying on evaluation order in two places <ijp>TaylanUB: not standard! *ijp reads the rest of the blog post now <TaylanUB>Why is you-know-what not standard yet!? :P <ijp>actually, I think these days we are down to two camps. prompt/control and shift/reset <TaylanUB>I thought one is simply more generic than the other ? <ijp>and as far as I know, both can express the other, so it's mostly about defaults <ijp>C Shan, Shift to Control, 2004 www.cs.rutgers.edu/~ccshan/recur/recur.pdf <TaylanUB>In its core, that situation doesn't sound any worse than, say, `if' and `cond'. :P So just put them both in the standard ? By the way I have to say I find explicit usage of `call-with-prompt' the most intuitive/simple to use. <ijp>you'll never get people to agree to put both in <ijp>that is unthinkable! <ijp>why have conditionals at all, when you can church encode them? <ijp><assorted opinions somewhere in between> <TaylanUB>I'm just saying, I'm not aware of the standards having a requirement of specifying only one of two things that can define each other. <TaylanUB>So as long as there's no third camp, just put these two in and move along ?.. <ijp>you did see how many control operators there are in the link above? <TaylanUB>Well I was thinking in terms of the two camps you mentioned. <ijp>yes, but if you are just specifying everything (the jcowan model) what criteria do you have for dismissing them? <TaylanUB>Whether there's a *cough*nuthead*cough* who stands up and protests the exclusion of one. <ijp>then jcowan can be that nuthead <ijp>did you see, e.g. his hashtable proposal? I can't imagine *ever* using more than *half* of those procedures <ijp>I did some nitpicking for him on it, but he didn't accept my position on the quantity <ijp>jcowan is the purest example of a large standard schemer there is <TaylanUB>I'd say over-specifying is better than under-specifying, for the purposes of the -large language. <TaylanUB>Because it wants to be a large language. :P <ijp>moreover, I disagree that it is over-specifying in one particular sense <ijp>he specifies too much crap, and he under specifies that crap <ijp>see, I have two problems with computing standards at large <ijp>1. unspecified behaviour <ijp>2. everything should be in the standard <ijp>it is a wonderful irony that these two coexist <TaylanUB>Uh, trying to solve that quiz with call/cc, my hate for call/cc increases. -_- <ijp>symbols are such a simple datatype aren't they? <TaylanUB>Not outside of Scheme, apparently, and now all the crap they're abused for comes to Scheme ... :P <TaylanUB>IMO they should be just "automatically interned immutable strings". <TaylanUB>Which they already are, except that you have to convert them to a string and back to be able to use string functions on them. <ijp> (symbol-ref symbol) Returns an object which is the value of symbol. The value may or may not have anything to do with the global binding of the identifier corresponding to symbol. <ijp>"the value may or may not have anything to do with" <ijp>it is completely meaningless <TaylanUB>"Redundant and useless" is what I should say I guess. <ijp>"the procedure car may or may not have anything to do with the secret nazi moon base" <TaylanUB>I'm indeed kind of baffled now as to why they would bother to add such a "symbol" API to Scheme. <ijp>because they have no real criteria for exclusion <ijp>the only way you can be all things to everyone is by being nothing to no-one <ijp>now, I'm going on a timeout for 15 minutes, or I'll go on about it for an hour <nalaginrut>any method to get thread-id? I need it to name a unique queue <ijp>there is a current-thread procedure ***sneek_ is now known as sneek
<ijp>the threads identity is its unique id <nalaginrut>say, #<thread 140074166306560 (876e00)>, I may need 876e00 or others <ijp>what are you needing it for? <ijp>what is the underlying problem you are trying to solve <TaylanUB>nalaginrut: You mean this id needs to be readable/writable ? <TaylanUB>nalaginrut: What prevents you from just using the thread itself as the "name" ? <TaylanUB>So it needs to look nice when written (even if it's OK that it can't be read back in) ? <nalaginrut>read back? you mean from id to thread? no, I don't need that <ijp>so just assign one arbitrarily <TaylanUB>nalaginrut: I mean, is this just for displaying something to the user ? <nalaginrut>actually it's an simple question, don't make it harder <ijp>TaylanUB: see what I mean? <ijp>you want a unique value, that differs for each thread, it never needs to be printed, or read, or even given to the user, .... and you don't want to use the thread <nalaginrut>that's not the question, I just need a way to get thread id number <TaylanUB>Sorry, I don't understand the question even if it's simple. :P <ijp>the threads identity is it's id <nalaginrut>#<thread 140074166306560 (876e00)> I want to get 876e00 <ijp>that's what it means for something to be an id <ijp>why not, you do plenty of other stupid shit <nalaginrut>when he told me stop, I would stop, that's the way he thinks not-stupid <TaylanUB>nalaginrut: That number seems pretty useless to me, it could even be assigned to a new thread after an old one is deallocated. <ijp>I want a giant grey mammal, large ears, native to africa, matriarchal, and not an elephant <ijp>nalaginrut: I already told you, just allocate one arbitrarily <ijp>store it in a hash, done <TaylanUB>nalaginrut: You can just use the thread object itself as the key of a hash-table etc., there's no problem with that. <nalaginrut>ijp: I know how to alloc an arbitrary thing, I just ask if there's way to get thread-id number, if no ,just say no, I would try the other way <nalaginrut>it's not a chance to judge the idea I want to do <ijp>I haven't had a chance to judge your idea because you haven't told me what it was <ijp>you told me what you want to do to implement it, and I told you the thread object itself has all the properties you desire <ijp>except that it isn't a number <ijp>and since you aren't adding dividing exponentiating or whatever, who cares <ijp>thread objects are unique <nalaginrut>the question is simple that just about id number, anyway, I know the approach you described <TaylanUB>When a thread exits, a new one that's created could get the same number as the old one, so that number is not really an identity for a thread. <nalaginrut>and thanks guys, if there's no way to get number id from thread-obj <nalaginrut>ijp: yes it's XY problem, but I don't think it's worth to put your energy for a few seconds work, just a simple naming *ijp puts gun in mouth, blows brain out <ijp>I dunno, I never found out whos it was <ijp>you'd think they'd write their name on it in marker pen or something <nalaginrut>ijp: I emphasized it's a simple thing to avoid you took much time for Y <add^_>Goddarnit, if you don't want to argue, don't. <TaylanUB>But it's simpler (and more robust) to just use the thread object as the ID. <TaylanUB>add^_: There's no need to create further tension ... <ijp>gah, I'm such an idiot <ijp>protip: don't debug a macro that is not used <ijp>turns out my define-macro changes worked on both versions of the define-curried example, but in one I was using a different defintions of and-let* that didn't use define-macro <cky>add^_: s/who's/whose/ <cky>ijp: s/whos/whose/ ;-) <cky>ijp: Is your message above about implementing the define-macro-with-map idea from eli? <ijp>I've posted it to guile-user <ijp>cky: I was responding to the earlier mail <ijp>there are a few things to clean up still