00:00:26 I'm thinking of a system in which the files are hardware ports and responsiveness is essential. 00:01:39 -!- Nightwolf [~Nightwolf@clientssh1.rbg.informatik.tu-darmstadt.de] has left #scheme 00:01:40 That only really matters for output ports, and we have flush-output-port for that. 00:02:50 How so? For example, suppose the system needs to monitor a physical variable like temperature and react whenever it changes. You can't do that if there is a 512-byte buffer between the port and your program. 00:03:20 s/port/temperature input port/ 00:03:57 You read data from the input port. If there's data still in the buffer, that's data you haven't read yet - you need to get through that no matter what. 00:04:15 If there isn't data in the buffer, it will refill. 00:04:19 Where's the problem? 00:04:44 I/O implementations don't require the whole buffer to be filled. 00:04:47 Input buffering normally stalls your program until the buffer is full. 00:05:08 No it doesn't. 00:11:16 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 00:12:21 *jcowan* thinks about that. 00:14:59 Axioplase [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has joined #scheme 00:15:06 soveran [~soveran@190.245.30.40] has joined #scheme 00:17:25 I suppose my mental model is cooked-mode terminals, where it does not matter if your I/O is buffered or unbuffered, you still don't get anything until the line is complete. 00:18:04 But I see that that's wrong: read() on other devices may return whatever bytes are available. 00:18:21 or not wrong, but insufficiently general. 00:22:42 I am writing a response to arcfide's email. 00:22:49 -!- DT`` [~Feeock@net-93-149-47-66.cust.dsl.teletu.it] has quit [Quit: DT``] 00:22:51 foof: What about the problem of non-string filenames? 00:23:03 I am just getting started out with scheme. I'm on linux - which scheme implementation would you recommend? 00:23:35 I like racket 00:23:51 *rudybot* does too, surprisingly enough 00:26:24 jcowan: We have the same problem with our without file-specs. I would suggest just allowing blobs in addition to strings (as a WG2 extension). 00:26:52 DT`` [~Feeock@net-93-149-47-66.cust.dsl.teletu.it] has joined #scheme 00:27:40 DrDuck [~duck@adsl-98-81-129-72.hsv.bellsouth.net] has joined #scheme 00:28:07 -!- soveran [~soveran@190.245.30.40] has quit [Remote host closed the connection] 00:29:08 mads-: if you are on a gnome system, you may already have guile installed 00:29:23 albeit an old one 00:31:46 foof: Okay. 00:32:20 I am sold on removing p-lists from WG1 I/O, but I think it's too late to do so in this ballot. 00:33:04 I will file a ticket to do so for ballot 4. 00:34:12 ijp, would it make any difference that it is old? 00:35:03 The current Guile is 2.x, whereas the packaged Guile is still 1.x 00:35:15 There's a lot of difference. 00:35:39 mads-: yes, the 2 series has a lot of new features 00:36:05 but for learning 1.x is probably fine 00:36:26 I'm just learning by playing around with the little schemer. 00:36:48 It's already on the ballot as PortsShinn, and p-lists were only written in tentatively - they never won the vote. 00:36:53 mads-: then it's more than plenty 00:37:08 ijp, awesome. Thanks :) 00:48:35 -!- mads- [~mads@pdpc/supporter/active/mads-] has quit [Quit: Leaving] 00:56:56 PortsShinn is about binary I/O, not about textual I/O. In fact, textual I/O as a whole has never been ballotted. 01:07:41 But if it passes, I think removing p-lists will pass too, so I filed ticket #226 to do so. 01:08:51 -!- DrDuck [~duck@adsl-98-81-129-72.hsv.bellsouth.net] has quit [Ping timeout: 252 seconds] 01:10:32 foof: On module factorization: I think your positions are that you strongly want (a) core I/O out of the base (b) case-lambda out of the base and weakly want (c) a consolidated I/O module and (d) multiple values out of the base. Is that a fair summary? 01:21:04 -!- bugQ [~bug@c-71-195-207-34.hsd1.ut.comcast.net] has quit [Ping timeout: 250 seconds] 01:29:42 ivartj_ [~ivartj@ti0031a380-0522.bb.online.no] has joined #scheme 01:29:53 -!- ivartj [~ivartj@ti0031a380-0522.bb.online.no] has quit [Ping timeout: 258 seconds] 01:30:31 djcb``` [~user@a88-114-88-233.elisa-laajakaista.fi] has joined #scheme 01:32:11 -!- djcb`` [~user@a88-114-88-233.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 01:36:55 bugQ [~bug@c-71-195-207-34.hsd1.ut.comcast.net] has joined #scheme 01:41:49 jcowan: swap (a) and (d) there :) 01:42:33 And the intention of PortsShinn is that we remove the file specs - was that not obvious? 01:42:53 parolang [~parolang@c-64-246-121-114.oregonrd-wifi-1261.amplex.net] has joined #scheme 01:55:48 No, all it says is that file-specs aren't used in open-binary-*-file procedures. 01:55:57 (I checked all versions.) 01:57:48 Hmmm... looks ambiguous to me. The rationale is clearly talking about using file-specs in general. 01:58:00 I'll have to check with what the others who voted think. 01:58:22 s/think/thought when they voted 02:00:19 aidalgol [~user@118.148.249.148] has joined #scheme 02:01:07 dnolen [~davidnole@184.152.69.75] has joined #scheme 02:05:08 -!- bugQ [~bug@c-71-195-207-34.hsd1.ut.comcast.net] has quit [Ping timeout: 252 seconds] 02:10:15 -!- aidalgol [~user@118.148.249.148] has quit [Quit: Moving...] 02:10:50 -!- tupi [~david@189.60.162.202] has quit [Quit: Leaving] 02:10:59 bugQ [~bug@c-71-195-207-34.hsd1.ut.comcast.net] has joined #scheme 02:13:19 Ah, my introductory mail said "I feel less strongly about not using file-spec lists, but this seems cleaner to me." 02:14:22 foof: I propose the following compromise: you get your (scheme io) module with (scheme io base), (scheme io read), and (scheme io write), and you get (scheme case-lambda). Multiple values stay in the base. 02:17:51 From my point of view, that minimizes the amount of irritating extra bureaucracy. 02:19:25 copumpkin [~pumpkin@user-12hcrs5.cable.mindspring.com] has joined #scheme 02:19:25 -!- copumpkin [~pumpkin@user-12hcrs5.cable.mindspring.com] has quit [Changing host] 02:19:25 copumpkin [~pumpkin@unaffiliated/pumpkingod] has joined #scheme 02:20:57 -!- copumpkin [~pumpkin@unaffiliated/pumpkingod] has quit [Client Quit] 02:22:07 ffs [~garland@unaffiliated/ffs] has joined #scheme 02:23:28 -!- Textmode [~boneidle@adsl-syd-2-23.ozonline.com.au] has quit [Ping timeout: 250 seconds] 02:29:55 copumpkin [~pumpkin@unaffiliated/pumpkingod] has joined #scheme 02:30:49 Penten [~user@114.255.149.182] has joined #scheme 02:34:40 -!- MrFahrenheit [~RageOfTho@users-146-61.vinet.ba] has quit [Ping timeout: 258 seconds] 02:43:06 -!- ijp [~user@host109-153-24-247.range109-153.btcentralplus.com] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 02:49:10 -!- copumpkin [~pumpkin@unaffiliated/pumpkingod] has quit [Quit: Computer has gone to sleep.] 02:59:42 -!- Axioplase [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has quit [Quit: bbl] 03:03:28 Axioplase [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has joined #scheme 03:03:57 -!- Axioplase [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has quit [Client Quit] 03:07:34 Axioplase [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has joined #scheme 03:08:43 copumpkin [~pumpkin@user-12hcrs5.cable.mindspring.com] has joined #scheme 03:08:43 -!- copumpkin [~pumpkin@user-12hcrs5.cable.mindspring.com] has quit [Changing host] 03:08:43 copumpkin [~pumpkin@unaffiliated/pumpkingod] has joined #scheme 03:11:17 -!- dnolen [~davidnole@184.152.69.75] has quit [Quit: dnolen] 03:19:36 DrDuck [~duck@adsl-98-81-129-72.hsv.bellsouth.net] has joined #scheme 03:29:25 jcowan: I'd rather go your way on I/O and have MV in a module. Historically it's been a strong point of contention among Schemers, and R5RS does not actually provide any procedures which return MV. 03:35:40 Is there any evidence that that dispute is anything but dead, other than your own feelings about MV? 03:36:11 MV? 03:36:13 In addition, R4RS didn't have MV, and the only procedures added by R5RS were the eval/repl group. 03:36:16 elly: Multiple values 03:36:23 ahh 03:36:58 So it's hardly a surprise that R5 doesn't have any MV-returning procedures (other than `values` itself) 03:37:12 Is there a way of writing a compose function in R5RS? 03:37:43 parolang: Certainly. 03:38:04 So you can just (define h (compose h f))? 03:38:17 err, (define h (compose f g)) 03:38:23 IEEE Scheme doesn't have MV either, and I assure you I'm not the only holdout :) 03:38:39 IEEE = R4RS, very nearly. 03:38:53 I've never used MV in anger myself. 03:39:11 parolang: I'm not saying that compose is predefined, but it is very easy to define. 03:39:25 genuine question, what's wrong with multiple values? 03:40:10 Like call/cc, they force you to see Scheme as it is, rather than the useful oversimplification that says Scheme is about function definitions. 03:41:23 -!- copumpkin [~pumpkin@unaffiliated/pumpkingod] has quit [Quit: Computer has gone to sleep.] 03:41:24 jcowan: Okay, was just wondering. We were talking about this in another channel, and they were saying that this was more verbose/fugly than in haskell. I guess I'm new to both, so I was wondering what was fugly about it. 03:41:25 If you don't use either feature, or use them only in very sterotyped ways, then you can see Scheme evaluation as invoking functions which return a value. 03:41:34 -!- MichaelRaskin [~MichaelRa@195.91.224.225] has left #scheme 03:42:21 Well, Haskell has ordinary algebraic notation, which is somewhat more compact than Scheme's prefix-parenthesized notation. Which is more fugly is an aesthetic question. 03:43:29 Structurally, the definition of composition is the same in both languages: (define (compose f g) (lambda x (f (apply g x)))) 03:43:45 Now that definition only works if f and g do not return multiple values! 03:44:09 -!- zeroish [~zeroish@135.207.174.50] has quit [Ping timeout: 255 seconds] 03:44:09 jcowan, oh. I've always thought that Scheme is about continuations, instead. 03:44:09 heh, tieing into the larger discussion, clever :) 03:45:07 DT``: Just so. Multiple values make sense when you view Scheme procedures not as returning but as passing results to the continuation. Scheme-with-MV is allowed to pass more than one result, that's all. 03:45:39 So without MV, you have call-return semantics, whereas with MV you have invoke-invoke semantics. 03:46:51 parolang: In addition, all Haskell functions accept only one argument, with the effect of multiple arguments provided by currying. That means you don't have to use apply to pass g an arbitrary number of arguments; you can wlg say (lambda (x) (f (g x))) 03:49:02 jcowan, right, but segregating MV in a module wouldn't help: call/cc is still there, with its escape procedures. But then, I'm no expert, that's just my opinion. 03:49:14 *jcowan* nods. 03:50:08 I'm not sure why foof wants to put it in a module anyway, except to stigmatize it. He often uses the phrase "relegate X to a module"; "relegate" in this sense means "send or confine to an inferior position." 03:52:36 Indeed, one view of MV is that it removes an arbitrary restriction (that continuations, unlike functions, can only have one argument), which is supposed to be what Scheme is about. 03:54:04 MV are useful too, I use them every day when I have to return, well, multiple values. Lists and pairs are for lists and pairs. 03:55:22 In Chibi (by foof), MVs are implemented as lists, which is defensible for what Chibi is meant for. 03:56:33 MVs will still be implemented as lists in Chibi when it's a highly optimizing compiler. 03:57:07 well, that's one way to implement them. 03:57:07 cataska [~cataska@210.64.6.233] has joined #scheme 04:01:45 MVs are also not supported in the most optimizing (but largely impractical) Scheme compiler, Stalin. 04:02:29 isn't Stalin R4RS? 04:02:34 yes 04:03:46 My theory is that the only reason the mythical Sufficiently Smart Compiler has not been written is because modern compilers are cluttered with special cases for handling MV and case-lambda and such, so optimization passes are prohibitively difficult. 04:06:52 that could be said for full continuations as well. I can see how MVs can make an implementation more complex, though, but case-lambda? 04:07:04 -!- tauntaun [~Crumpet@ool-44c711b3.dyn.optonline.net] has quit [Quit: Ex-Chat] 04:08:21 DT``: the compilers that handle case-lambda efficiently do so by adding a new node type to the AST 04:11:19 Of course, my theory could be wrong, but I'd like to have a go at it before embracing MV fully :) 04:12:09 but you don't need some esoteric stack arrangement/MV return method/calling convention like with continuations/MV/continuations-using-CPS with case-lambda. 04:13:24 I might be wrong, however, I've never wrote a full Scheme implementation. 04:14:28 I'm talking about very high-level AST->AST rewriting optimizations. The more AST node types you have, the more complicated this becomes. 04:14:53 if you use cps you don't even need any special handling for multiple values 04:15:19 and many optimiations you can do also apply for them automagically 04:15:40 -!- jao [~user@pdpc/supporter/professional/jao] has quit [Ping timeout: 252 seconds] 04:15:41 Yes, in my mind case-lambda is the worse culprit. 04:16:04 foof, true, but you also can implement case-lambda with the rest argument. 04:16:36 aoh, then you'd have the esoteric calling convetion. (I like CPS, though) 04:16:46 DT``: The people that argue case-lambda is fast specifically don't do that. 04:16:50 *convention 04:17:56 nowhereman [~pierre@AStrasbourg-551-1-91-149.w81-49.abo.wanadoo.fr] has joined #scheme 04:18:36 And if you use CPS, you have your work cut out for you making loops register/stack based when possible. 04:18:44 -!- nowhere_man [~pierre@AStrasbourg-551-1-101-227.w90-13.abo.wanadoo.fr] has quit [Ping timeout: 250 seconds] 04:20:03 foof, the people that argue case-lambda is fast will probably happily add the new AST node. 04:22:41 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Ping timeout: 240 seconds] 04:26:35 zardoz- [~mickey@76.73.16.26] has joined #scheme 04:27:59 -!- homie [~levgue@xdsl-78-35-132-149.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 04:31:29 if one wanted to implement a balanced binary tree would you use a list or a struct to represent the node? 04:35:27 zardoz-, depends if you want to treat it as a list too. I'd probably use a struct. 04:35:35 The simplest point about case-lambda is that when you have a call to a known function that is written using case-lambda, you can inline just the appropriate branch. Inlining is *the* most effective optimization, so this is a win. 04:38:05 Jafet [~Jafet@unaffiliated/jafet] has joined #scheme 04:38:39 -!- bugQ [~bug@c-71-195-207-34.hsd1.ut.comcast.net] has quit [Read error: Operation timed out] 04:40:02 soveran [~soveran@186.19.214.247] has joined #scheme 04:43:17 i guess the sufficiently smart compiler (tm) approach would be to handle the inlining via partial evaluation 04:44:49 or one could have a separate compiler pass that checks known calls and applies information about length of the arguemnt list 04:47:09 the good thing would be that there is again one less ast node to handle everywhere, and the same optimization might occasionally help also other code 04:54:00 -!- Axioplase is now known as Axioplase_ 04:58:43 -!- dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has quit [Ping timeout: 244 seconds] 05:09:43 Chibi's rest handling optimization is more general than case-lambda. 05:11:34 cky: Racket's keywords are very much first class, at least under any conceivable definition of "first class" that I know about. 05:12:12 gravicappa [~gravicapp@ppp91-77-163-6.pppoe.mtu-net.ru] has joined #scheme 05:23:12 MichaelRaskin [~MichaelRa@195.178.216.22] has joined #scheme 05:25:28 -!- Riastradh [~riastradh@fsf/member/riastradh] has quit [Remote host closed the connection] 05:26:07 Riastradh [~riastradh@fsf/member/riastradh] has joined #scheme 05:29:55 -!- leppie [~lolcow@196-210-194-43.dynamic.isadsl.co.za] has quit [Read error: Connection reset by peer] 05:41:06 realitygrill [~realitygr@184-195-188-80.pools.spcsdns.net] has joined #scheme 05:52:21 dsmith [~dsmith@cpe-184-56-129-232.neo.res.rr.com] has joined #scheme 06:00:42 -!- djcb``` [~user@a88-114-88-233.elisa-laajakaista.fi] has quit [Remote host closed the connection] 06:09:24 dnolen [~davidnole@184.152.69.75] has joined #scheme 06:11:01 -!- jcowan [~John@p-74-209-24-147.dsl1.rtr.chat.fpma.frpt.net] has quit [Quit: Leaving] 06:13:37 -!- bgs100 [~ian@unaffiliated/bgs100] has quit [Quit: meh!]