[plt-dev] some Racket proposals & implementation

I am almost certainly overreacting, but I can't really get behind this point.

The main issue seems to be that sstruct uses "many libraries at
compile time". In particular that's scheme/match, dict, and
syntax/parse. If we can't use our high level language and awesome
macro tools in our main language, what's the point?

My radicalism says that we should do what is elegant and nice and work
on better compilers, optimizers, etc to deal with the memory footprint
and startup time. I like Racket to begin with because I want the
computer to do the work, not me.

In this particular case, my batch compiler with its straight-forward
dead-code elimination allows you to use "scheme" and get the smallest
bit that you actually need. It gets smaller startup time and memory
footprint. Currently it's not perfect, but it seems like it is the
right direction when you're concerned with memory footprint, rather
than holding back what we otherwise believe are good features.

As a corollary, I see this define-sstruct as a nascent lambda/kw. If
we really value it, then it should be the default and we should do
what it takes to make it work. If we don't go that route, it doesn't
make sense to me to have it as a PLaneT package or swindle-like thing
that isn't commonly used. To be clear, I'm cool going that way. I'm
not emotionally attached to code that I wrote over two days in 30
second increments.

Jay

On Sat, Apr 3, 2010 at 6:20 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sat, 3 Apr 2010 15:23:36 -0600, Jay McCarthy wrote:
>> Would we want to use this as the
>> default define-struct in #lang racket? Or should I put this in
>> unstable or on planet?
>
> The `racket' language should probably have the same `define-struct' as
> in `racket/base' --- and one thing to keep in mind for things that
> might go into `racket/base' is that the footprint of the implementation
> can matter.
>
> At the moment, the difference between
>
>  #lang scheme/base
>  ;; (require "sstruct.ss")
>  (current-process-milliseconds)
>  (collect-garbage)
>  (current-memory-use)
>
> with and without the commented line:
>
>                       from source           from .zo
>                       time    mem          time  mem
>  without sstruct      51ms    2.2MB        45ms  2.0MB
>  with sstruct        224ms    9.6MB       184ms  9.3MB
>
> Changing "sstruct.ss" to build on `scheme/base' instead of `scheme'
> lowers the overhead somewhat, but not much, since "sstruct.ss" uses
> many libraries at compile time. Turning that around, switching the
> program above from `scheme/base' to `scheme' has a comparable effect on
> the program as using "sstruct.ss", and then using "sstruct.ss" is a
> relatively small additional overhead.
>
> Arguably, at least in the .zo case, the blame for the overhead belongs
> to our approach of building up language towers instead of a more
> conventional bootstrapping process. I think the simplicity of language
> towers has generally been a win, and it only seems like a problem to me
> when I'm implementing parts of the core.
>
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93