Arc Forumnew | comments | leaders | submitlogin
5 points by pg 5470 days ago | link | parent

Rtm tried for a bit, but eventually gave up. Versions of Mzscheme after 372 made conses immutable, and it was just too hard to work around this.

(I'm surprised they did that, actually, because it means Mz is no longer compatible with the Scheme standard.)

This might be the time to fork off a new MzScheme, if anyone is up for that.



2 points by elibarzilay 5465 days ago | link

No fork is necessary for mutable pairs -- mzscheme is flexible enough to allow breaking itself...

-----

1 point by CatDancer 5465 days ago | link

I tried a port (http://hacks.catdancer.ws/plt4-port.html) but it's running 3.5 times slower... any suggestions?

-----

1 point by CatDancer 5466 days ago | link

This might be the time to fork off a new MzScheme, if anyone is up for that.

Are there any bugs or deficiencies in MzScheme 372 that we'd like to fix if we keep using it?

-----

1 point by rocketnia 5465 days ago | link

Wouldn't it be simpler just to fork from 4.2? Making immutable pairs not-really-immutable shouldn't actually break any existing PLT-based code, since that code won't modify them. ^_-

It might break some low-level optimizations in PLT Scheme itself (which could be fixed in the forked version), it might break compatibility with other projects that dig into the PLT code, and it might annoy some library writers who really didn't want careless users to shoot themselves in the feet or expose security holes, but that's all the trouble I can think of offhand.

-----

1 point by CatDancer 5465 days ago | link

Simpler in what way?

Breaking the PLT Scheme optimizer by mutating pairs it thinks are going to be immutable and then going in and figuring out which optimizations to fix doesn't sound very simple to me... but, assuming that it was easy to do, what does starting from 4.2 do for us?

-----

1 point by rocketnia 5465 days ago | link

I guess I just see "Take the newest MzScheme and implement not-so-immutable conses again" as a conceptually easier task than "Take the fork and implement feature A and feature B as inspired by the newest MzScheme." Of course, the more objections we have to MzScheme changes, and the more features of our own we want to include, the harder this becomes.

-----

2 points by elibarzilay 5465 days ago | link

There are a lot of new features, as well as more and better optimizations in v4.2.

-----