On Mon, Jul 2, 2012 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
Thoughts so far:
I think you need a new communication channel to get information from
the expansion of an enclosing module to the expansion of its submodule.
Expansion-time state is the right kind of channel, but I think
At Tue, 3 Jul 2012 11:05:52 -0400, Sam Tobin-Hochstadt wrote:
However, I don't (yet) think it's the right solution. In particular,
I feel like this moves away from the really great feature of
submodules, which is that they behave basically exactly like regular
modules. From what I can tell,
On Tue, Jul 3, 2012 at 11:08 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 3 Jul 2012 11:05:52 -0400, Sam Tobin-Hochstadt wrote:
However, I don't (yet) think it's the right solution. In particular,
I feel like this moves away from the really great feature of
submodules, which is that
On Mon, Jul 2, 2012 at 9:22 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Is it possible there is another channel that TR could use to
communicate these types? That is, could it not expand
(: f Integer)
(define f 5)
into something that bound 'f' to a macro that knows its type? I
At Tue, 3 Jul 2012 11:14:10 -0400, Sam Tobin-Hochstadt wrote:
On Tue, Jul 3, 2012 at 11:08 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 3 Jul 2012 11:05:52 -0400, Sam Tobin-Hochstadt wrote:
However, I don't (yet) think it's the right solution. In particular,
I feel like this moves
Thoughts so far:
I think you need a new communication channel to get information from
the expansion of an enclosing module to the expansion of its submodule.
Expansion-time state is the right kind of channel, but I think it's
important to start every submodule's expansion in a fresh store, at
Is it possible there is another channel that TR could use to
communicate these types? That is, could it not expand
(: f Integer)
(define f 5)
into something that bound 'f' to a macro that knows its type? I guess
it already does that, so something doesn't work about that here, but
I'm not
The expansion of submodules is intended to have a fresh store, just
like the expansion of any module. The `#f' initial import is intended
to be something like using `(submod ..)' as the initial language,
except importing all internal bindings of the module instead of its
exports.
Can Typed Racket
On Mon, Jun 25, 2012 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
The expansion of submodules is intended to have a fresh store, just
like the expansion of any module. The `#f' initial import is intended
to be something like using `(submod ..)' as the initial language,
except importing
I think I misunderstood your complaint. If you change the example to
(module+ sub
(#%module-begin (m)))
then there's no error. So, I think you're running into the old
only-form-in-module-just-might-expand-to-#%module-begin problem.
The usual solution is form `m' to check whether it's
On Mon, Jun 25, 2012 at 5:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I think I misunderstood your complaint. If you change the example to
(module+ sub
(#%module-begin (m)))
then there's no error. So, I think you're running into the old
At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote:
The problem (I
think) is that the implicit `require` of `(submod ..)` happens
*before* the expansion of `#%module-begin` inside the submodule.
That's the same for a top-level module M whose initial language is some
other module L,
Sam, can you focus on cases of submodules for which you can guarantee that
#%module-begin is okay and reject others [with an explicit, informative error
message]? -- Matthias
On Jun 25, 2012, at 6:47 PM, Matthew Flatt wrote:
At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote:
On Mon, Jun 25, 2012 at 6:53 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Sam, can you focus on cases of submodules for which you can guarantee that
#%module-begin is okay and reject others [with an explicit, informative error
message]? -- Matthias
I'm not entirely sure what you mean
14 matches
Mail list logo
