Re: [racket-dev] A basic package system

2011-07-27 Thread Robby Findler
Bullet point 2 seems like it may overlap (in a practical, what do I
use today sort of a way) with Matthew's modulelet construct. Both
group modules together, both provide independently loadable things.

Do we really want/need both of these?

Robby

On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 Eli and I had a very useful conversation last night and we realized
 that a lot of the ideal package system we are imagining is within our
 reach very quickly. Today I made a demonstration of our ideas:

 https://github.com/jeapostrophe/exp/tree/master/pkgs

 There's a README there. Once you read it,

 Run use/program.rkt

 Then edit use/pkg-in.rkt and change the safe to unsafe

 You'll see that it changes the meaning of racket/listy module
 reference in use/program.rkt

 I haven't implemented the module algebra, but it should be clear from
 looking at the macro implementations that the existing identifier
 algebra in require/provide will work transparently.

 Jay

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

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


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

Re: [racket-dev] A basic package system

2011-07-27 Thread Robby Findler
They have more similarities than your message suggests I believe. And it is
probably worth exploring that. As far as I can see a facet/modulet has less
stuff than a package and possibly a different story vis a vis files in the
filesystem.

Robby

On Wednesday, July 27, 2011, Jay McCarthy jay.mccar...@gmail.com wrote:
 I don't see them as overlapping, but you may understand them different
 than I do.

 The way I see modules/facets is that 'racket/list.rkt' will have a
 'default' facet and a 'testing' facet and a 'documentation' facet, so
 that each use can be syntactically close but separately loadable.

 The way I see packages is that they allow indirection of module paths,
 so that inside 'a.rkt', 'racket/list' can refer to something other
 than the usual thing because of what package it is inside. Packages
 also allow module privacy in a way we don't provide now, because some
 modules may not be provided from the package, even though they are
 inside it.

 So... do you think those two understandings overlap? Or do you
 understand them differently?

 Jay

 On Wed, Jul 27, 2011 at 7:52 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Bullet point 2 seems like it may overlap (in a practical, what do I
 use today sort of a way) with Matthew's modulelet construct. Both
 group modules together, both provide independently loadable things.

 Do we really want/need both of these?

 Robby

 On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com
wrote:
 Eli and I had a very useful conversation last night and we realized
 that a lot of the ideal package system we are imagining is within our
 reach very quickly. Today I made a demonstration of our ideas:

 https://github.com/jeapostrophe/exp/tree/master/pkgs

 There's a README there. Once you read it,

 Run use/program.rkt

 Then edit use/pkg-in.rkt and change the safe to unsafe

 You'll see that it changes the meaning of racket/listy module
 reference in use/program.rkt

 I haven't implemented the module algebra, but it should be clear from
 looking at the macro implementations that the existing identifier
 algebra in require/provide will work transparently.

 Jay

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

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





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

 The glory of God is Intelligence - DC 93

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

Re: [racket-dev] A basic package system

2011-07-27 Thread Eli Barzilay
10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

