feat: Adds Dynamic.sort & improves output of failing dynamic tests

[TimDeve]

This adds Dynamic.sort function based on the quicksort described here.

It also contains a refactor of the dynamic test handles to properly display a diff of the expected Vs actual value rather than displaying "true" : "false".

Test display examples:

old:

Test 'Dynamic.sort sorts from higher to lower' failed:
        Expected value: 'true', actual value: 'false'

new:

Test 'Dynamic.sort sorts from higher to lower' failed:
        Expected value: '(4 3 3 5 1)', actual value: '(4 3 3 2 1)'

[TimDeve]

str for map is a bit odd, my understanding is there is a separate function for dynamic Maps (Dynamic.Map.str), is it not possible to make the standard str Map aware? Is it because Maps are just lists of tuples?

[eriksvedang]

@TimDeve Yeah there has been some discussions about that, but since the idea is to replace the dynamic map with a faster, built-in one I think we decided to just wait for that instead.

[hellerve]

Oh is that the idea? I didn’t know! Bummer, I was hoping we’d move more code out of Haskell and into Carp rather than the other way around.

[TimDeve]

I wasn't quite sure if having this in "userspace" was the goal or a shortcut. If we want to keep in Carp I'm wondering if we could "tag" the list with a symbol to be able to tell the difference between a simple list and a map.

[eriksvedang]

Oh is that the idea? I didn’t know! Bummer, I was hoping we’d move more code out of Haskell and into Carp rather than the other way around.

In my mind, we had more or less agreed on this, but maybe I'm misremembering. In general I agree that not putting stuff in Haskell is the right choice, but for the dictionary I think just doing the fastest thing possible is correct.

[hellerve]

I wasn't quite sure if having this in "userspace" was the goal or a shortcut. If we want to keep in Carp I'm wondering if we could "tag" the list with a symbol to be able to tell the difference between a simple list and a map.

We tried this in #1177 but it was shot down for now.

[scolsen]

#1177

Maybe we can revisit this now, if you're up for it?

I still think it's a good idea. Having more specialized data structures available in dynamics is a win imo. As I said in that PR thread I think the only thing I'd want is to make sure it's clear in the code when a type is dynamic vs. when it's static.

Also I think it's orthogonal to the dictionary issue. If Haskell based dicts are significantly faster it makes sense to me to use them, but I think dynamic types would still be a useful feature aside from that.

[eriksvedang]

Also I think it's orthogonal to the dictionary issue. If Haskell based dicts are significantly faster it makes sense to me to use them, but I think dynamic types would still be a useful feature aside from that.

Yeah, agreed.

[hellerve]

Also I think it's orthogonal to the dictionary issue. If Haskell based dicts are significantly faster it makes sense to me to use them, but I think dynamic types would still be a useful feature aside from that.

It’s not orthogonal in that it allows custom stringification for dynamic types, which is what prompted the conversation.

[TimDeve]

I wasn't quite sure if having this in "userspace" was the goal or a shortcut. If we want to keep in Carp I'm wondering if we could "tag" the list with a symbol to be able to tell the difference between a simple list and a map.

We tried this in #1177 but it was shot down for now.

I meant more to have a marker at the front of the list rather than proper dynamic types so {1 2} would be:

('dynamic-map-marker () () () () () () () () () () () () () () () ((100000000000000000 2)))

compared to the current:

(() () () () () () () () () () () () () () () ((100000000000000000 2)))

Edit:
Sorry missed the part where that's effectively how #1177 was implemented.

[TimDeve]

It's ready to merge if people are okay with the changes.

[eriksvedang]

Great!