"Stephen C. Gilardi" writes:
> I see that issue 79 against Clojure requesting this change is still
> open. If auto-wrapping of readers is no longer a change you'd like to
> see, would you please either withdraw it (if you as the originator
> have that capability) or add a comment to it requestin
On Feb 12, 2009, at 11:00 PM, Phil Hagelberg wrote:
Yikes. I hadn't thought of that--I was only using read in cases
where I
wanted to get a single object from the reader.
Taking things off the reader and then pushing them back on seems a
little odd to me--isn't there a way to just "peek" at
"Stephen C. Gilardi" writes:
> Now I apply the patch and use the convenience it offers:
>
> user=> (def a (java.io.StringReader. "123[145]"))
> #'user/a
> user=> (read a)
> 123
> user=> (read a)
> 145
>
> The "[" on the input stream was lost so the second obje
On Feb 12, 2009, at 3:39 PM, Phil Hagelberg wrote:
I'm no Java IO expert, but it sounds like a BufferedReader is the
right
thing in the majority of cases. I think having "read" wrap its
stream in
a PushbackReader where necessary is a much better, non-intrusive
solution, and my implementatio
Mark Fredrickson writes:
> While (read) taking an argument seems valid, I think you can do what
> you want in the short term using binding:
read actually already takes an argument, it just (without my patch)
requires it to be a PushbackReader.
> IIRC, duck-streams has a (with-reader ...) form
Stuart Sierra writes:
> I could change "duck-streams/reader" to return a PushbackReader
> instead of a BufferedReader. Unfortunately, "readLine" is defined in
> BufferedReader but NOT in PushbackReader. We need "readLine" for
> "clojure.core/line-seq". So we can't have it both ways. Blame Ja
Rich Hickey writes:
> Yes. Issue/patch welcome.
Great; issue and patch attachment are here:
http://code.google.com/p/clojure/issues/detail?id=79&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary
I haven't written much Java, but the implementation seems pretty
straightforward.
On Feb 12, 12:53 pm, Phil Hagelberg wrote:
> I'd expect to be able to do (read (reader my-file)), but this isn't OK
> because read needs a java.io.PushbackReader. It seems vaguely wrong
> somehow to have a function called "reader" return something that cannot
> be "read" from.
I could change "du
While (read) taking an argument seems valid, I think you can do what
you want in the short term using binding:
(binding [*in* my-reader]
(print (read)))
It has been my general observation that vars + binding in Clojure fill
the niche that optional arguments fill in other languages. While it
ma
Phil Hagelberg writes:
> I've got a problem where I have a reader (it's a java.io.BufferedReader
> that came from duck-streams, if that matters at all) and I want to call
> "read" on it.
I should mention that I know *how* to do this:
(read (java.io.PushbackReader. (reader file)))
I just thi
On Feb 12, 2009, at 12:53 PM, Phil Hagelberg wrote:
>
>
> I've got a problem where I have a reader (it's a
> java.io.BufferedReader
> that came from duck-streams, if that matters at all) and I want to
> call
> "read" on it.
>
> I'd expect to be able to do (read (reader my-file)), but this is
I've got a problem where I have a reader (it's a java.io.BufferedReader
that came from duck-streams, if that matters at all) and I want to call
"read" on it.
I'd expect to be able to do (read (reader my-file)), but this isn't OK
because read needs a java.io.PushbackReader. It seems vaguely wrong
12 matches
Mail list logo
