4

Is there a function in clojure that checks whether data contains some lazy part?

Background:

I'm building a small server in clojure. Each connection has a state, an input-stream and an output-stream

The server reads a byte from an input-stream, and based on the value calls one of several functions (with the state and the input and output stream as parameters). The functions can decide to read more from the input-stream, write a reply to the output stream, and return a state. This part loops.

This will all work fine, as long as the state doesn't contain any lazy parts. If there is some lazy part in the state, that may, when it gets evaluated (later, during another function), start reading from the input-stream and writing to the output-stream.

So basically I want to add a post-condition to all of these functions, stating that no part of the returned state may be lazy. Is there any function that checks for lazy sequences. I think it would be easy to check whether the state itself is a lazy sequence, but I want to check for instance whether the state has a vector that contains a hash-map, one of whose values is lazy.

Claude
  • 8,806
  • 4
  • 41
  • 56

2 Answers2

3

it's easier to ensure that it is not lazy by forcing evaluation with doall

I had this problem in a stream processing crypto app a couple years back and tried several ways until I finally accepted my lazy side and wrapped the input streams in a lazy sequence that closed in input streams when no more data was available. effectively separating concern for closing the streams from the concern over what the streams contained. The state you are tracking sounds a little more sophisticated than open vs closed though you may be able to separate it in a similar manner.

TacticalCoder
  • 6,275
  • 3
  • 31
  • 39
Arthur Ulfeldt
  • 90,827
  • 27
  • 201
  • 284
  • doall doesn't work recursively unfortunately: `(count (doall [1 2 3 4 (range)]))` will return 5, and not stack/heapoverflow. – Claude Mar 28 '12 at 22:23
  • Ah, and on the second part: wrapping the inputstream in a lazy-sequence is something I considered, and works (although you loose stuff like java DataInputStream). With the outputstream this doesn't work though, this is the one place where you actually need the side effect. – Claude Mar 28 '12 at 22:25
  • (count (map doall (filter seq? [1 2 3 4 (range)]))) – Arthur Ulfeldt Mar 28 '12 at 22:27
  • 1
    if you need further nesting look at using a zipper to recursively walkt your structure. – Arthur Ulfeldt Mar 28 '12 at 22:28
  • @Claude - typically that is what you would want. if you intended the `range` to be part of the same sequence then you could do `(count (doall (concat [1 2 3 4] (range 10))))` (which gives 14; and you don't really need `doall` since `count` will expand...) – andrew cooke Mar 28 '12 at 23:55
1

You could certainly force evaluation with doall as Arther wisely suggests.

However I would recommend instead refactoring to solve the real problem, which is that your handler function has side effects (reading from input, writing to output).

You could instead turn this into a pure function if you did the following:

  • Wrap the input stream as a lazy sequence
  • use [input-sequence state] as input to your handler function
  • use [list-of-writes new-state rest-of-input-sequence] as output, where list of writes is whatever needs to be subsequently written to the output stream

If you do this, your handler function is pure, you just need to run it in a simple loop (sending the list-of-writes to the output stream on each iteration) until all input is consumed and/or some other termination condition is reached.

mikera
  • 105,238
  • 25
  • 256
  • 415
  • Anything that touches lazy becomes lazy :) – Ankur Mar 29 '12 at 04:32
  • @Ankur - that's true (assuming you don't force evaluation) though I think the most important point is that if you stick to pure functions, laziness never matters. – mikera Mar 29 '12 at 06:26
  • I've given this suggestion a lot of thought over the past day or so. On the one hand I like the pure function. However working with sequences removes (in my idea) the cleanness of code. If I have a stream from which I need to read a long first (a), then a byte (b), and then (b) many ints, it would be easy to do(and easy to understand for anyone reading the code) `(let [a (.readInt i) b (.readByte i) c (repeatedly b #(.readInt i))] ...)`. How would one cleanly do this with a sequence... – Claude Mar 29 '12 at 21:58
  • @Claude - you'll certainly need to write that kind of code code at some point, but I would suggest wrapping it into a `read-message` function. Then you can do `(repeatedly read-message)` and get a lazy sequence of incoming messages. This is then the lazy input sequence that you will want to deal with (i.e. you want to operate at a slightly higher level of abstraction) – mikera Mar 30 '12 at 02:11
  • This looks like a clean solution, especially if you wrap your messages in some standard format (e.g. google protocol buffers). You do loose some flexibility though; for instance you can't start processing a message before the full message is received (question is how often you need this functionality anyways...). Thanks for your insights! – Claude Mar 30 '12 at 14:13