Fork me on GitHub
#rewrite-clj
<
2019-06-05
>
sogaiu10:06:16

would things break if: 1) sexpr was removed from the Node protocol, 2) another protocol was created with just sexpr, 3) only those things that don't purely throw exceptions for sexpr implement sexpr (participate in the protocol for 2), 4) before using sexpr, one could use satistfies? to check whether it would be safe to call sexpr ?

borkdude11:06:12

that would probably break the API yes. afaik the only things not seprs-able are comments and unevals? so it’s easy to write a predicate for that I guess

sogaiu20:06:53

based on recent conversations and looking at the source, it looks like the things that throw from sexpr include: comment, some reader nodes, uneval, whitespace, comma, newline. most of those throw unconditionally, at least one only sometimes.

sogaiu01:06:31

@lee is the idea of a predicate like sexprable? worth considering?

sogaiu01:06:47

ah, iiuc, it looks like all of the existing reader nodes provide sexpr-fns so they all don't throw by default.

sogaiu01:06:23

comma, newline, and whitespace can be tested for via node/whitespace? comment can be tested for via node/comment? if something analogous existed for uneval (similar thing in clj-kondo's utils), then perhaps one could have sexprable? be something that used whitespace?, comment?, and uneval?

lread12:06:43

yeah, one of my goals is no breaking changes. I might almost achieve it - but have migrated cljs positional fns to clj positional support so there’s at least one!

lread12:06:56

on that topic... do you guys know of any tools to test for breaking changes? I was thinking of comparing api fn signatures from current rewrite-cljs and rewrite-clj against my work.

borkdude13:06:32

doesn’t rewrite-clj proper have a test suite you can run against your changes?

borkdude13:06:01

clj-kondo has 70 tests and 500 assertions right now, you could maybe also try that

lread13:06:27

yeah it does have a good suite but rewrite-cljs suite was much smaller. just want to take what care I can to avoid unintentional breaking changes

borkdude13:06:52

why not incorporate all of rewrite-clj’s existing tests?

lread13:06:20

I have done that

lread13:06:53

just trying to be extra careful

lread13:06:17

do you think a tool that tests for api breakages between versions would be of general interest?

borkdude13:06:37

I think a test suite already takes care of that?

lread13:06:17

maybe it does if you you have complete coverage and haven’t made a human error

borkdude13:06:49

so you tool would write tests for free? seems awesome 😉

lread13:06:14

it would only compare api fn signatures between versions

lread13:06:52

I’m getting the strong impression you would not value such a tool simple_smile

lread14:06:26

martin klepsch goes over this type of idea in his recent talk: https://youtu.be/8klBWIwYfsY?t=1934

sogaiu21:06:44

ah sorry, i see that the link had a time in it. thanks!

sogaiu21:06:34

there is mention of detection of changes under the heading "automatic changelogs". the detection part could use its own name imho 🙂 i think it'd be nice to have this while writing intend-to-commit code -- so comparing between what is already committed and what is in the current tree.

sogaiu21:06:03

digressing a bit -- after "automatic changelogs" he mentions "examples". along those lines, one of the things i'm using rewrite-clj for is testing the idea of annotating code within rich-comment-blocks with test info. such code looks like:

(comment

  ^{:ael/want 2}
  (+ 1 1)

)
coming back to the code later, i have a record of what the results should be, but also, someone else examining the code might have a better idea of what concrete values are expected. further, using rewrite-clj, all of the code in the rich comment blocks can be extracted and turned into runnable tests -- the metadata annotations are then used for checking the results and labelling. the generated tests can be saved to a file to be run later and/or distributed as tests.

borkdude14:06:16

I would value it, but I don’t see what it adds compared to a test suite. A good test suite tests all the arities of an API, that’s my assumption

borkdude14:06:41

I’ll watch the talk section

borkdude14:06:13

I mean, as a library author, it should not come as a surprise that you’re breaking an API when you remove an arity 🙂

borkdude14:06:41

as a library consumer that would be interesting I guess, since you’re not in control

borkdude14:06:35

clj-kondo already saves the arities of functions in a cache, I guess diffing the cache on a next run wouldn’t be too hard

borkdude14:06:41

but maybe it makes more sense as a standalone tool, so please go ahead @lee

borkdude14:06:12

as part of cljdoc it would be useful for a wider audience I guess

sogaiu20:06:53

based on recent conversations and looking at the source, it looks like the things that throw from sexpr include: comment, some reader nodes, uneval, whitespace, comma, newline. most of those throw unconditionally, at least one only sometimes.

sogaiu21:06:34

there is mention of detection of changes under the heading "automatic changelogs". the detection part could use its own name imho 🙂 i think it'd be nice to have this while writing intend-to-commit code -- so comparing between what is already committed and what is in the current tree.

sogaiu21:06:03

digressing a bit -- after "automatic changelogs" he mentions "examples". along those lines, one of the things i'm using rewrite-clj for is testing the idea of annotating code within rich-comment-blocks with test info. such code looks like:

(comment

  ^{:ael/want 2}
  (+ 1 1)

)
coming back to the code later, i have a record of what the results should be, but also, someone else examining the code might have a better idea of what concrete values are expected. further, using rewrite-clj, all of the code in the rich comment blocks can be extracted and turned into runnable tests -- the metadata annotations are then used for checking the results and labelling. the generated tests can be saved to a file to be run later and/or distributed as tests.

lread21:06:19

yeah for this hypothetical api comparison tool, I’m thinking of cases where either you’ve maybe come in as a maintainer of an existing lib (my case) and when there are many contributors - I expect newbies would like to know if they’ve accidentally broken the api

sogaiu21:06:53

i expect some non-newbies would like to know too 🙂

lread21:06:29

simple_smile I’ll ping martin to learn if he’s found any existing work.

lread21:06:26

@sogaiu I think Arne Brasseur is doing something interesting that might be related. I think he’s generating docs for kaocha from tests. Here’s a random example: https://cljdoc.org/d/lambdaisland/kaocha/0.0-418/doc/cli-print-the-kaocha-configuration

lread21:06:07

your comment block idea is interesting too. Personally, after experimenting, I convert to unit tests and delete my comment blocks.

lread21:06:40

but your comment blocks can become unit tests… interesting.

lread21:06:42

I take it back, the kaocha example is not really related to what you are doing. But it is kind of cool, right? simple_smile

sogaiu21:06:44

@lee it is interesting for sure. i've been thinking to record execution of code and generate / analyze results -- generating draft docs is one thing that could be done with this sort of thing.

borkdude21:06:56

comment blocks that become tests, that sounds also like https://github.com/cognitect-labs/transcriptor

sogaiu21:06:12

@borkdude indeed, that's one of the inspirations

sogaiu21:06:32

there were some problems w/ transcriptor, and this is an experiment to work around some of them

lread21:06:09

@borkdude, I manually tried your problem file in my cljs playground a while ago and forgot to tell you. I parsed it in and spit it out successfully.

borkdude21:06:52

with tools.reader 1.3.2?

borkdude22:06:32

confirmed, I tested it now too

borkdude22:06:56

was there anything in particular you changed to make it work, or it just worked?

lread22:06:16

just worked

lread22:06:25

yes I am using tools.reader 1.3.2

borkdude22:06:44

the bug I’m getting with the original is that it tries to check if an empty string is a string consisting of linebreaks

lread22:06:11

hmmm… I started this so long ago I don’t recall changes I made. But something must be different!

lread22:06:33

I’m going to try to focus on finishing up my cljs ticket for now. If this is blocking you, let me know and I’ll take some time to dig in.

borkdude22:06:19

Not really blocking, I’ll figure something out

sogaiu01:06:47

ah, iiuc, it looks like all of the existing reader nodes provide sexpr-fns so they all don't throw by default.

sogaiu01:06:23

comma, newline, and whitespace can be tested for via node/whitespace? comment can be tested for via node/comment? if something analogous existed for uneval (similar thing in clj-kondo's utils), then perhaps one could have sexprable? be something that used whitespace?, comment?, and uneval?