On Mon, May 25, 2015 at 12:48 AM, Alexis King <lexi.lam...@gmail.com> wrote: >> Depending on other design decisions, it make make sense to consider >> this an IDE issue. That is, maybe the best thing is to have some kind >> of interactive value in the REPL that lets the user have control over >> the effects. (And this doesn't just have to be via some kind of >> simplistic mouse clicking -- I think there is a lot of unexplored UI >> space here). > > I'd definitely be curious to see what you have in mind beyond some > "simplistic mouse clicking". It would be cool to convey more information > about sequence values via DrRacket's capability to render snips.
I can't say that I have real concrete ideas, but all of this work on live updating GUIs seems promising. There's a lot out there, but beyond the obvious suspects, check out Sean McDirmid's work. It may also make sense to explore constructs that control effects somehow so you can just run things. I recently hacked together a little GUI thingy for showing enumerations that just let them scroll by inside what looks like the normal enumeration print out and it works by sampling and caching the first 200 elements of the enumeration, but being careful about errors and to staying the user's side of the world during the cache population. It does evaluate things at the point displaying is happening, but people generally do not have much expectation about when those functions are evaluated, so it seems to work well as long as errors that happen are printed sanely. > As for Daniel's point about the contract violation, I've pushed a change that > makes `sequence?` into a custom flat contract, so that example now gives a > more useful error message: > > > (take 5 (list->vector (range 10))) > take: contract violation > expected: (and/c immutable? sequence?) > given: '#(0 1 2 3 4 5 6 7 8 9), which is mutable > > However, this only works when the contract is used alone in a first-order > way. It doesn't give a helpful error message when used with `first`, for > example: > > > (first (vector 0)) > first: contract violation > expected: (and/c sequence? (not/c empty?)) > given: '#(0) > which isn't: sequence? > > It would be possible in this case, of course, to create a > `nonempty-sequence?` contract, but it still wouldn't work in other cases. > Robby, do you know of any way I could provide this extra error reporting in > more cases while still keeping `sequence?` a flat contract? I'm not completely sure I'm getting the point, but is this something that and/c would need to cooperate with? Like for it to recognize that sequence? (which maybe should be called sequence/c instead?) is itself and and/c and print nested ones better? Robby -- 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.
