Fork me on GitHub
#unrepl
<
2017-09-11
>
bozhidar13:09:20

@cgrand It’s a pity with didn’t get to chat at ClojuTRE, but I wasn’t feeling great and I was in a very uncommunicative mood.

bozhidar13:09:11

Btw, I think there’s some point to distancing unrepl from nrepl a bit, jokes aside.

cgrand13:09:02

@bozhidar next time, are you going to the Conj?

cgrand13:09:40

distancing names even for spelling?

bozhidar13:09:12

Yep. Sends a stronger message that one is not some continuation of the other (or an antipod for that matter).

cgrand13:09:07

originally I named it richrepl because richer interaction and influence by Rich rant on repls

bozhidar13:09:12

No, I won’t be coming to the conj this year, but I’ll be at ClojureX. I’m not doing enough Clojure development these days to justify dealing with the jetlag. 🙂

cgrand13:09:11

ClojureX in unlikely for me

cgrand13:09:21

:ClojureD maybe?

cgrand13:09:56

do you have any opinion or advice about unrepl (short of naming)?

bozhidar14:09:28

> :ClojureD maybe?

bozhidar14:09:31

Maybe. 🙂

bozhidar14:09:57

> do you have any opinion or advice about unrepl (short of naming)?

bozhidar14:09:50

I didn’t play much with it, but I liked the idea overall. Wanted to spend some time researching how it could be used with CIDER, but lately I’ve had a ton of work and very little free time.

bozhidar14:09:30

Maybe just one - better commit messages. I look from time to time at the code and such commit messages puzzle me a bit 🙂

dominicm16:09:32

@bozhidar I have thought about CIDER a little. I suspect it will primarily just be sending eval's because EDN allows a richer communication model, so much of the extra ops are unrequired in unrepl.

dominicm16:09:54

The only one I think is missing, is streaming of results. But I think this is something that only refactor-nrepl does.

cgrand16:09:39

@dominicm what do you mean by streaming of results?

dominicm17:09:50

Actually... A sufficiently lazy sequence might be able to do it. Basically if you have a slow operation you can do: > sleep 1000 > send result 1 > sleep 1000 > send result 2

cgrand17:09:01

From user code or tool code?

dominicm17:09:29

If you're asking "is this something only tooling would need", I think so, yes.

cgrand17:09:46

For user code there's print and log messages.

cgrand17:09:13

The difference is that log output browsable values.

cgrand17:09:17

And a tool could create its own stream of EDN messages (ok ok the extension system is not specified yet)

dominicm17:09:41

@cgrand yeah, now extension systems are a thing it's fine

dominicm17:09:20

I think a nice way to design this would be with a 1 print length lazy sequence.

cgrand17:09:22

Mixing laziness and control flow in Clojure…

dominicm17:09:41

@cgrand not fully sure I understand how I'm mixing them

cgrand18:09:46

I'm not sure that I get how you would use lazy sequence for that.

dominicm18:09:51

@cgrand I'm thinking from the context of the work being optional, you could stop it when necessary. And rely on the laziness property to defer work. So I guess that could be considered tying control and laziness.

dominicm19:09:59

@cgrand is this considered bad form? I might have to go rewrite some code...

cgrand19:09:11

If you look at Clojure evolution, the laziness contract has been relaxed multiple times. Strict laziness existed only for a short time (after the demise of nil-punning and before chunked seqs). To me it clearly mean that laziness in Clojure should not be used for flow control.

bozhidar20:09:25

@dominicm But still you’ll need to bundle a bunch of utility libraries providing the functionality you want to eval and you need some session multiplexing as you don’t want pollute the main user session with eval results for tooling needs (e.g. completion).

dominicm20:09:55

The latter is done by opening a second connection (or more) for tooling. The former is slightly more complex, but essentially unrepl can query for missing classes, which can be sent to continue evaluation.