Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Matthias Felleisen

On Jul 7, 2010, at 5:55 PM, Eli Barzilay wrote:

 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.


1. Three distinct examples (plus Algol, which could benefit too) sound like 
enough. 

2. I do not understand why #%body isn't enough. Couldn't #%body locally expand 
to the point where defs and exps are distinguished? 

3. Also, I am beginning to wonder whether the right name is #%block-begin of 
#%body-begin 

4. The next thing to consider is whether #%module-begin and #%block-begin are 
truly separate features. In a sense, we now should say that modules are just 
bodies. Or is there a difference? 

-- Matthias



_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


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

2010-07-08 Thread Matthias Felleisen

This sounds like we should give up on stratification. 


On Jul 7, 2010, at 5:21 PM, Eli Barzilay wrote:

 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
 -- 
  ((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] internal-definition parsing

2010-07-08 Thread Jay McCarthy
On Thu, Jul 8, 2010 at 11:19 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 On Jul 7, 2010, at 5:55 PM, Eli Barzilay wrote:

 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.


 1. Three distinct examples (plus Algol, which could benefit too) sound like 
 enough.

 2. I do not understand why #%body isn't enough. Couldn't #%body locally 
 expand to the point where defs and exps are distinguished?

 3. Also, I am beginning to wonder whether the right name is #%block-begin of 
 #%body-begin

 4. The next thing to consider is whether #%module-begin and #%block-begin are 
 truly separate features. In a sense, we now should say that modules are just 
 bodies. Or is there a difference?

#%module-begin as the top level controlling macro is a distinguishing
feature. Requires and provides can only be there and you know there's
only one application.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

The glory of God is Intelligence - DC 93
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Matthias Felleisen

On Jul 8, 2010, at 12:09 PM, Jay McCarthy wrote:

 #%module-begin as the top level controlling macro is a distinguishing
 feature. Requires and provides can only be there and you know there's
 only one application.

These could be an argument to the #%...-begin macro: 

 are-you-top-level? :: (U false (interface Provides Requires))

-- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-07-08 Thread Eli Barzilay
On Jul  8, Matthias Felleisen wrote:
 
 2. I do not understand why #%body isn't enough. Couldn't #%body
locally expand to the point where defs and exps are
distinguished?

Yes, it could -- and I guess that would be in analogy to
`#%module-begin'.  But I generally don't like that macros that need to
distinguish definitions from expressions need to do that work in that
context too -- it's delicate enough that it shouldn't be left to the
good enough instinct of leaving partial solutions.  (In the
`#%module-begin' case, a common result of this instinct is matching on
expressions that use `define', without expanding them, or expanding
them without dealing with macros.)


 3. Also, I am beginning to wonder whether the right name is
#%block-begin of #%body-begin
 
 4. The next thing to consider is whether #%module-begin and
#%block-begin are truly separate features. In a sense, we now
should say that modules are just bodies. Or is there a
difference?

It could be the same macro with (syntax-local-context) distinguishing
the two...  It might even make sense to do so in some cases where a
similar macro is needed in both (as with the lazy case).

-- 
  ((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] internal-definition parsing

2010-07-08 Thread Eli Barzilay
On Jul  8, Matthias Felleisen wrote:
 On Jul 8, 2010, at 12:09 PM, Jay McCarthy wrote:
 
  #%module-begin as the top level controlling macro is a distinguishing
  feature. Requires and provides can only be there and you know there's
  only one application.
 
 These could be an argument to the #%...-begin macro: 
 
  are-you-top-level? :: (U false (interface Provides Requires))

(It could also be an argument for making local requires more
accessible...)

-- 
  ((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