Thanks for the feedback! To start out with, let me address your initial three points. With regards to the error messages and tooling, I agree completely, and I actually think this is one of the areas where Racket can blow Clojure out of the water. Contracts alone are pretty expressive, and I'd absolutely like to try and make the system a little less opaque than Clojure's.
As for use of persistent data structures, I think it's a good design decision, but as I mentioned above in my response to Greg's email, Racket's data structures, mainly its vectors, aren't quite up to snuff to handle that model just yet. Getting good persistent vectors is a high priority. With that said, let me address your other points. > So I see what you're doing as exciting, but would appreciate a bit more about > where you're aiming to take this in your introduction. If you could outline > your criteria / aims that would be clarifying. Are you aiming for consistency > with Clojure or making a judgement call on an intermediate style (c.f. Greg's > #lang rackjure)? I'm aiming to make a library that would feel at home in Racket if backwards-compatibility were not an issue. I want this library to feel like Racket, not Clojure, but I'm also willing to override some of Racket's primitives to implement those ideas. Consider it an experimental proposal for #lang racket2. I really, really want to maintain the simplicity that the library currently provides, especially with the implementation of new user-defined data structures. Having a few interfaces with a handful of functions apiece is nice. The trick is figuring out how to provide enough capability for optimization hints to keep everything fast with such a small interface (something that I think is absolutely doable). > > (take 5 (range 10)) > #<lazy-sequence> > > > (drop 5 (range 10)) > '(5 6 7 8 9) Alright, let's talk about this. Consider the "producer/consumer" point I laid out above. This library is heavily optimized with the idea that once you start manipulating a sequence, it's better to force it into read-only mode instead of performing an expensive copy. For a list, dropping elements from the front requires no copying at all, so it just returns a list. On the other hand, taking elements from the front would require allocating a new list, so instead, you get a special kind of sequence that doesn't need to do any copying. > > (take 5 #(0 1 2 3 4 5 6 7 8 9)) > #<lazy-sequence> > > > (drop 5 #(0 1 2 3 4 5 6 7 8 9)) > #<random-access-sequence> This is the same sort of idea, but here, even dropping elements would require a new vector to be allocated. Slow and unnecessary if you're only reading! So instead you get a "view" on the vector as a sequence. If you want to modify it, make sure you have the representation you need first. Do (extend #() (drop 5 #(0 1 2 3 4 5 6 7 8 9))), then modify. As for printing these sequences... yes, printing as #<lazy-sequence> sucks. Currently you can always force a sequence with sequence->list, but that's annoying. Clojure takes the approach of making printing lazy sequences force them. This is okay, but it also can be incredibly confusing when side effects get evaluated in the REPL but not in code. I'm unsure about what to do about that particular problem. I'd like to maybe add a nicer printer for sequences, but I'm not completely sure what the best way to do that is, yet. > > (take 5 (list->vector (range 10))) > take: contract violation Ahh, then there's this. This absolutely needs a better error message. See, list->vector gives you a mutable vector, and sequence operations only work on immutable vectors. I consider this a flaw with Racket's vectors, also something I'd hope could be alleviated by a better vector library, but for now, it would make sense to add some special error messages for mutable vectors and mutable hashtables, which would otherwise just seem to fail mysteriously. Just for the sake of that example, though, this works: > (take 5 (vector->immutable-vector (list->vector (range 10)))) #<lazy-sequence> -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
