00:01:55 oleo [~oleo@xdsl-87-79-197-168.netcologne.de] has joined #scheme 00:04:48 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 00:05:41 ok, so I should be thinking of recursion not as loops, but as separate invocations of the same procedure each with their own frame of name bindings. 00:06:41 so it's really another different instance of the procedure. 00:07:19 recursion was first explained to me, as loops, but it seems like it is much more elegant than that.. 00:08:07 Guest48746 [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has joined #scheme 00:08:10 -!- Guest48746 [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has quit [Changing host] 00:08:10 Guest48746 [~jao@pdpc/supporter/professional/jao] has joined #scheme 00:08:50 gjord [~gjord@ool-18babf32.dyn.optonline.net] has joined #scheme 00:10:54 przl [~przlrkt@p5B298586.dip0.t-ipconnect.de] has joined #scheme 00:11:07 basics, I'm just reviewing.. 00:15:20 I've got a scheme implementation question (of sorts) 00:15:47 -!- przl [~przlrkt@p5B298586.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 00:15:54 or I'm more wondering if I'm missing anything 00:16:27 I've got four different stacks, an argument stack, a variable frame stack, a call stack, and a dynamic wind stack, and a continuation is simply a reference to each of these at the moment it is created via call/cc 00:17:19 variable frames are simply an array containing all the *possible* variables in a given application of a closure; these variables need not all be reached, and allocating these all once isn't a problem because all looping is recursion anyways 00:18:15 cool, thanks tabemann 00:18:18 when entering a continuation, the current dynamic wind stack and the continuations' dynamic wind stack are compared; all entries in the current one not in the continuation's one have their after thunks applied, and all entries in the continuation's one but not the current one have their before thunks applied 00:18:39 -!- carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: carleastlund] 00:19:05 carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 00:19:05 -!- carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Client Quit] 00:19:13 is that a correct implementation of dynamic wind across continuation application? 00:19:46 (dynamic-wind pushes a dynamic wind stack entry when it is applied, and removes said entry when it exits) 00:20:56 damn 00:22:04 I just realized that I'll have to handle *nested* continuation applications correctly (a before or after thunk could enter a continuation *during* a comparison of dynamic wind stacks during entering a different, or even the same, continuation) 00:22:33 kuribas [~user@d54C430B0.access.telenet.be] has joined #scheme 00:22:40 just what *are* the semantics of such nested continuation application? 00:25:01 anyone know? 00:28:08 okay 00:28:22 for handling that an "after" thunk may enter a continuation 00:30:02 each after thunk removes its corresponding dynamic wind stack entry when it is applied, so if an after thunk applies a continuation, all after thunks to be applied not yet applied are still there, so that continuation application still has to apply them (unless the corresponding dynamic wind stack entries are also in the new continuation's dynamic wind stack) 00:31:08 but for handling that a "before" thunk may enter a continuation... 00:32:19 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: computer sleeping] 00:32:51 well 00:33:48 -!- Guest48746 is now known as jao 00:33:58 dynamic stack entries will only be added *after* "before" thunks are evaluated, so a "before" thunk applying a continuation will not cause the resulting dynamic wind stack to require the corresponding "after" thunk to be applied later 00:35:31 tabemann: have you looked at the papers on dynamic-wind and continuations? I believe they consider these questions fairly thoroughly if I understand what you're trying to do. 00:35:40 and instead of simply replacing the current dynamic wind stack with the continuation's, the current dynamic wind stack will be incrementally transformed into the continuation's, so if a different continuation is applied in the process a valid dynamic wind stack reflecting which "after" thunks and which "before" thunks have already been evaluated will be preserved 00:35:45 -!- agumonkey [~agu@245.217.72.86.rev.sfr.net] has quit [Ping timeout: 248 seconds] 00:37:14 (there's "Constraining Control" by Friedman & Haynes and "Adding Composable and Delimited Control to a Production Programming Environment" by Flatt/Yu/Findler/Felleisen) 00:37:33 no I haven't 00:37:46 At least they cover what the semantics is, if not how to implement. 00:37:53 *tabemann* is aiming for simple but correct implementation, not necessarily fast implementation 00:40:08 (I'm sure my implementation of creating continuations is simple, correct, and fast, but *applying* them is another story...) 00:41:21 -!- racycle [~racycle@75-25-129-128.lightspeed.sjcpca.sbcglobal.net] has quit [Remote host closed the connection] 00:42:11 bokr [~ed@109.110.53.59] has joined #scheme 00:47:04 *tabemann* somehow suspects that the many people implementing toy mini-Schemes in Haskell haven't bothered to implement call/cc and dynamic-wind together properly 00:57:18 crap 00:57:57 continuations completely mess up my implementations of outcalls from Haskell to Scheme, because any outcall to Scheme may never return to the calling Haskell function (i.e. the return closure put on the Scheme stack may never be applied)... 00:58:17 unless 00:59:00 I also implement a "cleanup" stack, that contains closures into Haskell that *will* be evaluated when applying a continuation, in a fashion similar to the dynamic-wind stack... 00:59:58 pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has joined #scheme 01:00:16 fuck 01:00:44 what if a before or after function, instead of applying a continuation calls call/cc and set!s the continuation somewhere... 01:00:52 and then someone later applies this continuation 01:02:31 actually 01:02:42 racycle [~racycle@75-25-129-128.lightspeed.sjcpca.sbcglobal.net] has joined #scheme 01:05:27 Nisstyre-laptop [~yours@oftn/member/Nisstyre] has joined #scheme 01:09:51 carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 01:16:40 -!- hiroakip [~hiroaki@p4FFDD7C2.dip0.t-ipconnect.de] has quit [Read error: Connection timed out] 01:17:11 hiroakip [~hiroaki@p4FFDD7C2.dip0.t-ipconnect.de] has joined #scheme 01:20:09 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 01:25:39 jaaso [~jaaso@109.175.27.246] has joined #scheme 01:36:29 you should name your procedures after various curse words and insults. :( $@#@#$@#$@#$@#$ ) 01:36:50 until it magically mysteriously artificially intelligently designs itself to work well 01:37:30 -!- kuribas [~user@d54C430B0.access.telenet.be] has quit [Remote host closed the connection] 01:42:47 heh 01:44:26 tabemann, consider for a `mini-Scheme' in Haskell. Doesn't have DYNAMIC-WIND or CWCC implemented, but a non-winding CWCC is trivial given how the rest of it works, and you can steal Scheme48's DYNAMIC-WIND and CWCC, which are very easy and straightforward. 01:46:00 yeah, I was originally considering call/cc without dynamic-wind, and it seemed completely trivial (just copy references for each stack encapsulating thread state into the continuation for call/cc, and copy those references into the current state when applying the continuation), and then was "oh shit" when I then read about dynamic-wind 01:46:38 You can always have a PRIMITIVE-CWCC and define CWCC in terms of that. 01:46:49 ...define DYNAMIC-WIND and CWCC in Scheme in terms of that, I mean. 01:46:55 See scheme/rts/wind.scm in Scheme48 for details. 01:47:55 many people have implemented mini-Schemes in Haskell before, which is kind of why I want to implement a full R5RS this time 01:48:20 -!- Nisstyre [~yours@oftn/member/Nisstyre] has quit [Quit: Leaving] 01:48:33 of course that I'm implementing this in Haskell makes a lot of things easier, e.g. I don't have to worry about memory management, and as the stack(s) are going to be on the heap *anyways*, that makes "primitive" call/cc trivial 01:48:39 What sets my mini-Scheme apart is that it actually has everything you need for the execution engine, and it's clearly organized using, not abusing, Haskell abstractions. 01:49:36 So you can implement Scheme's CWCC using callCC from the Cont monad (or, more specifically, from the ContT monad transformer used in the execution engine). 01:49:57 (This isn't cheating; Haskell's callCC isn't primitive like Scheme's.) 01:50:16 hmm... most of the pathological cases with call/cc+dynamic-wind seem much simpler if I preserve intermediate state during "after" and "before" application, so it can be resolved properly just in case the closures are unexpected exited *or* entered 01:50:41 I'm trying to be complete, so I am abusing IOArrays to allow the implementation of set! 01:50:44 efficiently 01:51:06 especially because I plan on adding threads, and I will need to preserve mutable state across threads 01:52:05 (with the implementation I am thinking of so far, threads are essentially trivial, with the exception that I would need a mutex to protect the top-level name hash) 01:54:13 Do read Scheme48's scheme/rts/wind.scm, and consider following the structure in Scheme.hs -- you could adapt it very easily to use IOArrays or whatever instead of the explicit stores it uses. 01:54:41 -!- pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 248 seconds] 01:55:23 (Just change `newtype Location = Location { locationIndex :: Int }' to `newtype Location = Location { locationRef :: IORef Datum }' or something, and `newtype Command answer = ...' to `type Command answer = IO answer'.) 01:55:27 hmm... I might need to use mutexs except to *set* the top-level name hash if I implement my top-level binding array as not an IORef (IOArray Int (Value a)) but as an IORef (Array Int (IORef (Value a))) 01:56:18 (the first IORef is because I might need to resize the array) 01:57:07 the problem here is safety during array resizes - the first definition breaks if someone set!s a top-level binding at the moment the array is being copied into a larger array, but the second works if the inner IORefs are merely being rereferenced by the larger array rather than copied 01:57:39 (I like considering corner cases...) 01:58:34 Don't just consider that possibility a corner case; consider proving that the code you write implements the properties and invariants you want. 01:58:45 hiroaki [~hiroaki@p4FFDFE81.dip0.t-ipconnect.de] has joined #scheme 01:58:52 brianmwaters [41b78511@gateway/web/freenode/ip.65.183.133.17] has joined #scheme 02:01:07 unfortunately I'm not very familiar with doing formal proofs on code... 02:01:19 (haven't worked with the likes of Agda or Coq myself) 02:02:35 -!- hiroakip [~hiroaki@p4FFDD7C2.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 02:03:50 too bad protecting my top-level binding array with a mutex would probably be prohibitively expensive 02:04:08 and as reads would be certainly far more common than writes, they need to be optimized 02:04:50 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: bye!] 02:05:01 -!- alexei [~amgarchin@p4FD60EC1.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 02:05:02 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 02:05:43 oooo 02:05:45 better faster design 02:06:40 no top-level binding array, but have the top-level name hash point directly to IORefs, and copy the references to the IORefs into the lookup-global VM instructions as they are evaluated, to mean that the values can be accessed essentially instantly while still being settable 02:07:00 ooh, I would be interested in learning about formal proofs on code.. can you do this with scheme programs, or only "purely" functional languages, such as haskell? 02:07:53 zacts: you can do formal proofs about code in any language with a well-defined semantics, just some languages (and some programs in them) are harder than others. 02:08:13 By `proof', I really just mean `confidence-inspiring argument', not necessarily a machine-verifiable formal receipt for a theorem. 02:09:00 does haskell even have "well-defined semantics"? 02:09:06 Yes. 02:09:08 I prove little theorems to myself all the time whenever I read code in any language, be it Haskell or Scheme or C. 02:09:24 maybe if you limit yourself to things like "no unsafePerformIO, no unsafeCoerce, etc." 02:09:48 unfortunately people do use those in real code 02:09:52 For any language usable for practical programs, there will always be backdoors, you will always have to limit formal reasoning to subsets of the language, and/or assumptions that unsafe operations are used in "safe" ways. 02:09:59 Anything labelled `unsafe' breaks the language semantics; you then have to defer to what the real implementation will actually do. 02:10:30 But in Haskell, the set of things that _are_ unsafe is at least limited and well-understood. In many languages, there's no clear distinction between safe things and unsafe things. Things just kinda do stuff, and whatever. 02:10:35 Doesn't mean you can't prove properties of programs and then when they are violated in practice scream at the idiot who used unsafePerformIO to break your proofs. 02:12:22 you can probably prove code that you yourself written that do not have any means that control flow can escape from them into code that has not been fully considered statically, but proving higher-order functions (which inherently allow control flow to escape) is another matter... 02:12:31 There are plenty of things that are unsafe in Haskell but not really marked as such in the sense that you can't rely on the behaviour of a program that encounters these cases. 02:12:42 where then, yes, you would have to prove them with the caveat of "no unsafe stuff in called functions" 02:12:47 For example, ((x:xs) -> x) [] has this property. 02:13:00 (\(x:xs) -> x) [] 02:13:01 anything with partial functions 02:13:41 Riastradh: so when would formal verification be useful if there are so many possible backdoors? 02:13:48 and unfortunately plenty of stuff *does* use partial functions, so to use their code while proving one's own code one would have to prove that those partial functions don't evaluate to bottom 02:14:13 zacts, formal verification is useful to check your work, and apply it to a bigger program than you can fit in your head. 02:14:22 \xs map head $ filter ((>1) . length) xs is safe though 02:14:26 tabemann: proving things about higher-order functions is done all the time, by people who reason formally about programs. 02:14:48 tabemann, that doesn't mean you can't prove little theorems with the hypothesis that nobody's doing anything bogus such as unsafePerformIO. 02:15:32 so xmonad's formally verified extensions, may be formally verified, but may still crash. 02:15:39 cartleastlund: I assume they have to make assumptions like, e.g. function f won't evaluate to bottom 02:15:40 woah I thought I was in #haskell 02:15:44 Formal reasoning is often modular. You don't need to say "this function does X", you can say "this function does X if called in Y way". So your reasoning is true regardless of context, but some contexts will simply fail the condition. 02:15:51 Nisstyre-laptop: sorry 02:16:03 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: bye!] 02:16:12 zacts: don't apologize 02:16:17 Nisstyre-laptop: I'm implementing a scheme in haskell, hence the haskell discussion in #scheme 02:16:28 tabemann: yeah I know, you mentioned it yesterday 02:16:39 Nisstyre-laptop: just wasn't sure if you were there then 02:16:57 tabemann: I was the one who told you about the paper on continuations 02:16:58 tabemann: absolutely. The same way you have to assume the input to division isn't zero, and so forth. Formal reasoning involves lots of assumptions, and whoever attempts to use an argument with an assumption must prove that it applies in their particular case. 02:17:38 The discussion is really about formal arguments about code. Everything we're saying applies equally well to Scheme, Haskell, etc. 02:18:59 so does exercies 1.13 in SICP kind of lead towards this goal of formal verification? Is formal verification often done with mathematical induction in mind? 02:19:04 s/lead/lend/ 02:19:16 http://www.cs.cmu.edu/~crary/819-f09/Hoare69.pdf 02:19:22 zacts: formal reasoning about program uses induction all the time, yes, it's the bread and butter of proofs. 02:19:27 ok 02:19:46 Here's an SAT analogy for you -- induction : proofs :: recursion : programs 02:20:08 cool! :-) 02:20:11 (if the SAT were to somehow assume knowledge of functional programming and formal verification) 02:21:30 heh 02:22:20 I was chatting on #perl6 about parallel computing, and recursion. it was stated that sequential recursion doesn't fit well with parallel processing. is that true? 02:22:32 zacts: need more context 02:23:15 hm.." recursion implies sequentiality that is not desirable in 02:23:16 parallel computations" 02:23:28 "So languages that optimize for tail recursion are, as it 02:23:28 were, barking down the wrong (branch of) the tree." 02:23:36 even though it might be unreasonable for the SAT to assume that, they should at least make college freshmen majoring in CS learn Scheme and Haskell, and requiring learning how to formally verify code would be nice too 02:23:36 No, no more context is needed. That's true. It helps to have tree-like recursion/iteration, so you can pass the separate pieces of work to different places to do the work, rather than having one side do a little work and the other do most of it. 02:24:01 This is something Guy Steele has given talks about at a number of venues, for instance, as a result of his work on Fortress. 02:24:47 zacts: of course the issue with that is that one *will* have sequential computation, and as tail recursion is utterly trivial to implement provided the environment doesn't restrict it (e.g. JVM), so why *not* implement it? 02:25:06 s/tail recursion/tail call optimization 02:25:11 zacts, the same is true of languages that optimize for `for (i = 0; i < n; i++)' loops. 02:25:28 carleastlund: interesting. so couldn't you just abstract the implementation of recursion to allow for tree like structures underneath while providing the illusion of regular linear recursion? if that makes sense? 02:25:39 tail calls are much more general than for(i = 0; i < n; i++) 02:25:42 zacts: watch SPJ's talk about nested data parallelism 02:25:46 ok 02:26:42 zacts: but if people write programs in ways that imply sequential iteration (iteration in the general sense, recursive or loopish), there is no automatic way to turn them into balanced splits of work. Programs need to be written into ways that can be split up into balanced bundles of work, for parallelism to give them much advantage. 02:26:49 zacts: it's about optimizing tree like structures into flat structures that can be fairly split up to do data parallel processing 02:27:31 ah ok 02:27:48 On the other hand, once you do push work out to different places, the work done at each needs to be fast and sequential, so some part of the program needs to be optimized to parallelize, but another needs to have blindingly-fast sequential optimization, so we can't give up on the old ways, we just have to make sure they don't get in the way of the new ones. 02:28:10 WOW was that an awful run-on sentence. Pretend I paused for breath in the middle, somewhere. 02:28:16 zacts, example: lists are a sequential recursive structure, not a balanced recursive structure. If you want to compute (list (f x0) ... (f xn)), (map f (list x0 ... xn)) will take off the first element of the list and compute (f x0) as well as (map f (list x1 ... xn)), rather than splitting the list in half and doing (map f (list x0 ... x{n/2)})) and (map f (list x{n/2+1} ... xn)). 02:28:21 one should only parallelize as far as to occupy all computation units available, i.e. all cores on all nodes 02:28:36 beyond that point one might as well write one's code as being purely sequential 02:28:53 Divide-and-conquer more parallelism-friendly than element-by-element. 02:29:01 tabemann: assuming all you want is parallelism and not some combination of concurrency and parallelism 02:29:09 Nisstyre-laptop: of course 02:31:21 tabemann: I sometimes see this confusion when people complain about python's GIL. They don't know if they want concurrency or parallelism, or even that they are distinct things. 02:33:15 yeah 02:33:36 *tabemann* wasn't speaking about concurrency 02:33:52 yeah I know :P just sayin 02:35:07 I guess I don't understand why underneath a recursion can't be implemented as a tree like structure. I guess because each procedure invocation sequentially relies on another procedure to complete its computation before it can return it's value to it's parent procedure. 02:35:15 ? 02:36:13 at least with a linear recursive process. 02:36:55 zacts: with associative operations like * or + you can easily split them up 02:37:32 fold accumulates multiple values into one value, right? 02:37:42 more or less 02:37:47 based on some function that is applied to two values at a time? 02:37:58 ok, so * and + could be implemented in terms of fold right? 02:38:42 zacts: if you have something called a monoid then you can assume it's associative 02:39:11 but fold can apply to more than just monoids...at least in Scheme/Racket 02:39:45 zacts: they could be 02:40:09 zacts, to find the middle of an n-element list you have to fetch n/2 pointers sequentially. 02:41:03 If lists were structured as (cons left-half element right-half) instead of (cons first-element remaining-elements), and were automatically balanced, then you could find the middle of an n-element list with one pointer fetch. 02:41:51 ooh that is going to be interesting.... (multithreading combined with call/cc and dynamic-wind, i.e. calling call/cc in one thread and applying the resulting continuation in another....) 02:42:36 (my implementation it seems will allow one to *copy* threads that way...) 02:44:06 oh I think I see Nisstyre-laptop, so * and + can split up pairs of additions in a divide and conquer fashion, put each one on a separate parallel process, to compute in a parallel fashion. then you must combine those in some way. 02:44:57 zacts, I think you're starting to get the idea, although you seem to be assigning * and + a very active role in the process. Usually + and * are just applied to two numbers at a time; all the splitting up happens before you get to + or *. 02:45:17 do existing multithreaded scheme implementations allow you to use call/cc to copy entire threads' states into other threads? 02:45:34 zacts: yeah 02:45:45 tabemann, I would think so. 02:46:15 so I wonder how you could imlement a linear recursive process in a similar fashion? 02:46:26 zacts: say you have a list from 1 to 1000, then you can just split it up into two lists, one per core, and do the fold on both 02:46:28 Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has joined #scheme 02:46:36 then combine the results using the same operation 02:46:37 similar to how sicp mentions optimizations to make linear recursive processes into iterative ones, in the footnotes somewhere. 02:46:47 a compiler/interpreter optimization 02:47:35 but in this case turn the recursive definition into a divide and conquer algorithm underneath.. I wonder if that would be difficult.. 02:48:36 if every linear recursion can be represented iteratively, I don't know for sure if that is true, but iirc, then couldn't you express linear iteration as parallel computations? 02:49:01 then I promise not to continue this branch of the conversation further.. sorry. :-) just curious. 02:49:33 zacts: if the iterations do not have dependencies upon each other 02:52:28 ok, I think I get it now 02:53:50 zacts: think of how you would compute say, the fibonnaci sequence, or the sequence of primes in parallel 02:54:15 or something like a collatz sequence 02:55:01 yeah let's use fib for example 02:55:13 everyone's familiar with that 02:56:14 the sicp linear iterative recusrive procedure that implements fib(n). 02:56:24 how would that be implemented in a parallel fashion? 02:56:26 each number depends on the previous two 02:57:51 ah ok. so it's the linear dependencies that make this kind of recursion inefficient for parallel computations? 02:58:06 yes 02:58:09 and therefore, would be difficult if not impossible to optimize underneath 02:58:19 optimize in a parallel fashion that is 02:58:40 and hence trying to de-recursiv-ize such computations does little, as you've still got the linear dependencies 02:59:01 ok thanks for helping me to understand 02:59:17 you could compute the fibonacci sequence by taking powers of a matrix 02:59:22 and that's something that could be parallelized 02:59:23 primes you might be able to do 02:59:25 so trying to forbid optimizations of recursion is just penalizing sequential computations that need it to be efficient, by saying, "well you shouldn't be doing that in the first place!" 02:59:44 but i guess by that point you might as well use the closed form 03:00:01 ChouLin [~user@120.196.98.118] has joined #scheme 03:00:07 ok, hehe 03:00:36 tabemann: where did "forbidding optimizations of recursion" come into the conversation, did I miss something? 03:00:49 that was the original quote or whatever I think 03:01:07 carleastlund: the Perl6 person in the original quote was basically saying that tail call optimization was bad 03:01:33 in a parallel setting 03:01:50 The quote said it was barking down the wrong tree that's not the same as bad, or saying it shouldn't be done, it's just saying it's not the kind of thing that'll get the biggest results. 03:02:19 but that makes the major (and wrong) assumption that one can infinitely parallelize, when in reality you can only parallelize as far as many cores you have, and beyond that any further parallelism is just overhead 03:03:50 -!- Nisstyre-laptop is now known as Nisstyre 03:04:06 You seem to be talking about two different things whether it's good/bad to optimize tail recursion, and whether we should be writing programs with more tail recursion or with more parallelizable recursion. 03:04:34 sorry, I kind of went off on a tangent 03:05:33 As for more parallelizable recursion no, we can't infinitely parallelize, but that doesn't mean we know which recursions will be the right ones to parallelize when we write them. Often it will depend on the inputs to the function. With any kind of automated parallelism, you have to write things in a generic way, and let the runtime figure out what to do with it. If you have a good enough generic system, you 03:05:33 can get tree-like parallel recursion until it's occupied each core, then on each it can still run nice tight linear, tail-recursive loops. 03:06:24 but where should that be implemented? should it be optimized within the compiler/interpreter, or should the user of the language be concious of these issues while they are programming? 03:06:32 I'm thinking the latter more than the former.. 03:06:49 *tabemann* is thinking the latter himself 03:07:37 zacts: watch that video I mentioned 03:07:38 trying to make code that will be sequential (do to having maxed out the cores) parallelizable anyways is going to be just overhead unless there is special language support for optimizing away extra parallelism and turning into optimized sequential code 03:07:50 Nisstyre: ok I'll check it out. 03:07:54 s/turning/turning it 03:08:11 http://youtu.be/NWSZ4c9yqW8 03:08:55 s/do to/due to 03:09:47 in code where you have explicit control over threads, versus the runtime having implicit control over threads, one will have to manually consider the point at which all cores are occupied 03:11:49 zacts, tabemann: users have to be conscious while writing these things, but the compiler and runtime can both help optimize things with information users may not have. For instance, the user can't plan ahead for how busy the system will necessarily be, and generic data-processing functions need to work for both large data that must be parallelized, and small data that would be wasteful to try to split up. So 03:11:50 large-scale parallelism does require a good deal of automation, you can't just decide statically in each case that this function will run parallel and that one won't. 03:11:51 I would like to learn more about this eventually, also I wonder how the OS itself comes into play here, such as the linux kernel. does it proved an abstraction layer over some parallelization issues. I just need to educate myself on issues like this. I feel that I would then be able to contribute more to conversations like these. 03:13:49 linux just provides OS threads, which it will map to individual cores as it sees fit 03:13:54 zacts: you're the one whose questions are causing these conversations to happen in the first place. I'd say that's a rather important contribution. Bear in mind, most newbies who drop in and ask questions sadly, ask rather poorly chosen questions that go nowhere. You've done an excellent job of finding the right things to ask, and having an idea of what you know, what you don't know, and what's useful to 03:13:54 find out. 03:15:12 note that in many language runtimes, such as Haskell, one will actually have M:N threads, where M green threads are mapped to N OS threads, often with things such as forking off blocking calls into C into their own OS threads 03:15:13 -!- ffio_ [~fire@unaffiliated/security] has quit [Ping timeout: 248 seconds] 03:15:29 ok, well if I ever do stay on a random tangent, or interfere with a conversation too much, just let me know. also, you may notice that I try to lay back when other people have more important topics to talk about.. 03:15:38 bleh bad sentence, sorry 03:15:44 well bbl. got stuff to do. 03:15:48 _ffio_ [~fire@unaffiliated/security] has joined #scheme 03:16:55 (M:N threads are very useful when one has more threads of concurrency than cores to utilize, as multiple green threads mapped to a single OS thread on a single core can switch *much* faster than multiple OS threads on a single core, and typically have far less overhead, e.g. lacking their own C and kernel stacks) 03:19:53 too bad many language runtimes just use 1:1 mappings between runtime threads and OS threads... 03:23:30 ah, back for a sec. linux is amazing in that all drivers work on all architecture types, and it is ported to so many different architectures. from single core cpu to multicore cpu. It would be interesting to see how they have dealt with these kinds of issues. they are directly faced with them on a daily basis, I would think. 03:23:57 but the reason I was curious about these questions is that tabemann was working on an interpreter now, and I am learning about recursion in scheme. 03:24:05 so it seemed to provide good synergy. 03:24:14 anyway, I'm done with this topic for now. 03:24:20 If you want to figure out how Linux works, the code is out there. 03:25:16 git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 03:25:22 hehe, ok 03:25:31 -!- ChouLin [~user@120.196.98.118] has quit [Read error: Connection reset by peer] 03:26:34 the main way Linux deals with issues of multicore is by things like maintaining per-core state (while disabling kernel preemption during accesses to such state, to prevent kernel threads from being migrated between cores during accesses) 03:26:48 (Not all drivers work on all architectures, by the way. Most of the MI drivers get tested mainly on x86 (which has a relatively strong memory ordering model), and there are plenty of MD drivers, especially in the ARM world.) 03:26:51 -!- _ffio_ is now known as ffio 03:27:06 with locking when shared state has to be mutated and per-core state isn't possible 03:27:14 ah interesting, I based that on a comment by Greg Kroah Hartman. 03:28:15 even though a *lot* of the locking in the kernel is actually spinlocking, as traditional mutexes require the possibility of sleeping, which isn't possible except in process context 03:29:50 so for short accesses where the main locking is to handle simultaneous accesses from other cores, spinlocking works fine (and is much more responsive than mutexes, which require process switches when they sleep) 03:29:58 dessos [~dessos@c-174-60-176-249.hsd1.pa.comcast.net] has joined #scheme 03:30:15 wow that's way cool tabemann :-) 03:30:45 it seems contradictory for someone used to userland programming, where typically spinlocking is treated as practically verboten 03:31:08 b4283 [~b4283@111.80.24.154] has joined #scheme 03:32:02 but usually when something in userland has to wait for something, they may have to wait significantly longer, and if they are waiting for a thread on the same core, spinning is just preventing that other thread from actually releasing the lock 03:34:17 didn't someone make a space shooters game with scheme? I think I saw a youtube video.. let me find it. 03:35:56 http://www.youtube.com/watch?v=RV7ClMSOZp4 03:36:44 that's what I'm going to do 03:42:05 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 03:42:55 -!- annodomini [~lambda@wikipedia/lambda] has quit [Quit: annodomini] 03:43:00 -!- tenq|away is now known as tenq 03:59:08 Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has joined #scheme 04:15:29 bokr1 [~ed@37.200.77.170] has joined #scheme 04:17:33 -!- bokr [~ed@109.110.53.59] has quit [Ping timeout: 264 seconds] 04:27:05 -!- bokr1 [~ed@37.200.77.170] has quit [Quit: Leaving.] 04:35:10 -!- jao [~jao@pdpc/supporter/professional/jao] has quit [Ping timeout: 246 seconds] 04:47:23 gravicappa [~gravicapp@ppp91-77-165-120.pppoe.mtu-net.ru] has joined #scheme 05:04:23 -!- xilo [~xilo@107-209-248-232.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 264 seconds] 05:16:47 jerryzhou [~jerryzhou@58.245.253.218] has joined #scheme 05:25:09 -!- youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has quit [Remote host closed the connection] 05:29:18 -!- kobain [~kobian@unaffiliated/kobain] has quit [Quit: El motor por excelencia http://www.europio.org/] 05:29:21 youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has joined #scheme 05:38:25 -!- em_ [~em@user-0cev0hr.cable.mindspring.com] has quit [Quit: Reconnecting] 05:38:38 em [~em@unaffiliated/emma] has joined #scheme 05:50:49 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 245 seconds] 05:56:23 -!- karswell` [~user@87.114.19.117] has quit [Ping timeout: 240 seconds] 05:57:38 yacks [~py@180.151.36.168] has joined #scheme 06:05:41 -!- jerryzhou [~jerryzhou@58.245.253.218] has quit [Quit: Leaving] 06:14:13 -!- fridim__ [~fridim@65.93.78.88] has quit [Ping timeout: 246 seconds] 06:20:08 -!- youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has quit [Read error: Connection reset by peer] 06:31:18 -!- hiroaki [~hiroaki@p4FFDFE81.dip0.t-ipconnect.de] has quit [Quit: Ex-Chat] 06:39:50 youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has joined #scheme 06:57:43 MrFahrenheit [~RageOfTho@77.221.25.95] has joined #scheme 07:10:32 hiroakip [~hiroaki@p4FFDFE81.dip0.t-ipconnect.de] has joined #scheme 07:11:58 -!- yacks [~py@180.151.36.168] has quit [Quit: Leaving] 07:26:41 agumonkey [~agu@245.217.72.86.rev.sfr.net] has joined #scheme 07:34:09 -!- Nisstyre [~yours@oftn/member/Nisstyre] has quit [Ping timeout: 245 seconds] 07:38:11 jerryzhou [~jerryzhou@58.245.253.218] has joined #scheme 07:42:58 Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has joined #scheme 07:46:00 -!- zacts [~user@unaffiliated/zacts] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 07:46:43 jewel [~jewel@105-236-99-241.access.mtnbusiness.co.za] has joined #scheme 07:49:04 userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has joined #scheme 07:52:11 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 07:52:42 -!- Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 07:59:07 -!- carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: carleastlund] 08:04:14 Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has joined #scheme 08:06:18 -!- racycle [~racycle@75-25-129-128.lightspeed.sjcpca.sbcglobal.net] has quit [Remote host closed the connection] 08:11:19 emmp [~manolis@130.43.83.180.dsl.dyn.forthnet.gr] has joined #scheme 08:11:37 mmc1 [~michal@j212142.upc-j.chello.nl] has joined #scheme 08:20:09 YoungFrog [~youngfrog@geodiff-mac3.ulb.ac.be] has joined #scheme 08:30:58 kvda [~kvda@unaffiliated/kvda] has joined #scheme 08:33:23 -!- arubin [~arubin@99-114-192-172.lightspeed.cicril.sbcglobal.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 08:35:18 -!- trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 08:50:41 -!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...] 08:51:43 alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 08:52:42 -!- kvda [~kvda@unaffiliated/kvda] has quit [Quit: x___x] 08:54:41 -!- jerryzhou [~jerryzhou@58.245.253.218] has quit [Quit: Leaving] 09:09:55 -!- alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 09:13:04 -!- userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has quit [Remote host closed the connection] 09:29:06 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 09:32:19 Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has joined #scheme 09:35:20 Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has joined #scheme 09:36:45 wingo [~wingo@cha74-2-88-160-190-192.fbx.proxad.net] has joined #scheme 09:37:29 -!- mmc1 [~michal@j212142.upc-j.chello.nl] has quit [Ping timeout: 245 seconds] 09:39:34 -!- oleo [~oleo@xdsl-87-79-197-168.netcologne.de] has quit [Ping timeout: 245 seconds] 09:40:13 oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has joined #scheme 10:27:27 -!- hiroakip [~hiroaki@p4FFDFE81.dip0.t-ipconnect.de] has quit [Quit: Ex-Chat] 10:29:11 -!- emmp [~manolis@130.43.83.180.dsl.dyn.forthnet.gr] has quit [Quit: Leaving] 10:36:27 -!- SeySayux_ [SeySayux@libsylph/developer/seysayux] has quit [Read error: Operation timed out] 10:44:06 SeySayux [SeySayux@libsylph/developer/seysayux] has joined #scheme 10:45:27 -!- taylanub [tub@p4FD910C2.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:46:54 taylanub [tub@p4FD910C2.dip0.t-ipconnect.de] has joined #scheme 10:48:15 -!- electromancer [~electroma@cpe-198-72-207-51.socal.res.rr.com] has quit [Quit: Leaving] 10:49:20 electromancer [~electroma@cpe-198-72-207-51.socal.res.rr.com] has joined #scheme 10:57:54 pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has joined #scheme 11:02:04 -!- pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 245 seconds] 11:04:40 -!- tabemann [~travisb@adsl-69-217-164-123.dsl.milwwi.ameritech.net] has quit [Ping timeout: 276 seconds] 11:08:45 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 11:11:40 pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has joined #scheme 11:11:53 trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has joined #scheme 11:14:32 xwl [~user@182.48.101.22] has joined #scheme 11:15:04 -!- ffio [~fire@unaffiliated/security] has quit [Ping timeout: 252 seconds] 11:15:15 -!- Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 11:15:36 tabemann [~travisb@adsl-76-229-159-60.dsl.milwwi.sbcglobal.net] has joined #scheme 11:15:56 ffio_ [~fire@unaffiliated/security] has joined #scheme 11:15:59 -!- Razz|at_1ork is now known as Razz 11:30:27 -!- trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:41:35 -!- agumonkey [~agu@245.217.72.86.rev.sfr.net] has quit [Ping timeout: 264 seconds] 11:43:18 -!- tenq is now known as tenq|away 11:43:45 Hi. If I want to make pointer comparison between 2 elements of a list I should us "eq?", right ? 11:43:55 trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has joined #scheme 11:58:56 -!- Triclops256|away is now known as Triclops256 12:02:12 -!- xwl [~user@182.48.101.22] has quit [Remote host closed the connection] 12:03:32 Yes 12:04:05 -!- oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has quit [Quit: Verlassend] 12:05:18 oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has joined #scheme 12:08:03 ok, thx 12:26:02 agumonkey [~agu@245.217.72.86.rev.sfr.net] has joined #scheme 12:27:45 -!- pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 248 seconds] 12:37:21 -!- Triclops256 is now known as Triclops256|away 12:49:37 -!- dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has quit [Ping timeout: 248 seconds] 12:53:36 barryfm [~barryfm@fl-71-52-211-52.dhcp.embarqhsd.net] has joined #scheme 13:02:36 dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has joined #scheme 13:03:28 -!- barryfm [~barryfm@fl-71-52-211-52.dhcp.embarqhsd.net] has quit [Quit: Ex-Chat] 13:14:50 I don't think it's healthy to think of eq? as pointer comparison. 13:15:16 Unless you've long tied yourself to a specific implementation and know how it does things. 13:18:06 Nisstyre-laptop [~yours@oftn/member/Nisstyre] has joined #scheme 13:23:59 pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has joined #scheme 13:26:58 Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has joined #scheme 13:35:28 fantazo [~fantazo@213.129.230.10] has joined #scheme 13:51:43 -!- Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 14:10:39 -!- Nisstyre-laptop is now known as Nisstyre 14:31:44 -!- acedia [~rage@unaffiliated/ffs] has quit [Ping timeout: 256 seconds] 14:37:50 xilo [~xilo@107-209-248-232.lightspeed.austtx.sbcglobal.net] has joined #scheme 14:38:36 -!- jaaso [~jaaso@109.175.27.246] has quit [Read error: Connection reset by peer] 14:40:15 mmc1 [~michal@j212142.upc-j.chello.nl] has joined #scheme 14:41:40 racycle [~racycle@75-25-129-128.lightspeed.sjcpca.sbcglobal.net] has joined #scheme 14:44:29 -!- Kabaka [~Kabaka@botters/kabaka] has quit [Ping timeout: 240 seconds] 14:50:10 Kabaka [~Kabaka@botters/kabaka] has joined #scheme 15:04:33 -!- clog [~nef@bespin.org] has quit [Ping timeout: 248 seconds] 15:06:02 -!- dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has quit [Ping timeout: 252 seconds] 15:07:39 Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has joined #scheme 15:12:25 carleastlund [~carleastl@209-6-40-238.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 15:19:56 dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has joined #scheme 15:24:03 tupi [~user@189.60.6.98] has joined #scheme 15:24:13 -!- fantazo [~fantazo@213.129.230.10] has quit [Read error: Operation timed out] 15:27:51 gabnet [~gabnet@ACaen-652-1-204-52.w83-115.abo.wanadoo.fr] has joined #scheme 15:28:08 Kruppe [~user@CPE602ad0938e9a-CM602ad0938e97.cpe.net.cable.rogers.com] has joined #scheme 15:32:35 clog [~nef@bespin.org] has joined #scheme 15:37:47 -!- Cromulent [~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 15:45:55 jao [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has joined #scheme 15:45:58 -!- jao [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has quit [Changing host] 15:45:58 jao [~jao@pdpc/supporter/professional/jao] has joined #scheme 15:54:35 -!- trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has quit [Quit: Leaving] 16:02:52 -!- jao [~jao@pdpc/supporter/professional/jao] has quit [Ping timeout: 251 seconds] 16:05:52 -!- pumpkin360 [~main@ays114.neoplus.adsl.tpnet.pl] has quit [Quit: WeeChat 0.4.1] 16:09:15 -!- bjz [~brendanza@125.253.99.68] has quit [Quit: Leaving...] 16:10:23 -!- b4283 [~b4283@111.80.24.154] has quit [Remote host closed the connection] 16:13:19 -!- taylanub [tub@p4FD910C2.dip0.t-ipconnect.de] has quit [Disconnected by services] 16:13:48 taylanub [tub@p4FD9128A.dip0.t-ipconnect.de] has joined #scheme 16:13:57 karswell [~user@80.229.124.80] has joined #scheme 16:20:42 userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has joined #scheme 16:32:16 hiroakip [~hiroaki@ip-178-202-216-178.unitymediagroup.de] has joined #scheme 16:34:13 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 16:38:09 fridim__ [~fridim@65.93.78.88] has joined #scheme 16:41:56 arubin [~arubin@99-114-192-172.lightspeed.cicril.sbcglobal.net] has joined #scheme 16:43:37 -!- gabnet [~gabnet@ACaen-652-1-204-52.w83-115.abo.wanadoo.fr] has quit [Quit: Quitte] 16:45:42 alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 16:46:39 -!- hiroakip [~hiroaki@ip-178-202-216-178.unitymediagroup.de] has quit [Ping timeout: 245 seconds] 16:50:51 Okasu [~1@unaffiliated/okasu] has joined #scheme 16:54:39 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: computer sleeping] 16:55:36 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 16:55:57 -!- ffio_ [~fire@unaffiliated/security] has quit [Ping timeout: 264 seconds] 16:57:37 -!- oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has quit [Quit: Verlassend] 17:01:04 hiroakip [~hiroaki@ip-178-202-216-178.unitymediagroup.de] has joined #scheme 17:19:10 -!- agumonkey [~agu@245.217.72.86.rev.sfr.net] has quit [Remote host closed the connection] 17:22:45 oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has joined #scheme 17:26:37 agumonkey [~agu@245.217.72.86.rev.sfr.net] has joined #scheme 17:30:29 ffio [~fire@unaffiliated/security] has joined #scheme 17:38:02 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: bye!] 17:38:08 -!- Kruppe [~user@CPE602ad0938e9a-CM602ad0938e97.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 17:38:34 -!- youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has quit [Ping timeout: 276 seconds] 17:44:11 -!- jrapdx [~jra@c-98-246-145-216.hsd1.or.comcast.net] has quit [Remote host closed the connection] 17:45:52 jrapdx [~jra@c-98-246-145-216.hsd1.or.comcast.net] has joined #scheme 17:45:57 emmp [~manolis@188.4.47.193.dsl.dyn.forthnet.gr] has joined #scheme 17:49:05 -!- alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 17:49:17 alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 17:55:36 alexei_ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 17:55:38 -!- alexei [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 17:56:35 -!- tupi [~user@189.60.6.98] has quit [Remote host closed the connection] 18:03:11 -!- hiroakip [~hiroaki@ip-178-202-216-178.unitymediagroup.de] has quit [Ping timeout: 264 seconds] 18:07:04 -!- gravicappa [~gravicapp@ppp91-77-165-120.pppoe.mtu-net.ru] has quit [Ping timeout: 245 seconds] 18:13:58 -!- Guest12453 [dan64@dannyadam.com] has quit [Quit: ZNC - http://znc.in] 18:14:35 dan64 [dan64@dannyadam.com] has joined #scheme 18:19:56 -!- agumonkey [~agu@245.217.72.86.rev.sfr.net] has quit [Ping timeout: 260 seconds] 18:22:09 yacks [~py@180.151.36.168] has joined #scheme 18:23:33 Giomancer [~gio@107.201.206.230] has joined #scheme 18:27:36 -!- emmp [~manolis@188.4.47.193.dsl.dyn.forthnet.gr] has quit [Quit: Leaving] 18:28:37 -!- alexei_ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 18:32:39 alexei_ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 18:35:24 hiroakip [~hiroaki@ip-178-202-216-178.unitymediagroup.de] has joined #scheme 18:38:26 -!- jrapdx [~jra@c-98-246-145-216.hsd1.or.comcast.net] has quit [*.net *.split] 18:38:26 -!- arubin [~arubin@99-114-192-172.lightspeed.cicril.sbcglobal.net] has quit [*.net *.split] 18:38:26 -!- userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has quit [*.net *.split] 18:38:26 -!- tabemann [~travisb@adsl-76-229-159-60.dsl.milwwi.sbcglobal.net] has quit [*.net *.split] 18:38:27 -!- sethalves [~user@headache.hungry.com] has quit [*.net *.split] 18:38:27 -!- inarru [~edwardgeo@nest.insectsarerubbish.org] has quit [*.net *.split] 18:38:27 -!- marienz [~marienz@freenode/staff/marienz] has quit [*.net *.split] 18:38:27 -!- copec [copec@schrodbox.unaen.org] has quit [*.net *.split] 18:38:28 -!- nmeum [~nmeum@2a00:12c0:1015:123::] has quit [*.net *.split] 18:38:28 -!- eMBee [~eMBee@foresight/developer/pike/programmer] has quit [*.net *.split] 18:38:28 -!- ggherdov [uid11402@gateway/web/irccloud.com/x-krqrhkkvgfqiuopk] has quit [*.net *.split] 18:38:28 -!- weinholt [weinholt@debian/emeritus/weinholt] has quit [*.net *.split] 18:38:28 -!- wrl [~wrl@don.gs] has quit [*.net *.split] 18:38:28 -!- asumu [~at@2001:470:b:b7:1e6f:65ff:fe23:c3d4] has quit [*.net *.split] 18:38:29 -!- shardz [~samantha@ilo.staticfree.info] has quit [*.net *.split] 18:38:29 -!- ec_ [~elliottca@ell.io] has quit [*.net *.split] 18:38:29 -!- zbigniew [~zb@3e8.org] has quit [*.net *.split] 18:40:07 nitefli [sage@reaver.cat.pdx.edu] has joined #scheme 18:40:16 -!- nitefli19 [sage@reaver.cat.pdx.edu] has quit [Read error: No buffer space available] 18:42:02 -!- pothos [~pothos@114-25-203-141.dynamic.hinet.net] has quit [Read error: Connection reset by peer] 18:42:15 pothos [~pothos@114-25-203-141.dynamic.hinet.net] has joined #scheme 18:42:28 -!- gjord [~gjord@ool-18babf32.dyn.optonline.net] has quit [Read error: Connection reset by peer] 18:47:26 shardz [~samantha@ilo.staticfree.info] has joined #scheme 18:47:31 inarru [~edwardgeo@nest.insectsarerubbish.org] has joined #scheme 18:47:48 copec [copec@schrodbox.unaen.org] has joined #scheme 18:47:54 wrl [~wrl@don.gs] has joined #scheme 18:47:55 sethalves [~user@headache.hungry.com] has joined #scheme 18:48:16 weinholt [weinholt@2002:4f88:e0b::] has joined #scheme 18:48:18 -!- weinholt [weinholt@2002:4f88:e0b::] has quit [Changing host] 18:48:18 weinholt [weinholt@debian/emeritus/weinholt] has joined #scheme 18:48:19 userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has joined #scheme 18:48:35 asumu [~at@2001:470:b:b7:1e6f:65ff:fe23:c3d4] has joined #scheme 18:48:43 arubin [~arubin@99-114-192-172.lightspeed.cicril.sbcglobal.net] has joined #scheme 18:48:53 travisb [~travisb@adsl-76-229-159-60.dsl.milwwi.sbcglobal.net] has joined #scheme 18:49:51 jrapdx [~jra@c-98-246-145-216.hsd1.or.comcast.net] has joined #scheme 18:50:04 -!- rudybot___ [~luser@ec2-54-215-10-197.us-west-1.compute.amazonaws.com] has quit [Ping timeout: 275 seconds] 18:50:22 rudybot___ [~luser@ec2-54-215-10-197.us-west-1.compute.amazonaws.com] has joined #scheme 18:50:41 ggherdov [uid11402@gateway/web/irccloud.com/x-qgcihmdapfxmiefd] has joined #scheme 18:51:18 -!- Okasu [~1@unaffiliated/okasu] has quit [Write error: Broken pipe] 18:51:29 -!- arrdem [~arrdem@dhcp-53-132.ece.utexas.edu] has quit [Ping timeout: 257 seconds] 18:51:36 arrdem [~arrdem@dhcp-53-132.ece.utexas.edu] has joined #scheme 18:52:01 -!- mario-goulart [~user@email.parenteses.org] has quit [Ping timeout: 273 seconds] 18:52:13 eMBee [~eMBee@foresight/developer/pike/programmer] has joined #scheme 18:53:26 nmeum [~nmeum@2a00:12c0:1015:123::] has joined #scheme 18:53:33 ELLIOTTCABLE [~elliottca@ell.io] has joined #scheme 18:53:58 marienz [~marienz@freenode/staff/marienz] has joined #scheme 18:57:05 -!- oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has quit [Remote host closed the connection] 18:59:00 -!- userzxcvasdf [~neutral_a@c656847C1.dhcp.as2116.net] has quit [Remote host closed the connection] 19:04:35 mario-goulart [~user@email.parenteses.org] has joined #scheme 19:10:41 gravicappa [~gravicapp@ppp91-77-178-38.pppoe.mtu-net.ru] has joined #scheme 19:12:11 waxysubs` [hope7@world.peace.net] has joined #scheme 19:12:25 agumonkey [~agu@245.217.72.86.rev.sfr.net] has joined #scheme 19:13:05 wrl_ [~wrl@don.gs] has joined #scheme 19:13:47 dsmith_ [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has joined #scheme 19:14:19 fgudin_ [fgudin@odin.sdf-eu.org] has joined #scheme 19:14:30 -!- wrl [~wrl@don.gs] has quit [Disconnected by services] 19:14:41 -!- wrl_ is now known as wrl 19:15:41 antoszka_ [~antoszka@unaffiliated/antoszka] has joined #scheme 19:16:07 ffio_ [~fire@unaffiliated/security] has joined #scheme 19:16:10 -!- pygospa [~Pygosceli@kiel-4d067ac2.pool.mediaWays.net] has quit [Disconnected by services] 19:16:18 TheRealPygo [~Pygosceli@kiel-4d067ac2.pool.mediaWays.net] has joined #scheme 19:17:27 -!- joneshf-laptop_ [~joneshf@c-98-208-36-36.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 19:17:31 -!- taylanub [tub@p4FD9128A.dip0.t-ipconnect.de] has quit [Disconnected by services] 19:17:33 joneshf-laptop [~joneshf@c-98-208-36-36.hsd1.ca.comcast.net] has joined #scheme 19:17:42 emma [~em@unaffiliated/emma] has joined #scheme 19:17:46 -!- ffio [~fire@unaffiliated/security] has quit [Ping timeout: 251 seconds] 19:17:57 taylanub [tub@p4FD9128A.dip0.t-ipconnect.de] has joined #scheme 19:20:09 -!- dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has quit [*.net *.split] 19:20:09 -!- xilo [~xilo@107-209-248-232.lightspeed.austtx.sbcglobal.net] has quit [*.net *.split] 19:20:09 -!- em [~em@unaffiliated/emma] has quit [*.net *.split] 19:20:09 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [*.net *.split] 19:20:09 -!- waxysubs [hope6@world.peace.net] has quit [*.net *.split] 19:20:09 -!- fgudin [fgudin@odin.sdf-eu.org] has quit [*.net *.split] 19:20:10 -!- gluegadget [~amir@unaffiliated/gluegadget] has quit [*.net *.split] 19:20:10 -!- adiii [~adityavit@c-50-156-85-49.hsd1.ca.comcast.net] has quit [*.net *.split] 19:20:10 -!- duncanm [~duncan@a-chinaman.com] has quit [*.net *.split] 19:20:10 -!- z0d [~z0d@unaffiliated/z0d] has quit [*.net *.split] 19:20:10 -!- vnz [~vnz@unaffiliated/vnz] has quit [*.net *.split] 19:20:14 vnz_ [~vnz@unaffiliated/vnz] has joined #scheme 19:20:26 -!- vnz_ is now known as vnz 19:20:54 gluegadget [~amir@li346-83.members.linode.com] has joined #scheme 19:20:54 -!- gluegadget [~amir@li346-83.members.linode.com] has quit [Changing host] 19:20:54 gluegadget [~amir@unaffiliated/gluegadget] has joined #scheme 19:21:48 duncanm [~duncan@a-chinaman.com] has joined #scheme 19:21:49 la la la 19:22:05 -!- Riastradh [~riastradh@fsf/member/riastradh] has quit [Remote host closed the connection] 19:22:12 xilo [~xilo@107.209.248.232] has joined #scheme 19:22:54 zeroish [~zeroish@135.207.174.50] has joined #scheme 19:23:01 adiii [~adityavit@c-50-156-85-49.hsd1.ca.comcast.net] has joined #scheme 19:27:23 Riastradh [~riastradh@fsf/member/riastradh] has joined #scheme 19:27:48 oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has joined #scheme 19:28:04 -!- jewel [~jewel@105-236-99-241.access.mtnbusiness.co.za] has quit [Ping timeout: 260 seconds] 19:42:14 alexei___ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 19:43:11 jjjj2_ [~jon@c-50-131-54-186.hsd1.ca.comcast.net] has joined #scheme 19:46:03 agumonke1 [~agu@245.217.72.86.rev.sfr.net] has joined #scheme 19:46:11 Saeren_ [~saeren@mail.skepsi.net] has joined #scheme 19:46:26 simon___ [simon@relay.pronoia.dk] has joined #scheme 19:46:45 fadein_ [~Erik@c-67-161-246-186.hsd1.ut.comcast.net] has joined #scheme 19:47:11 wrl_ [~wrl@don.gs] has joined #scheme 19:47:31 kryptiskt_ [~kryptiskt@213.101.209.229] has joined #scheme 19:48:02 epsylon [~epsylon@2a00:dcc0:eda:98:216:3cff:fea1:ce4] has joined #scheme 19:48:04 C-Keen_ [cckeen@pestilenz.org] has joined #scheme 19:48:54 -!- microcode [~microcode@bas1-toronto04-1176392373.dsl.bell.ca] has quit [Excess Flood] 19:48:59 rapacity1 [~rapacity@li128-246.members.linode.com] has joined #scheme 19:50:37 shardz_ [~samantha@ilo.staticfree.info] has joined #scheme 19:50:37 microcode [~microcode@bas1-toronto04-1176392373.dsl.bell.ca] has joined #scheme 19:52:21 -!- Triclops256|away [~Triclops2@Powder/Developer/Triclops200] has quit [Ping timeout: 264 seconds] 19:52:46 tuubow [~adityavit@c-50-156-85-49.hsd1.ca.comcast.net] has joined #scheme 19:52:49 -!- C-Keen [cckeen@pestilenz.org] has quit [Ping timeout: 264 seconds] 19:52:51 -!- duncanm [~duncan@a-chinaman.com] has quit [Ping timeout: 264 seconds] 19:52:52 -!- alexei_ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 19:52:55 -!- jrslepak [~jrslepak@punchout.ccs.neu.edu] has quit [Ping timeout: 264 seconds] 19:52:55 -!- certainty [~david@www1.d-coded.de] has quit [Ping timeout: 264 seconds] 19:52:59 -!- fadein [~Erik@c-67-161-246-186.hsd1.ut.comcast.net] has quit [Ping timeout: 264 seconds] 19:53:01 -!- sethalves [~user@headache.hungry.com] has quit [Ping timeout: 264 seconds] 19:53:02 -!- epsylon` [~epsylon@abbaye.thele.me] has quit [Ping timeout: 264 seconds] 19:53:02 -!- cmatei [~cmatei@78.96.108.142] has quit [Ping timeout: 264 seconds] 19:53:11 -!- adiii [~adityavit@c-50-156-85-49.hsd1.ca.comcast.net] has quit [*.net *.split] 19:53:12 -!- TheRealPygo [~Pygosceli@kiel-4d067ac2.pool.mediaWays.net] has quit [*.net *.split] 19:53:13 -!- wrl [~wrl@don.gs] has quit [*.net *.split] 19:53:13 -!- ffio_ [~fire@unaffiliated/security] has quit [*.net *.split] 19:53:13 -!- agumonkey [~agu@245.217.72.86.rev.sfr.net] has quit [*.net *.split] 19:53:15 -!- shardz [~samantha@ilo.staticfree.info] has quit [*.net *.split] 19:53:17 -!- SeySayux [SeySayux@libsylph/developer/seysayux] has quit [*.net *.split] 19:53:21 -!- dpk [~r00t@obquire.infologie.co] has quit [*.net *.split] 19:53:21 -!- klutometis [~klutometi@pdpc/supporter/professional/klutometis] has quit [*.net *.split] 19:53:22 -!- gabot [~eli@racket/bot/gabot] has quit [*.net *.split] 19:53:23 -!- ft [efftee@oldshell.chaostreff-dortmund.de] has quit [*.net *.split] 19:53:23 -!- simon [simon@relay.pronoia.dk] has quit [*.net *.split] 19:53:25 -!- tenq|away [~tenq@199.19.116.207] has quit [*.net *.split] 19:53:25 -!- rapacity [~rapacity@unaffiliated/rapacity] has quit [*.net *.split] 19:53:26 -!- kryptiskt [~kryptiskt@213.101.209.229] has quit [*.net *.split] 19:53:27 -!- Saeren [~saeren@mail.skepsi.net] has quit [*.net *.split] 19:53:53 cmatei [~cmatei@78.96.108.142] has joined #scheme 19:54:39 -!- C-Keen_ is now known as C-Keen 19:57:38 antoszka [~antoszka@unaffiliated/antoszka] has joined #scheme 19:57:51 -!- ohama [ohama@cicolina.org] has quit [Disconnected by services] 19:58:19 ohama [ohama@cicolina.org] has joined #scheme 19:58:42 jrslepak [~jrslepak@punchout.ccs.neu.edu] has joined #scheme 19:59:07 -!- microcode [~microcode@bas1-toronto04-1176392373.dsl.bell.ca] has quit [Changing host] 19:59:07 microcode [~microcode@unaffiliated/microcolonel] has joined #scheme 19:59:10 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 19:59:37 -!- brianloveswords [~brianlove@li124-154.members.linode.com] has quit [Excess Flood] 19:59:38 -!- arrdem [~arrdem@dhcp-53-132.ece.utexas.edu] has quit [Write error: Broken pipe] 19:59:38 -!- antoszka_ [~antoszka@unaffiliated/antoszka] has quit [Write error: Broken pipe] 19:59:40 -!- muep [twingo@otitsun.oulu.fi] has quit [Write error: Broken pipe] 19:59:41 -!- DerGuteMoritz [~syn@saturn.lileth.net] has quit [Remote host closed the connection] 19:59:44 ffio_ [~fire@unaffiliated/security] has joined #scheme 19:59:57 -!- fadein_ [~Erik@c-67-161-246-186.hsd1.ut.comcast.net] has quit [Write error: Connection reset by peer] 20:00:05 gabot [~eli@racket/bot/gabot] has joined #scheme 20:02:34 SeySayux [SeySayux@libsylph/developer/seysayux] has joined #scheme 20:03:11 amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 20:03:21 -!- alexei___ [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Write error: Broken pipe] 20:05:12 brianloveswords [~brianlove@li124-154.members.linode.com] has joined #scheme 20:06:41 fadein [~Erik@67.161.246.186] has joined #scheme 20:06:58 certainty [~david@www1.d-coded.de] has joined #scheme 20:08:03 -!- waxysubs` is now known as waxysubs 20:08:35 jaimef [jaimef@dns.mauthesis.com] has joined #scheme 20:11:18 ft [efftee@195.160.168.8] has joined #scheme 20:11:20 arrdem [~arrdem@dhcp-53-132.ece.utexas.edu] has joined #scheme 20:12:29 dpk [~r00t@obquire.infologie.co] has joined #scheme 20:12:29 Triclops256 [~Triclops2@199.19.116.207] has joined #scheme 20:12:29 tenq|away [~tenq@199.19.116.207] has joined #scheme 20:12:43 -!- Triclops256 [~Triclops2@199.19.116.207] has quit [Changing host] 20:12:43 Triclops256 [~Triclops2@Powder/Developer/Triclops200] has joined #scheme 20:13:21 klutometis [~klutometi@klutometis.wikitex.org] has joined #scheme 20:13:21 *rudybot___* bows deeply before his master, inventor of incubot 20:13:43 DerGuteMoritz [~syn@saturn.lileth.net] has joined #scheme 20:13:44 -!- klutometis is now known as Guest89565 20:15:40 -!- jjjj2_ [~jon@c-50-131-54-186.hsd1.ca.comcast.net] has quit [Quit: Ex-Chat] 20:18:21 Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has joined #scheme 20:19:02 muep [twingo@otitsun.oulu.fi] has joined #scheme 20:19:08 duncanm [~duncan@a-chinaman.com] has joined #scheme 20:19:08 la la la 20:20:27 youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has joined #scheme 20:20:43 DUM de dum 20:22:41 pygospa [~Pygosceli@kiel-4d067ac2.pool.mediaWays.net] has joined #scheme 20:42:47 -!- amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 20:45:26 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 20:45:51 -!- weie_ [~eie@softbank221078042071.bbtec.net] has quit [Read error: Connection reset by peer] 20:46:25 weie [~eie@softbank221078042071.bbtec.net] has joined #scheme 20:48:38 amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 20:55:09 -!- travisb [~travisb@adsl-76-229-159-60.dsl.milwwi.sbcglobal.net] has quit [Read error: Connection reset by peer] 21:00:47 zacts [~zacts@unaffiliated/zacts] has joined #scheme 21:04:22 -!- gravicappa [~gravicapp@ppp91-77-178-38.pppoe.mtu-net.ru] has quit [Remote host closed the connection] 21:05:16 -!- youlysses [~user@75-132-28-10.dhcp.stls.mo.charter.com] has quit [Ping timeout: 276 seconds] 21:08:20 travisb [~travisb@adsl-76-199-167-1.dsl.milwwi.sbcglobal.net] has joined #scheme 21:09:19 trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has joined #scheme 21:16:36 -!- kryptiskt_ [~kryptiskt@213.101.209.229] has quit [Quit: Lämnar] 21:26:48 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #scheme 21:28:42 -!- trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has quit [Quit: Leaving] 21:28:43 -!- Ripp__ [~Ripp___@c-76-21-7-143.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 21:31:36 trusktr [~trusktr@c-76-114-26-222.hsd1.ca.comcast.net] has joined #scheme 21:33:36 -!- wingo [~wingo@cha74-2-88-160-190-192.fbx.proxad.net] has quit [Ping timeout: 260 seconds] 21:33:38 -!- dsmith_ is now known as dsmith 21:40:33 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 21:42:56 bjz [~brendanza@125.253.99.68] has joined #scheme 21:43:08 jaimef [jaimef@dns.mauthesis.com] has joined #scheme 21:43:23 -!- oleo [~oleo@xdsl-78-35-130-4.netcologne.de] has quit [Ping timeout: 264 seconds] 21:43:57 oleo [~oleo@xdsl-78-35-188-52.netcologne.de] has joined #scheme 21:51:33 -!- amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 21:52:21 -!- travisb [~travisb@adsl-76-199-167-1.dsl.milwwi.sbcglobal.net] has quit [Ping timeout: 264 seconds] 21:54:25 travisb [~travisb@adsl-76-199-158-108.dsl.milwwi.sbcglobal.net] has joined #scheme 21:54:43 -!- travisb is now known as tabemann 21:55:03 amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has joined #scheme 21:55:06 kobain [~kobian@unaffiliated/kobain] has joined #scheme 22:01:30 -!- dessos [~dessos@c-174-60-176-249.hsd1.pa.comcast.net] has quit [Quit: leaving] 22:02:45 dessos [~dessos@c-174-60-176-249.hsd1.pa.comcast.net] has joined #scheme 22:11:58 -!- joast [~rick@76.178.135.192] has quit [Quit: Leaving.] 22:18:43 -!- tabemann [~travisb@adsl-76-199-158-108.dsl.milwwi.sbcglobal.net] has quit [Ping timeout: 276 seconds] 22:21:57 -!- amgarchIn9 [~amgarchin@p4FD62728.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 22:26:41 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 22:26:59 tabemann [~travisb@adsl-76-228-197-7.dsl.milwwi.sbcglobal.net] has joined #scheme 22:27:06 pchrist [~spirit@gentoo/developer/pchrist] has joined #scheme 22:33:01 -!- tabemann [~travisb@adsl-76-228-197-7.dsl.milwwi.sbcglobal.net] has quit [Ping timeout: 276 seconds] 22:33:47 travisb [~travisb@adsl-76-199-161-116.dsl.milwwi.sbcglobal.net] has joined #scheme 22:33:53 -!- travisb is now known as tabemann 22:36:28 joast [~rick@76.178.135.192] has joined #scheme 22:38:30 -!- tabemann [~travisb@adsl-76-199-161-116.dsl.milwwi.sbcglobal.net] has quit [Ping timeout: 264 seconds] 22:40:02 tabemann [~travisb@adsl-76-199-165-191.dsl.milwwi.sbcglobal.net] has joined #scheme 22:46:37 jerryzhou [~jerryzhou@58.245.253.218] has joined #scheme 22:51:58 letrec semantics question 22:52:41 if you specify a recursive expression that is *not* broken by a lambda with letrec, what should happen? 23:00:51 What does that mean? 23:05:56 jao [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has joined #scheme 23:05:59 -!- jao [~jao@55.Red-79-148-157.dynamicIP.rima-tde.net] has quit [Changing host] 23:06:00 jao [~jao@pdpc/supporter/professional/jao] has joined #scheme 23:09:08 I mean, 23:09:09 given: 23:09:12 (define foo 23:09:12 (lambda () 23:09:13 (letrec ((x (+ y 1)) 23:09:13 (y 0)) 23:09:13 x))) 23:09:29 whoops my indentation is weird 23:09:44 (it didn't like my tab it seems) 23:10:11 but anyways, what should happen 23:10:14 or better yet 23:10:35 define foo 23:10:36 (lambda () 23:10:36 (letrec ((x (+ y 1)) 23:10:36 (y x)) 23:10:36 x))) 23:10:44 s/define/(define 23:11:21 That's an error. 23:11:42 that's what I was expecting, but I just wanted to make sure 23:12:37 Riastradh, you sure? Why? 23:12:57 In the R5RS, anyway. In the R{6,7}RS, it's kosher. 23:13:07 Oh, sorry. 23:13:10 It's an error in all three. 23:13:30 If it were (letrec ((y 0) (x (+ y 1))) ...) it would be an error in the R5RS but kosher in the R{6,7}RS. 23:14:19 that was another thing I was wondering about, whether (in R5RS) letrec behaved like let* if there actually were no recursion 23:14:22 Oh, no, wait, I see. One way or another in R5RS it'll be (+ 1 ). 23:14:50 -!- tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has quit [Quit: computer sleeping] 23:15:53 tabemann, were you reading R5RS when you asked the question? Because the spec seems pretty specific. 23:17:53 -!- mmc1 [~michal@j212142.upc-j.chello.nl] has quit [Ping timeout: 248 seconds] 23:18:05 Hmm. The final "restriction" on letrec in R5RS seems poorly worded and undecidable. 23:18:16 I wasn't looking at R5RS at the moment 23:19:18 tabemann, okay, I feel a little bit saner then. :) As for let*, I don't think it behaves that way -- the way I read R5RS, none of the bindings are available until _all_ of them have been evaluated. 23:19:48 let* seems to just bind them in order 23:20:25 See also: letrec* 23:20:32 Yeah, (let* ([x1 e1]  [xn en]) b) is just (let ([x1 e1])  (let ([xn en]) b)  ) 23:22:40 annodomini [~lambda@wikipedia/lambda] has joined #scheme 23:31:00 tcsc [~tcsc@c-76-127-240-20.hsd1.ct.comcast.net] has joined #scheme 23:32:21 -!- tabemann [~travisb@adsl-76-199-165-191.dsl.milwwi.sbcglobal.net] has quit [Ping timeout: 248 seconds] 23:32:54 -!- agumonke1 [~agu@245.217.72.86.rev.sfr.net] has quit [Ping timeout: 245 seconds] 23:37:18 tabemann [~travisb@adsl-69-210-128-151.dsl.milwwi.ameritech.net] has joined #scheme 23:47:51 hmm... what are semantics of values when not called inside call-with-values? 23:53:02 tabemann: any expression can produce any number of values; usually, they produce 1. What happens when they produce multiple depends on the context -- most contexts "expect" a specific number of values, and raise an exception if they get the wrong number. 23:55:48 rudybot___: (+ (values 1 2)) 23:55:49 carleastlund: your racket/load sandbox is ready 23:55:49 carleastlund: error: result arity mismatch; expected number of values not received expected: 1 received: 2 values...: 1 2 23:56:03 rudybot___: (+ (begin (values 1 2) 9)) 23:56:04 carleastlund: ; Value: 9 23:56:24 rudybot___: (let ([x (values 1 2)]) 7) 23:56:24 carleastlund: error: result arity mismatch; expected number of values not received expected: 1 received: 2 values...: 1 2 23:56:36 and so forth 23:58:51 -!- tabemann [~travisb@adsl-69-210-128-151.dsl.milwwi.ameritech.net] has quit [Read error: Operation timed out]