[racket-dev] internal-definition parsing

2010-07-07 Thread Matthew Flatt
Short version:

I'm planning to change internal-definition expansion (anywhere that
says `body ...' in the Racket documentation) to allow expressions to
mingle with definitions. For example,

  (let ()
(define (f) x)
(displayln f)
(define x 1)
(list f x))

would be allowed; the `displayln' call would print `#procedure:f',
and the result would be a list containing the function `f' and the
number 1.

Some other changes related to internal-definitions have been suggested,
but I don't plan to implement them for now.

Long version:

Mixing Expressions and Definitions

Long ago, internal-definition positions in MzScheme allowed multiple
sets of definitions separated by expressions. For example,

 (let ()
   (define x 1)
   (display x)
   (define y 2)
   (display y))

was allowed. In that old mode, the definition of `y' started a new
group of definitions, so the right-hand side of `(define x ...)' could
not refer to `y'. In other words, the above was equivalent to

 (letrec ([x 1])
   (display x)
   (letrec ([y 2])
 (display y)))

I think this behavior mimicked Chez Scheme at the time, but I may be
mistaken. For whatever reason (I don't remember), we changed
internal-definition positions to now allow additional definitions after
an expression. Maybe it was to more closely match R5RS.

Meanwhile, `unit', `module', `class' and other forms evolved to allow
expressions mixed with definitions. Probably as a result, many have
suggested that internal definitions similarly allow expressions mixed
with definitions --- without the old grouping. In that case, the `let'
above would be equivalent to

 (letrec-values ([(x) 1]
 [() (begin (display x) (values))]
 [(y) 2])
   (display y))

This change seems like a good idea. Now that I've finally gotten around
to trying it out, I think we should go with it immediately.

Should an expression be required at the end? A `module', `unit', or
`class' body can consist of just definitions. Similarly, if an
internal-definition context ends with a definition, we could define the
result to be `(void)', which is what the `block' form does.

I think it's better to require an expression at the end, partly on the
grounds that the internal-definition block is supposed to return a
value (unlike the body of `module', etc.) and partly to avoid making
forms like

 (define (f x)
 (define (g y)

legal when they are almost certainly mistakes.

This change could be implemented in new `lambda', etc. bindings, but I
think existing forms in `racket' should change. Furthermore, to keep
things simple, the existing `scheme' forms --- most of which are the
same binding as the `racket' forms --- should also change.

The change should not affect the `r5rs' language, and we should change
the `r6rs' language so that it doesn't inherit the more liberal
handling of internal-definition forms.

There are no issues with backward-compatibility for existing `scheme'
and `racket' modules, as far as I can tell. The change would just
accept more modules.

More Internal-Definition Contexts

Internal definitions could be allowed in more places, such as

 (define f
   (define x 2)

In principle, where a single expression is expected, definitions could
be allowed to precede the expression.

It's a tempting generalization, but probably too confusing. I think
it's better to use some form that groups definitions with an
expression: `(let () )', `(block )', or something like that.

An Implicit Internal-Definitions Form

Many forms --- including `lambda' `let', and the function-shorthand
variant of `define' --- support internal definitions. The handling of
internal definitions is currently tired to the form.

An alternative would be to have those forms implicitly wrap a group of
internal-definition forms with `#%body', in much the same way that an
application form is converted to a use of `#%app'. Then, the treatment
of internal definitions could be independently configured through a
module import. For example, one module might use a `#%body' that
corresponds to the old handling of internal definitions, while another
module could import a `#%body' that corresponds to the new handling.

Setting aside the backward-compatibility issues of adding an implicit
form, I think it turns out not to work as well as `#%app'. The problem
is that there's not a good place to get the lexical context to use for
the implicit `#%body'. We have many macros analogous to

 (define-syntax-rule (squawk body ...)
 (displayln squawk!)
 (let () body ...)))

If you take the lexical context from the parentheses that surround the
`let' form, then the `#%body' is drawn from the context of the `squawk'
definition, while the intent was more likely to get it from the use of
`squawk'. Meanwhile, the `body ...' sequence 

Re: [racket-dev] proposal: `data' collection

2010-07-07 Thread Petey Aldous
That would be interesting and it would not be terribly difficult to
instrument setup-plt to do it.

I can't promise to have any time in the lab between now and the beginning of
my time at the University of Utah, so if you'd like it done anytime soon, I
won't be of much help.

- Petey

-Original Message-
From: Matthias Felleisen [mailto:matth...@ccs.neu.edu] 
Sent: Sunday, July 04, 2010 4:16 PM
To: Petey Aldous
Cc: 'Jay McCarthy'; 'Robby Findler'; dev@racket-lang.org
Subject: Re: [racket-dev] proposal: `data' collection

Wouldn't the more interesting thing be to measure the connectivity at the
collects level (not the files) and to discover cycles in this graph? --

On Jul 2, 2010, at 5:50 PM, Petey Aldous wrote:

 Here it is. This is a simplified dependency graph; rather than showing
file-to-file dependencies, it shows file dependencies from collection to
collection. Cheers!
 - Petey
 -Original Message-
 From: Jay McCarthy [mailto:jay.mccar...@gmail.com] 
 Sent: Friday, July 02, 2010 5:22 AM
 To: Robby Findler
 Cc: Eli Barzilay; dev@racket-lang.org; Petey Aldous
 Subject: Re: [racket-dev] proposal: `data' collection
 On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Those numbers seem pretty small in today's disk sizes, but I do agree
 that there is value in being able to divide up the distribution and to
 be able to stratify things so we can better keep track of our
 I feel like I routinely download programs and dev environments where
 the distribution is over 100MBs.
 (BTW, just a random question: have you thought about
 trying to visualize the collection-level dependencies with, say, dot?)
 My student did that. It is absurd. I'll CC him to get the image.
 It seems like you're after something that would allow multiple
 collections with the same name. Is that part of it, all of it, or
 mostly irrelevant to your main issue?
 On Fri, Jul 2, 2010 at 1:15 AM, Eli Barzilay e...@barzilay.org wrote:
 [Sorry for the late reply.]
 On Jun 30, Matthias Felleisen wrote:
 Which part is a symptom? My request for a description when there's
 no owner?
 The no-owner fact?
 The unstable collects?
 All of the above.
 Here are some questions that can demonstrate the problem better:
 1. What text would you expect to find in the purpose.txt file of
  `unstable'?  Of `data'?
 2. My course code is installed in a local collection named `pl'.  Why
  would I need to rename it if a new `pl' module was added to the
  racket distribution?
 3. Say that you want to install apache on your machine.  What would
  you think if your OS tells you that you need to install powerpoint
  for that?
 4. Assuming that there is a `data' collection with a few known data
  structures implemented, what happens when there's another data
  structure that happens to be just the thing for some project X
  and otherwise it's not too useful, or at least it seems that way.
  Why can't project X come with a new data/foo module?
 In any case, keep in mind that there is another way to make me stop
 saying coherent and package -- give up the idea of ever getting a
 smaller racket distribution, and the problem is solved.  We won't even
 need the distribution specs, since everything will be included...
 (From my POV, this would work out great since it looks like the
 general attitude towards it is that it's just something that *I*
 choose to be concerned with, and otherwise there's no problems.)
 For reference, here's a table of installer sizes (the Windows one,
 which has the highest compression) and source bundle size (the unix
 one, which has the highest compression in the sources bundles), with
 roughly one representative per year:
bin   src
 ver  year  size  size
  53  1998  2.6M
 103  2000  3.4M  4.6M
 200  2001  4.3M  6.7M
 203  2002  4.8M  6.0M
 205  2003  5.8M  7.6M
 209  2004  8.4M  11M
 300  2005  12M   13M
 372  2007  14M   15M
 4.0  2008  22M   14M
 4.2  2009  25M   15M
 5.0  2010  28M   16M
 ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
   http://barzilay.org/   Maze is Life!
 For list-related administrative tasks:
 For list-related administrative tasks:
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 The glory of God is Intelligence - DC 93
  For list-related administrative tasks:

  For list-related administrative tasks:

Re: [racket-dev] internal-definition parsing

2010-07-07 Thread Eli Barzilay
On Jul  7, Matthew Flatt wrote:
 Short version:
 I'm planning to change internal-definition expansion (anywhere that
 says `body ...' in the Racket documentation) to allow expressions to
 mingle with definitions. For example,


On Jul  7, Matthias Felleisen wrote:
 4. I am vaguely interested in #%body because I have a hunch that
there are yet more possibilities. But at the same time, I
understand your objection and I can only see a limited utility of
#%body now. (That doesn't mean much, because I originally failed
to appreciate #%module-begin.)

I have a very conceret interest in that.  Is there any concrete
example for something that would go wrong with it now?

What bugs me often is that playing around with a different semantics
for body sequences is currently very tedious -- I have to redefine
`lambda', `let', `define', and their (many) relatives (even things
like `for' etc, if it should be complete), and in practice it always
ends up being a half-assed job instead...

Some examples that show how useful this is:

  * In the lazy language you want the implicit begin to force all
expressions except for the last one.

  * I've redefined the implicit begin (in an ugly way) for my course
language to force all non-tail expressions to have a `Void' type.

  * The scribble/text language should really return a list of all
values instead of just the last one.  It currently provides `text'
that builds on `begin/collect', which allows each block of
consecutive definitions to be mutually recursive -- this is now a
problem in that it's different in a subtle way than the default
implicit begin.

I think that a good goal is to have all of these uses available as
simple macro definitions.

If you take the lazy use as an example, then just a single `#%body'
thing is not enough: since it needs to force only expressions, then
having a `#%body' means that it will need to do its own crawling over
the expressions to find which ones are not definitions and force
them.  So it looks like another special #% macro would be needed, and
even that is not enough to implement the last one conveniently, since
it needs to collect all non-definition expressions and combine them.

  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
  For list-related administrative tasks: