IRC channel logs
2014-06-16.log
back to list of logs
<Lajjla>ijp, I gather you are fairly knowledgeale, are you not? <ijp>there are things I know, things I don't know, things I think I know, and thinks I know I don't think I know I know I think <Lajjla>ijp, what's with the general dislike towards square braces? <ijp>well, they don't actually bring anything new to the table, and the readability improvement is subjective <Lajjla>THat's only because of 90% of programming languages, with the exception of syntax they are pretty much identica. <Lajjla>Apparently Javascript even originated from trying to give Scheme C-style syntax. <Lajjla>Originally the creator wanted S-expressions or something but Netscape would not have it. <ijp>the point is, it's syntax, and therefore everyone can weigh in on the discussion <Lajjla>Well, the most hotly debated issue seems to be unlimited or delimited continuations and whether or not values should continue to exist as a primitive. <Lajjla>I don't see much debate on [ ... ] except that most peple seem to agree it is useless which I never got. <ijp>plus, negative opinions always outweigh positive opinions <ijp>positive and neutral* <ijp>if you like something or don't care, you don't mention it <Lajjla>Negative opinions are more useful I would say, there is little use in praising the status quo, it will remain that way even if people are silent, negative opinions inspire change. <Lajjla>Oh, and one other thing, is it intentional that when you do [import [prefix [srfi :88] s88:]] it basically fails because it makes s88: a keyword <ijp>:foo keyword syntax is not on by default <ijp>the default is #:foo <ijp>do we even support that? <ijp>ignore the first two lines, I was thinking of a different issue <ijp>I don't think it *should* fail <ijp>*but* it will fail if you do it on other imports *after* you load srfi 88 <ijp>so having it fail there is not such a big deal <ijp>sigh, I really hate reader modification <Lajjla>ijp, is it possible to write your own modules that do that anyway <Lajjla>But yeah, default is #:key, not key:, but I needed 88 to get s88:keyword? to test for it <ijp>well, all (srfi srfi-88) does is basically (read-set! keywords 'postfix) <ijp>but once you do that, any subsequent use of foo: is going to be treated as a keyword <Lajjla>One assumes the entire reader completes reading the entire document before such things are evaluated? <ijp>otherwise you couldn't enable it for macros you are writing <Lajjla>So the reader actually reads it one expression at a time, evaluates one, and then reads the next one? <ijp>funnily, also not true <ijp>I *think* it works like that for macros, but obviously you can compile and stuff, so you don't necessarily evaluate all forms <ijp>life would be much simpler IMO, if we did have a separate read phase <Lajjla>It makes it it easier to understand for my special brain <Lajjla>ijp, so, if I import a module that has imported srfi :88 but exports nothing from it, it also turns the symbol syntax to foo: instead of #:foo in the module that imports the module that imports 88 <Lajjla>Surely this cannot be intended behaviour <ijp>the reader is/was a global setting <Lajjla>Kind of goes against the idea of a module though. <Lajjla>If the module doesn't export reader settings it should stay in it one reckons. <ijp>perhaps, but that is not the way the reader works <Lajjla>Anyway, is there some syntax to force it to be a symbol. [prefix (srfi :1] |s1:|] does not seem to work <ijp>Lajjla: if you don't need the two procedures actually exported by srfi 88, don't import it, just do the reader modification in your own module <ijp>that avoids the issue altogether <Lajjla>ijp, well, I do, I needed 88/keyword? <Lajjla>To see if something is a keyword <ijp>srfi 88 does not export keyword? <Lajjla>It does actually, srfi 88 says so <Lajjla>And s88-keyword? seems to work in the code <Lajjla>We have keyword? keyword->string and string->keyword <ijp>the srfi 88 module does not export keyword? because keyword? is already in (guile) <ijp>I see, so this has changed in between whatever version you have, and the one I have <ijp>Lajjla: alternatively, don't use prefix, but rename <ijp>there are only 2/3 procedures, this is not onerous <Lajjla>Well, if I would rename I would all rename them to s1:whatever, I like to quantify names so that whoever reads the code knows in what place they are defined. <Lajjla>keyword is indeed already defined in guile but I don't like to rely on implementation-specific extensions and try to stick to r6 and the srfi's as much as possible. <ijp>(import (rename (srfi :88) (keyword? srfi-88:keyword?) ...)) <Lajjla>Yeah, but that still disqualifies x: as a symbol for anyone who imports the module that imports srfi :88 <ijp>of course it does, x: is no longer a symbol <taylanub>Lajjla: have you considered using :foo notation for keywords instead of foo: ? It's also what CL and Elisp use and nearer to #:foo so it might be a nicer choice for being same/closer to what others are used to, and has the bonus of not having the issue you mention <ijp>srfi 88 specifies that those types of "symbols" are really keywords <Lajjla>taylanub, well, I don't have much of a choice, as soon as I import srfi-88 it becomes foo: <ijp>this is not an effect you can readily contain to one library <Lajjla>In that module, and any module that may import that module. <ijp>actually, this is a pretty good example of why srfis aren't the same thing as libraries <Lajjla>ijp, you could let each library be read by its own reader though. I don't know, the idea of a module sort of implies that such things don't leak out unless explicitly exported <Lajjla>Some srfi's do seem to call for pretty strange modifications that can't be done in pure scheme I guess <ijp>you could make readers file local. I would like this. We don't. <Lajjla>But I might just throw importing 88 out of it all togethar and add a disclaimer "This implementation relies on your scheme supporting keyword?"