They're really unrelated -- the new thing with
facets/modulets/whatever name they get is a kind of a separately
loadable sub-module.  What we were talking about is basically making
the `foo' in (require foo) be an identifier that you could define to
actually point to some random file.

-- 
  ((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] A basic package system

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

Would a binding for foo affect uses like foo/bar?  And would this mean
going to a semantics for require specs where unbound identifiers have
one meaning, and bound identifiers have another?  That leads to issues
with silent failures, where you try to refer to a binding but a typo
leads to the wrong require instead of a syntax error.  Also, right now
I can do (define racket Racket) and then (require racket) and it
works fine.  If require starts looking at bindings, suddenly the
collection namespace becomes part of the normal Racket namespace.

--Carl

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


Re: [racket-dev] A basic package system

2011-07-27 Thread Jay McCarthy
On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

 Would a binding for foo affect uses like foo/bar?  And would this mean
 going to a semantics for require specs where unbound identifiers have
 one meaning, and bound identifiers have another?  That leads to issues
 with silent failures, where you try to refer to a binding but a typo
 leads to the wrong require instead of a syntax error.  Also, right now
 I can do (define racket Racket) and then (require racket) and it
 works fine.  If require starts looking at bindings, suddenly the
 collection namespace becomes part of the normal Racket namespace.

I just want id-require-transformers. Right now we have
require-transformers but there's no reason we couldn't/shouldn't have
id macros too.

(define racket Racket) is not problem because it's a phase-0,
non-require-transformer binding.

Using these macros this way is just a nice way to implement the
package system. It's not really a new feature (as my example shows...
we already have it.)

Jay



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

The glory of God is Intelligence - DC 93

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

Re: [racket-dev] A basic package system

2011-07-27 Thread Carl Eastlund
On Thu, Jul 28, 2011 at 12:35 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
 On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

 Would a binding for foo affect uses like foo/bar?  And would this mean
 going to a semantics for require specs where unbound identifiers have
 one meaning, and bound identifiers have another?  That leads to issues
 with silent failures, where you try to refer to a binding but a typo
 leads to the wrong require instead of a syntax error.  Also, right now
 I can do (define racket Racket) and then (require racket) and it
 works fine.  If require starts looking at bindings, suddenly the
 collection namespace becomes part of the normal Racket namespace.

 I just want id-require-transformers. Right now we have
 require-transformers but there's no reason we couldn't/shouldn't have
 id macros too.

I would say that the silent failure mode is a reason not to.  The only
other place I can think of where we allow both bound and unbound
identifiers, and interpret them differently, is syntax templates.  I
don't think of a require spec as a template -- mostly data with a few,
special, overriding references -- I generally expect each name to have
a single unambiguous meaning.

 (define racket Racket) is not problem because it's a phase-0,
 non-require-transformer binding.

Require transformers are at phase 0, too.  Or are you suggesting that
we interpret bound names if they are require transformers, but not if
they're something else?  Once again, only templates behave that way.
It would be very odd to me to treat require specs as mostly data, with
a few special, overriding bindings, rather than as a type of
expression where each name has a single meaning.

 Using these macros this way is just a nice way to implement the
 package system. It's not really a new feature (as my example shows...
 we already have it.)

We already have require macros for application positions because all
application positions in require specs are interpreted as bindings.
All identifier-only positions are interpreted as data and used as
collection names.  In general, Racket macros avoid mixing data and
expressions (anything that interprets bindings), because it leads to
very confusing behavior.  This is similar to why cond has a binding
for else rather than using its symbolic name, and even more directly
similar to why match does not have id transformers either.

--Carl

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


[racket-dev] A basic package system

2011-07-26 Thread Jay McCarthy
Eli and I had a very useful conversation last night and we realized
that a lot of the ideal package system we are imagining is within our
reach very quickly. Today I made a demonstration of our ideas:

https://github.com/jeapostrophe/exp/tree/master/pkgs

There's a README there. Once you read it,

Run use/program.rkt

Then edit use/pkg-in.rkt and change the safe to unsafe

You'll see that it changes the meaning of racket/listy module
reference in use/program.rkt

I haven't implemented the module algebra, but it should be clear from
looking at the macro implementations that the existing identifier
algebra in require/provide will work transparently.

Jay

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

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


Re: [racket-dev] A basic package system

2011-07-26 Thread Matthias Felleisen

It's probably just me, but this readme is a bit too dense. 
[I know the first bit. That's why I pushed the two-step. 
I know a bit more from Eli. But that's an accident.]


On Jul 26, 2011, at 5:49 PM, Jay McCarthy wrote:

 Eli and I had a very useful conversation last night and we realized
 that a lot of the ideal package system we are imagining is within our
 reach very quickly. Today I made a demonstration of our ideas:
 
 https://github.com/jeapostrophe/exp/tree/master/pkgs
 
 There's a README there. Once you read it,
 
 Run use/program.rkt
 
 Then edit use/pkg-in.rkt and change the safe to unsafe
 
 You'll see that it changes the meaning of racket/listy module
 reference in use/program.rkt
 
 I haven't implemented the module algebra, but it should be clear from
 looking at the macro implementations that the existing identifier
 algebra in require/provide will work transparently.
 
 Jay
 
 -- 
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay
 
 The glory of God is Intelligence - DC 93
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

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