Arc Forumnew | comments | leaders | submitlogin
1 point by CatDancer 5628 days ago | link | parent

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 5628 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 5628 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 5627 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 5627 days ago | link

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

-----