Re: [racket-dev] internal-definition parsing
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, > [...] Nice! 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: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposal: `data' collection
On Jul 6, Petey Aldous wrote:
> That would be interesting and it would not be terribly difficult to
> instrument setup-plt to do it.
There's no reason to do that -- the data is all there in the dep
files. It just needs to be trimmed for the collection name instead of
the full paths.
I'm attaching a file with a list of all toplevel collections and a has
table that maps collection names to what they depend on. I tried to
visualize this with graphviz in a number of ways -- and there was
nothing that producing a graph that would make sense. I then wrote
some code and there's two groups of collections -- one huge ball of
code that is all inter-dependent, and then a bunch of collections that
are nearly free of dependency problems. The only problem in the
latter group is teachpacks and deinprogramm which form a cycle.
So, the unproblematic set of collects is:
2htdp, afm, algol60, combinator-parser, datalog, defaults,
embedded-gui, eopl, frtime, gui-debugger, guibuilder, handin-client,
handin-server, hierlist, honu, lazy, macro-debugger, make, mysterx,
mzcom, plai, plot, preprocessor, racklog, redex, repo-time-stamp,
schemeunit, sgl, sirmail, slatex, srpersist, swindle,
test-box-recovery, tex2page, waterworld, games, tests, meta
it would work fine to install them one by one in this order, except
for {teachpack, deinprogramm} which are their own set.
The problematic set of collects is:
racket, at-exp, browser, compiler, config, drracket, drscheme,
dynext, errortrace, ffi, file, framework, graphics, help, htdp,
html, icons, lang, launcher, mred, mrlib, mzlib, mzscheme, net,
openssl, parser-tools, planet, profile, r5rs, r6rs, rackunit, raco,
reader, readline, rnrs, s-exp, scheme, scribble, scribblings,
scriblib, setup, slideshow, srfi, stepper, string-constants, syntax,
syntax-color, test-engine, texpict, trace, typed, typed-scheme,
unstable, version, web-server, wxme, xml
deps.rktd
Description: Binary data
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposal: `data' collection
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? -- Matthias 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 > 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 >> dependencies. > > 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. > > Jay > >> >> 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? >> >> Robby >> >> On Fri, Jul 2, 2010 at 1:15 AM, Eli Barzilay 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: >>> http://lists.racket-lang.org/listinfo/dev >>> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 >
Re: [racket-dev] internal-definition parsing
At Wed, 7 Jul 2010 13:13:31 -0400, Matthias Felleisen wrote: > > 1. My most important concern is that begin-with-definitions takes Nx times > more time to expand than the current body expander. Are you going to use this > macro or are you going to bake it all into the implementation? The latter, so there's no slowdown. > 2. My second one is one of internal interest. In principle all 'body' forms > should be expanded in one single place and this should be a single point of > change here. Is this correct? Yes. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] internal-definition parsing
1. My most important concern is that begin-with-definitions takes Nx times more time to expand than the current body expander. Are you going to use this macro or are you going to bake it all into the implementation? 2. My second one is one of internal interest. In principle all 'body' forms should be expanded in one single place and this should be a single point of change here. Is this correct? 3. Historically our original form borrowed from Algol. I don't think Chez had this liberal notion. 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.) -- Matthias On Jul 7, 2010, at 12:23 PM, 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, > > (let () >(define (f) x) >(displayln f) >(define x 1) >(list f x)) > > would be allowed; the `displayln' call would print `#', > 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) > x > (define (g y) > 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) > x) > > 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 impli
Re: [racket-dev] internal-definition parsing
Yeah! (And I think you're right about not having an implicit #%body, but I don't really know for sure.) Robby On Wed, Jul 7, 2010 at 11:23 AM, 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, > > (let () > (define (f) x) > (displayln f) > (define x 1) > (list f x)) > > would be allowed; the `displayln' call would print `#', > 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) > x > (define (g y) > 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) > x) > > 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
[racket-dev] internal-definition parsing
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 `#', 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) x (define (g y) 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) x) 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 ...) (begin (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 itself doesn'
