Won't something like

(defn lazy-tree
  []
  (lazy-seq
   (list
    (lazy-tree)
    (lazy-tree))))

I think any such data structure will stack overflow.

(defn x [] [(x)]) (x)

Not if it's lazy, then maybe you can walk it

seems like my lazy-tree doesn't stack overflow as long as you don't print anything

(def f (first (lazy-tree)))

it's fine as long you don't do anything with f

which is pretty useless ;)

You guys are fast. This was my first attempt, but it burns up tthe CPU…: ((fn f [] (lazy-seq (f))))

But attempting to get even the first element locks up. I’m not sure why since the very first element is not aggressively computed (you can perform class on the return of that fn call above).

Let's ask the big question - why?

I”m OK with blowing out the stack on printing or attempting to walk infinitely deep -that’s kinda the point of this structure. I want to be satisfied that my code lazily walks an infinitely deep data structure.

Just as first can force realization of the first of an infinitely wide data structure, I want to prove that my accessor ( a variant of a zipper) forces instantiation of only a finite number of recursions of an infinitely nested data structure.

@UK0810AQ2 ' attempt and mine have a common shape: a recursive call to a lazy seq with a single elements that is a call to a lazy…

Actually, my example is both infinitely deep and infinitely wide

Yep. Mine is not, and just infinitely deep is OK.

its width increases exponentially

I’ve already got the width test working.

but what's the difference between an infinite lazy seq and an infinitely deep seq? an infinite lazy sequence is like a linked list. Isn't a linked list deep? or do you consider it wide?

But the infinintely deep part seems like it should work. But it clearly does not

I think the difference can best be explained with an example accessor: (iterate first data) should run infinitely long on an infinitely deep structure. It would not (necessarily) on an infinitely wide lazy seq.

Upon further reflection, here is my litmus test: (iterate first data) should neither error nor return only on an infinitely deep data structure while (iterate rest data) should neither errors nor return only on an infinitely wide data structure. (both modulo stack overflow or OOM conditions).

still haven't answered why

at first reading this is classic https://xyproblem.info

WHy is easy: to test that a zipper-like constructor does not accidentally walk infinitely deep (and I know it does now, it’s not trivial to fix and it’s easy to regress -thus a unit test seems prudent).

…plus it seems like, for all it’s elegant handling of laziness, Clojure would have a tool for lazy recursive (in depth) data structures.

several of the code snippets above will generate recursive datastructures

But none seem to be able to do so in finite time.

whether or not you can print them is a separate concern

I do not understand that assertion

Maybe I missed something…. checking my first solutiuon again…

Nope. Mine (for sure) and I think Ben’s solution (I think, more testing required) both cannot pass the test of (class (first data))

(class data) => LazySeq

(class (first data)) => ….

Looks like @UK0810AQ2 ' solution (`lazy-tree`) passes the “Access the first element lazily” test…

Here’s a slightly simplified version (only infinite vertically) of Ben’s lazy-tree that does indeed solve the problem:

(def lazy-tree
  ((fn f [] (lazy-seq
            (list
             (f))))))

Thanks, Ben.

Correctly blows out the stack on (iterate first (lazy-tree)).

This is what I thought too, but an answer with 11 upvotes on Stack Overflow suggested using array-map so I thought perhaps I was mistaken.

Afaik array-map is just an optimization detail

Yeah, 8 seems to be the magic cutoff on my machine:

user=> (into (array-map) (into (sorted-map) (zipmap (range 9 0 -1) (repeat 1))))
{7 1, 1 1, 4 1, 6 1, 3 1, 2 1, 9 1, 5 1, 8 1}
user=> (into (array-map) (into (sorted-map) (zipmap (range 8 0 -1) (repeat 1))))
{1 1, 2 1, 3 1, 4 1, 5 1, 6 1, 7 1, 8 1}

Yes, but the DSL is basically json. It is not meant for Clojure programmers, but people with experience with a Python DSL called https://snakemake.readthedocs.io/. For those users, this would be expected behavior.

But you want to parse this using a Clojure parser?

Yes. I guess I should just use a vector of tuples: [[kw val] [kw2 val2] ...] instead

Thanks for the suggestions and help btw.

But this would require my users to add the order above. I guess preprocessing the file to switch {-1 5 0 3} into (seq '([-1 5] [0 3])) is the best way to do it. Or just use a vec of [kw val] tuples.

Alternatively, you can explicitly use array maps. The order will be preserved. Do note however, that assoc, dissoc, and any other function that returns a new map may change its type to a hash map.

because they have different semantics? ... refs need to be used in a transaction. Agents are asynchronous. Volatile's and Atoms have different thread guarantees. I'm not sure that anyone should be pretending that they're the same to write to ... only that you can deref them to read

it's not about pretending they are the same

it's about having an abstract operator with a unique name that has different semantics based on the value it is called with

Abstractions are about pretending a group of things are the same in a specific way. Clojure's reference types are the same in that they can always be read without a significant cost (unlike a remote actor which would require a network request, for example) because they're in ram and (ideally) wrap a persistent data structure. But they all have different semantics for writing to, so what's the point of an abstract function? Isn't that just a common name that obscures the important difference between why you're using one reference type over another?

I'm not sure I understand why that would be a positive thing

obscures it for whom? why would an expression have to locally demonstrate the semantics of it's execution if the semantics doesn't matter locally?

at the local point where swap!/vswap!/... is called, the knowledge about the type of the ref does not matter

after all, is the ref itself not telling you that difference?

(circle-area circle) (square-area square)

Let's say there was a a protocol for writes of ref-like things. Then the underlying interface would be "megamorphic" which makes function inlining less likely Not sure if this is the precise reason though, but megamorphic site: returns some hits

> why would an expression have to locally demonstrate the semantics of it's execution if the semantics doesn't matter locally? Because it matters in the execution of the program. If it's a agent, then I can't deref it and expect it to have the value I've just sent it, or if it's a ref I have to have a transaction open make a change. > at the local point where swap!/vswap!/... is called, the knowledge about the type of the ref does not matter I'm not sure I can agree with that. I think at that point it very much matters. My send to an agent has completed, what can I do with that agent, vs the equivalent on an atom. > after all, is the ref itself not telling you that difference? Yes, the constructors are different. But so are the update semantics, and also the reasons that an update might fail or be retried. These differences are what would be obscured by an abstraction that allowed you to easily exchange one for another. It would also need to take into account things like transactions, asynchrony, livelocks and deadlocks (for example), and complicate the ease of use of things like atoms. Also, how would it deal with alter vs commute? Would it need to support both update strategies on all reference types?

I think history is also a reason that this doesn't exist. The STM predates protocols in Clojure.

your take would have made sense to me if one of swap!/vswap!/alter!/send had implementations for more than one ref-type

I'm not sure I understand why that makes more sense ... can you explain further, please?

all these functions are always called in the presence of the ref-like value, so there is no confusion there with respect to alter/commute issue, in the absence of knowledge, it would call whichever operation that is more generic (expects less structure from data)

> all these functions are always called in the presence of the ref-like value, so there is no confusion there I think that's what I'm getting at. There is confusion. Everything about calling one of these update functions is different, apart from the fact that they all do some form of state management > with respect to alter/commute issue, in the absence of knowledge, it would call whichever operation that is more generic (expects less structure from data) alter updates a ref in a compare and swap kind of way (but consistently within the transaction), wheras commute allows for commutable operations to be reordered if there's a transactional conflict. This isn't supported by any the other reference types and is an example of where the semantics up updating a ref differ from an atom, for example.

is there an actual api doc anywhere for next.jdbc? not seeing it on the readme

ah, nvm I found it

I guess I should add a more obvious link to the API docs then...

(done; also link to older docs under old group ID)

thx

https://www.hyrumslaw.com/