[racket-dev] Things we could move out of the core

On Wed, Jun 26, 2013 at 6:36 AM, Eli Barzilay <eli at barzilay.org> wrote:
>
> An hour ago, Robby Findler wrote:
>> The sandbox, IMO, is a nice standalone library the does not need to
>> be in the core. (Ditto for errortrace.)
>>
>> I like the definition of the core as "minimum stuff to get pkgs
>> running" and we should be picky about what goes in -- even to the
>> point of rewriting some code to move other stuff out.
>
> This doesn't make sense if things at such a small size turn to
> packages.  It's true that a package is a unit of utility for end
> users, but it's also a unit of developement.  IMO there are far better
> things to move out -- things that are bigger (in size and complexity)
> like (on a brief scan) contracts, gui, match, places, units, json,
> planet, xml, net, help.[*]

`racket/gui` just contains `racket/gui/dynamic`.  The `help`
collection has 72 lines of code.

`racket/match`, `racket/unit`, and `racket/contract` are widely used
in the core, as is `syntax-parse`, another big library.  We could
decide to move them out, but that would be a big change in coding
style and a massive rewrite of a lot of code.

`planet` is closely tied to the internals of the setup system.  We
might wish this wasn't the case, but I doubt that it's worth
disentangling.

The package system uses `net`, of course.

Places are used by `raco setup`. Perhaps distributed places could be
moved -- I don't know how intertwined they are.

`xml` is used by `planet` (for checking that some info.rkt fields are
properly xexprs),  `db` (not actually used, I think), and `compiler`
(for managing plists when creating bundles on OS X).  `json` is used
by `db` (for handling JSON in Postgres) and `pkg` (for contacting
GitHub).   For these two, if you wanted to write the patch to make
them removable, that would be great, but it looks like it would be
hard.

>> Think of someone deploying a game on a phone: would they be happy
>> with your rationale influencing their app's size?
>
> I think that errortrace has been one of the biggest offenders in terms
> of bad bugs of many varieties -- and moving it out won't help.  (And
> if I were doing a game on a phone I'd worry about any of the above
> much more, btw.)

I think "library that has lots of bugs and mostly only Matthew ever
knows how to fix" is a strong candidate for _not_ being in the core.

Sam