00:02 (join) Gwyth`
00:05 (quit) Gwyth: Ping timeout: 265 seconds
00:22 (quit) Spewns: Quit: Leaving.
00:41 (quit) mario-goulart: *.net *.split
00:41 (quit) j3parker: *.net *.split
00:42 (join) mario-go`
00:44 (join) j3parker
01:01 (quit) jay-mccarthy: Read error: Connection reset by peer
01:04 (join) jay-mccarthy
01:34 (quit) jonrafkind: Ping timeout: 246 seconds
01:41 (join) paul_stansifer_
01:54 (join) masm
01:59 (quit) paul_stansifer_: Ping timeout: 252 seconds
03:28 (nick) Gwyth` -> Gwyth
04:25 (join) pdelgallego
04:40 (join) incandenza
05:07 (part) incandenza: "Killed buffer"
05:07 (quit) pdelgallego: Ping timeout: 260 seconds
05:10 (join) pdelgallego
05:23 (join) incandenza
07:03 (quit) pdelgallego: Ping timeout: 240 seconds
07:32 (quit) mario-go`: Quit: ERC Version 5.3 (IRC client for Emacs)
07:33 (join) mario-goulart
07:44 (join) pdelgallego
09:01 (join) Byron
09:22 (join) Spewns
09:27 (quit) aeouidhtns: Ping timeout: 265 seconds
10:46 (join) rpr`
11:45 (join) aeouidhtns
11:53 (join) Gwyth`
11:53 (quit) Gwyth: Ping timeout: 258 seconds
11:54 (nick) Gwyth` -> Gwyth
12:20 (quit) incandenza: Ping timeout: 245 seconds
12:44 (quit) chandler: Ping timeout: 248 seconds
13:06 (join) chandler
13:07 (quit) klutometis: Read error: Operation timed out
13:07 (nick) chandler -> Guest58841
13:07 (join) klutometis
13:08 (nick) klutometis -> Guest62936
13:10 (quit) Guest58841: Changing host
13:10 (join) Guest58841
13:10 (nick) Guest58841 -> chandler
13:24 (join) faure
13:58 (join) incandenza
14:36 (join) samth
14:53 (quit) samth: Ping timeout: 265 seconds
15:33 (quit) rpr`: Remote host closed the connection
15:50 (join) bmarkmann
15:52 (quit) bmarkmann: Quit: leaving
16:14 (join) Gwyth`
16:17 (quit) Gwyth: Ping timeout: 260 seconds
16:50 (quit) aeouidhtns: Quit: WeeChat 0.3.2
16:51 (join) shkk
16:53 shkk: All, which operator should we use to compare values in Scheme? example. to find if a value exists in a list ?
17:03 (quit) Gwyth`: Quit: ERC Version 5.3 (IRC client for Emacs)
17:03 (join) Gwyth
17:44 (quit) Spewns: Quit: Leaving.
18:07 (join) Gwyth`
18:10 (quit) Gwyth: Ping timeout: 258 seconds
18:16 (quit) masm: Quit: Leaving.
18:18 (quit) Gwyth`: Ping timeout: 276 seconds
18:19 (part) Byron
18:20 (join) b-man_
18:38 (join) jonrafkind
19:50 offby1: depends :)
19:50 offby1: rudybot: doc memv
19:50 rudybot: offby1: http://docs.plt-scheme.org/reference/pairs.html#(def._((quote._~23~25kernel)._memv))
19:50 offby1: rudybot: doc member
19:50 rudybot: offby1: http://docs.plt-scheme.org/reference/pairs.html#(def._((quote._~23~25kernel)._member))
19:50 offby1: rudybot: doc memq
19:50 rudybot: offby1: http://docs.plt-scheme.org/reference/pairs.html#(def._((quote._~23~25kernel)._memq))
19:51 offby1: shkk: "comparing values" and "finding if a value exists in a list" are related, but different.
19:52 shkk: Yes, but I want to compare values and I was not if one can use "=" for all datatypes of a list
19:52 offby1: depends on the data type.
19:52 offby1: It has nothing to do with whether the items are in a list or not, though.
19:53 shkk: Well, is eq? an operator that would work for any datatype comparison ?
19:53 offby1: = only works with numbers
19:53 offby1: well, it won't ever raise an error.
19:53 offby1: But it might not always give the answer you expect, either
19:53 offby1: rudybot: eval (equal? (list 3) (list 3))
19:53 rudybot: offby1: ; Value: #t
19:53 offby1: rudybot: eval (eq? (list 3) (list 3))
19:53 rudybot: offby1: ; Value: #f
19:53 offby1: you need to understand why those two differ.
20:03 (join) Gwyth
20:04 (quit) b-man_: Remote host closed the connection
20:08 (quit) pdelgallego: Ping timeout: 276 seconds
20:10 (join) evhan
21:00 (join) Byron
21:01 (part) Byron
21:06 (join) evhan_
21:09 (quit) evhan: Ping timeout: 240 seconds
21:13 Lajla: shkk, eq? tests of two objects are in the same place in memory.
21:13 Lajla: So it's very cheap, but not always the result you want
21:14 Lajla: As in, two lists could be structurally the same, but reside in difference places of memory.
21:14 Lajla: eqv? tests 'aequivalence', what that is is vague and depends on the implementation, but guaranteed to be a superset of eq?
21:14 Lajla: And equal? tests structural aequivalence, and is quite expensive.
21:14 shkk: I dont want to compare 2 lists. But an element of a list with a value i.e. to check if a value exists in a list
21:14 shkk: so what should be the best operator to use ?
21:15 Lajla: As in, (eqv? 'x 'x) is guaranteed to succeed, because they're symbols
21:15 Lajla: shkk, it depends on your value
21:15 Lajla: The type of your value
21:15 Lajla: As in (eqv? "hai" "hai") is not guaranteed to succeed, because a string is not an atom
21:15 shkk: Oohh  .. so there is no single operator that would work for ints, chars and string ?
21:16 Lajla: shkk, well, there is, equal? is the top of the mountain
21:16 Lajla: it works for all
21:16 Lajla: But it's very expensive, and usually you don't need it.
21:16 shkk: So how do I test if a value resides in a list ? For any above type of list
21:17 Lajla: Basically (member "Hello" '("hai" "car" "foo" "hello" "smurf")) returns ("hello" "smurf")
21:17 Lajla: If "hello" was not in the list, it would return #f
21:20 shkk: Hmmm okie. That should be a drawback then
21:24 Lajla: shkk, why?
21:24 Lajla: I mean, like in php or perl, == is equal?
21:24 Lajla: In C or Java it's more like eq?
21:24 Lajla: Scheme gives you choice.
21:25 shkk: I mean, I want to write a code that would test if a value exists in a list, for any type. But I cannot do that right
21:25 Lajla: shkk, you can, you use equal?
21:25 chandler: eli: Out of curiosity, who runs this joint?
21:25 Lajla: Or actually, member
21:25 Lajla: member uses equal? as the comparison, memv uses eqv? and memq uses eq?
21:26 Lajla: Though, I don't like that, so I basically rewrote this so that member takes a comparison function, and I added membal to replace the old member.
21:27 shkk: Hmmm okiee .. thanks Lajla
21:27 chandler: shkk: You might find http://www.nhplace.com/kent/PS/EQUAL.html interesting. You can read Common Lisp EQ as Racket `eq?', EQL as `eqv?', and EQUAL as `equal?'. EQUALP doesn't have a direct equivalent.
21:28 Lajla: shkk, but, if you know your list is not going to contain lists or strings et cetera or vectors itself, better use memv
21:28 chandler: shkk: Oh, and I'd suggest not taking advice from Lajla. He's as often wrong as he is right.
21:28 (join) Spewns
21:28 Lajla: shkk, you have to take into account that chandler is not a very good reader when he makes that comment.
21:28 Lajla: He often seems to take things from my comment that I never sought to imply
21:29 chandler: "As in (eqv? "hai" "hai") is not guaranteed to succeed, because a string is not an atom"
21:29 shkk: chandler: Hahahahahhaa ... Well its too late for me to consider that advice
21:29 chandler: It isn't guaranteed to succeed, but your explanation is wrong on two counts.
21:29 Lajla: chandler, oh, do explain
21:29 chandler: Strings are atoms, and the reason it isn't guaranteed to succed has nothing to do with atomicity.
21:29 Lajla: chandler, strings are atoms?
21:30 Lajla: http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/Lisp-Atoms.html
21:30 (notice) rudybot: http://tinyurl.com/379wpux
21:30 Lajla: This source begs to differ
21:30 Lajla: saying that atoms are indeed what the word suggests, not made up of any identifiable smaller parts
21:30 chandler: Well, I should say first that there's no strict definition of `atom'.
21:31 chandler: If you ask Racket, it'll tell you that a string is an atom, but to quote the documentation: "does not actually imply an atomic value".
21:31 Lajla: Ahh, oky
21:31 Lajla: I guess I then use the historical term
21:31 Lajla: shkk, let me be more clear
21:32 chandler: But the question of (eqv? "foo" "foo") isn't about atomicity. It's more interesting to consider why (eqv? 2 2) and (eqv? 'x 'x) is guaranteed to work.
21:32 shkk: Oohh okiee
21:32 Lajla: chandler, well, some sources would say that is the definition of 'atom' more or less.
21:32 Lajla: Depends on whose atom you speak of.
21:32 Lajla: But originally, the idea of atom was immutable basically
21:32 Lajla: Lists and vectors and strings were mutable, and therefore not atoms
21:33 (part) incandenza: "ERC Version 5.3 (IRC client for Emacs)"
21:33 chandler: Ah, but lists aren't mutable in Racket - that doesn't change the issue with regard to (eqv? '(1 2) '(1 2)) .
21:33 chandler: Literal strings aren't mutable either.
21:34 chandler: But: literal strings aren't guaranteed to be interned by the reader, and that's what separates (eqv? "foo" "foo") from (eqv? 'foo 'foo) .
21:35 chandler: An implementation of Scheme *could* guarantee that all literals that are `equal?' are coalesced, in which case it could guarantee the behavior of these examples.
21:35 Lajla: chandler, yes, I know that, but that was basically the original definition of atom where this was considered pretty much aequivalent to mutable.
21:36 Lajla: As I said, it is not bound to succeed, I know that (eqv? "hai" "hai") may succeed in a comforming scheme implementation
21:36 Lajla: chandler, anyway, you're effectively arguiing a definition, asin 'My definition of the concept atom is the only true definition thereof'
21:37 chandler: And it may fail, but the reason is only that the reader is not required to coalesce those constants.
21:37 Lajla: What I said was the same
21:37 Lajla: Yeah, I know that.
21:37 chandler: If it was about atomicity, (let ((x "foo")) (eqv? x x)) would also be undefined - but it isn't; it will always return #t.
21:38 Lajla: I never said that
21:38 Lajla: I said that in the case o (eqv? "hai" "hai") it wasn't bound to succeed.
21:38 chandler: I'll cede the point about the definition of atom, though. It's well defined in Common Lisp, but I keep forgetting it isn't in Scheme.
21:38 Lajla: I never said it wasn't in that case?
21:39 chandler: Right, but the point is that `eqv
21:39 chandler: Gr.
21:39 Lajla: I also said that eqv? is guaranteed to encompass eq?, and that eq? tests for same location in memory.
21:39 chandler: `eqv?' isn't distinguishing atoms from non-atoms. The behavior of that example only pertains to the behavior of the reader.
21:39 Lajla: So of course, this implies that (eqv? x x) in your example succeeds
21:40 Lajla: chandler, and I never said it destinghuishes them, I said in that perticular example it wasn't bound to succed because strings aren't atoms (in my definition thereof)
21:40 Lajla: Which goes by the literal definition of the word 'indivisable'
21:40 eli: chandler: Which joint are you referring to?
21:40 chandler: So your definition of "atom" is "things that the reader is guaranteed to coalesce to the same location in the store if they are `equal?'"?
21:41 chandler: eli: #racket
21:41 Lajla: chandler, no, you reverse the arrow of implication
21:41 Lajla: I said that (eqv? "foo" "foo") is not guaranteed to succeed as a string is not an atom
21:42 Lajla: That does not imply that it's guaranteed to succeed if a string is an atom, of course
21:42 eli: chandler: IIRC, samth started it.  Is there any problem?
21:42 Lajla: OR that being guaranteed to succeed <-> atom
21:42 chandler: If the reader was required to coalesce `equal?' string constants, would strings be atoms?
21:42 Lajla: Simply said, that's not guaranteed to succeed because two strings made up from the same characters are not guaranteed to be in the same place in memory.
21:42 Lajla: chandler, no.
21:43 Lajla: But the reverse is quite true
21:43 chandler: Because strings are not atoms, the reader isn't required to coalesce them?
21:43 Lajla: If strings were atoms, then a reader would surely coalesce them
21:43 Lajla: chandler, you reverse the arrow of implication
21:43 chandler: No, I'm afraid I haven't.
21:43 Lajla: All I say is 'If strings were atoms, then a reader would coalesce them'
21:44 chandler: We can't derive that (eqv? "foo" "foo") is undefined from that statement alone.
21:45 Lajla: Sure I can, I said 'because it's not an atom', if it were an atom, then it would be in the same place in memory, if it's in the same place in memory, then eqv? is guaranteed to succeed.
21:46 chandler: That's backwards. You've started from the premise that strings are not atoms and derived that they're not atoms. But that doesn't tell us anything about whether the reader is guaranteed to coalesce literal non-atoms.
21:47 Lajla: I haven't derived  that they are not atoms, I have derived that eqv? is not guaranteed to succeed on two literal strings
21:47 Lajla: Which it would if strings were atoms, in my sense of the word, the historical sense of lisp 1.5
21:47 Lajla: But the term is dated, graned
21:48 Lajla: I said it wasn't guaranteed to succeed because strings are not atoms, surely you'd give that if they were atoms in my definition of the concept, it would be guaranteed to succeed?
21:48 shkk: Why do I feel that the community comes alive after I ask a question ! :)
21:48 Lajla: shkk, oh, this is just chandler and I really.
21:48 eli: chandler: ?
21:48 Lajla: He thinks I talk crackpot, I think he misreads what I intend to say over some terminology.
21:48 shkk: hahahahahahaha
21:49 Lajla: shkk, though, to be fair, I'm not the best speaker, I apparently have an 'unusual' way to phrase things
21:50 jonrafkind: do you have terrets?
21:50 jonrafkind: tourette*
21:51 Lajla: jonrafkind, no, not really. I just have a very poor appreciation of the value of words and keep assuming that if I say beforehand 'alright, for the sake of this debate, cow is used to mean 'convertable car on red wheels', that people have no troubles adjusting to that and read that meaning every time I use the word 'cow', but apparently not. =)
21:52 jonrafkind: 10101 is "the", 10100 is "a", with me so far? ok, 10110 is ...
21:53 Lajla: jonrafkind, well, I'm fine with that, but keep in mind that 'the' and 'a' are function words.
21:53 Lajla: And as such, they have no meaning when they stand on their own
21:54 Lajla: Like, if I say 'a' on its own, you can't relaly get an image to that.
21:54 chandler: Lajla: As I said, I think you've derived that they aren't atoms from the premise that they aren't atoms, but it's still not possible to determine what (eqv? "foo" "foo") means from that premise alone.
21:54 jonrafkind: so you are happy to redefine english on the fly and expect people to remember your definition
21:55 Lajla: chandler, I haven't derived that they are atoms, I'm just pointing out that because they are atoms, as in, it's possible for them to reside in two different places of memory when they satisfy equal? eqv? is not guaranteed to succeed on them.
21:55 Lajla: jonrafkind, yeah, like I said, poor appreciation of the value of words.
21:55 jonrafkind: *cough* and programming *cough*
21:55 chandler: Lajla: This being demonstrated by the fact that the standard forbids compliant programs from mutating string literals precisely to allow implementations to coalesce them, or to treat them as atoms by your definition.
21:55 Lajla: As in, I don't believe words have any objective meaning as in, you can say 'your definition is wrong', they are placeholders effectively.
21:56 Lajla: chandler, well, then I rephrase as in 'since strings aren't guranteed to be atoms ...'
21:56 Lajla: Though, in the original sense 'atom' and 'guaranteed to be atom' was essentially the same as there was only one implementation, of course.
21:57 Lajla: But I agree that the term is perhaps nowadays vague and dated.
21:57 Lajla: Anyway, you get what I meant.
21:57 chandler: I guess. :-)
21:57 Lajla: I meant to say that if strings were guaranteed to be in the same location of memory, then (eqv? "string" "string") would succeed.
21:59 chandler: That's true. Unfortunately, the Scheme standard needlessly complicates these discussions.
21:59 chandler: It would be nice if that *was* guaranteed.
21:59 chandler: Similarly, it would be nice if (eq? 2 2) was guaranteed to be #t.
21:59 Lajla: chandler, hmm, I guess it depends if you want to make ti easy on implementors or programmers.
22:00 Lajla: I agree.
22:00 Lajla: My own lisp solves this quite simple, eqv? is guaranteed to be true if both objects as 'simple' and the same and guaranteed to be false for any compound data, equal? also takes compound with it.
22:00 chandler: Similarly, it'd be nice if (eq? x x) was always #t.
22:01 Lajla: chandler, in what case isn't it?
22:01 chandler: It might not be if x is a number or character.
22:01 Lajla: Really?
22:02 Lajla: I was kind of assuming that x then pointed to the same place in memory as x though
22:02 chandler: Ah, but it isn't that easy. :-)
22:02 Lajla: chandler, do you know of an implementation where it may be #f?
22:03 chandler: No, but the standard allows it.
22:03 chandler: There might be one out there that I don't know of.
22:04 Lajla: chandler: http://lavica.fesb.hr/cgi-bin/info2html?(r5rs)Equivalence%20predicates
22:05 Lajla: THis seems to imply though that in the case of (eq? x x) it's result is mandated as true
22:05 Lajla: As in (let ((p (lambda (x) x))) (eq? p p)) is demanded to be #t
22:05 Lajla: If it goes for lambda, I guess then it should surely go for chars and procedures
22:05 chandler: No; there's an example in the `eq?' section that demonstrates where it fails.
22:06 chandler: (let ((n (+ 2 3))) (eq? n n)) ==> unspecified
22:06 chandler: The same applies to characters.
22:06 Lajla: Ah yes, I hand't noticed that one
22:06 chandler: This is one of those warts on this "jewel-like" (cough) language.
22:07 Lajla: So what it basically does there is allowing for a call-by-name like strategy I guess
22:07 Lajla: STrangely it does require the #t in the case of the lambda
22:08 chandler: I'm not sure what this has to do with call-by-name.
22:10 Lajla: Well, that the implementation can basically rewrite that to (eq? (+ 2 3) (+ 2 3))
22:11 Lajla: Ah lot of these quirky rules do seem to exist to make it easier for implementors and give them more choice though
22:11 chandler: Not really. It certainly can't rewrite (let ((n (foo 2 3))) (eq? n n)) into (eq? (foo 2 3) (foo 2 3)) .
22:12 Lajla: And I guess that's a godo thing, just bad for portability, so maybe there should be like a naming for r5rs:12:31:3 to specify exactly what form of r5rs an implementation conforms to which could be written at the top of a source code, another implementation could flag if it was incompatible
22:12 Lajla: chandler, of course, but you can with the +
22:12 chandler: Right, but why would you?
22:13 Lajla: I don't know, why on earth would you have it in two places o memory to begin with?
22:13 chandler: I think the intent is that implementations which use a strange number representation - fixnums consed on the heap, for instance - don't have to do anything intelligent in `eq?'.
22:13 Lajla: I guess they found a reason to explicitly allow it
22:14 Lajla: But eq? does what it does really, it tests for sameness in memory mostly and it should be used only for that purpose.
22:14 chandler: Personally, I don't think there is a reason to allow this at all. The efficiency benefit is marginal, and the side effect is that `eqv?' is used almost everywhere anyway.
22:14 (quit) shkk: 
22:14 Lajla: I agree.
22:15 Lajla: But it's hard bound to agree with all parts of a language.
22:15 chandler: Anyway, back to coding.
23:37 (quit) Spewns: Quit: Leaving.
23:54 evhan_: i read on the mailing list that the gui package is getting a redesign
23:54 evhan_: im wondering, is the syntax planned to change much with the switch?
23:55 evhan_: or will it mostly be plumbing?
23:56 jonrafkind: i think its mostly plumbing
23:56 jonrafkind: by syntax, do you mean the API? or do you mean using standard scheme notation
23:56 evhan_: the API, yes
23:57 jonrafkind: i dont know specifics, but I would guess that the API would try to be backwards compatible to some extent, as well as adding new functions
23:57 jonrafkind: I think the code to the new gui is online somewhere if you want it
23:57 jonrafkind: did you find the link from matthew's email?
23:59 evhan_: not from him directly, but from an email talking about the changes he was making
23:59 jonrafkind: in one of his emails he linked to where you can find the code
23:59 evhan_: looks like the changes are on github... ill check it out there