[racket] TR Submodules

[Ray Racine]

#lang typed/racket

(provide x)

(module M typed/racket
  (provide x)
  (define: x : Natural 3))

(require (submod "."  M))

;; end-of-file

Submodules don't work in TR (at least the above variation).  I added a few debug statements and it does appear the when requiring a submodule defined within the enclosing file it fact TR attempts to dynamic-require the current source file/module again.

i.e. It fails to recognize that referenced submodule is _not_ in an external source file file, but is defined within the current source/module.

I pointed out awhile back and I sort of got the impression that there was something foundationally deeper that the core team was going to have to address.  But it seems a fix would be something along the lines of 'don't (re)dynamic-require a submodule path with a "." in it '.

Has anyone had a chance to look into this yet?  I'd love to use submodules in TR.

Thanks,

Ray

[Neil Toronto]

On 11/18/2012 07:02 PM, Ray Racine wrote:
> #lang typed/racket
>
> (provide x)
>
> (module M typed/racket
> (provide x)
> (define: x : Natural 3))
>
> (require (submod "." M))
>
> ;; end-of-file
>

>...

>
> Has anyone had a chance to look into this yet? I'd love to use
> submodules in TR.

As a workaround, you can change the parent module's language to "racket"
and your specific example will work just fine. You don't have to worry
about extra contract checks, because the identifier `x' won't have a
contract on it unless it's used in untyped code, even though it's
provided by untyped code.

IOW, if your parent module above is named "x.rkt", you can write this:

#lang typed/racket
(require "x.rkt")
x

TR is smart enough to not put a contract on `x'. (I don't think it would
in this case anyway, but pretend `x' is a function. It still wouldn't
have a contract.)

The array library uses typed submodules a lot, mostly to define typed
values and untyped macros that expand to those values in the same file.
I did have to split files in a few cases, because I ran into problems
having two typed submodules in the same parent module.

I'll let someone else explain that fundamental problem that seems to
require rewriting the macro expander to fix it. I also won't speculate
on whether that will happen soon.

Neil ⊥

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Ray Racine]

I'd originally written some cooperating macros in untyped Racket using granularly structured in submodules as many aspects ended up being required at meta 0 and reused again at meta 1 for the macros.  That was pretty seamless.

When I tried to TR things I started to hit the submodule issue.  However as Neil indicated if you avoid having TR submodules in a TR language top level module, and when necessary refactor things into their own source file, it all works out.  Not quite as neat if submodules worked completely in all their glory, but all-in-all not bad.   

In other words I was able to do everything a needed/wanted to do with regard to syntax/parse macros in TR.  I had a few palpitations going in on whether one could write macros in TR code which expanded into TR syntax.  Turns out it all works quite smoothly other than the noted submodule issue.

TR + Syntax/Parse is the shiniest of new hammers, must resist making everything a macro.  Or not.

[Sam Tobin-Hochstadt]

On Sun, Nov 18, 2012 at 9:02 PM, Ray Racine <ray.r...@gmail.com> wrote:
> #lang typed/racket
>
> (provide x)
>
> (module M typed/racket
> (provide x)
> (define: x : Natural 3))
>
> (require (submod "." M))
>
> ;; end-of-file
>
> Submodules don't work in TR (at least the above variation). I added a few
> debug statements and it does appear the when requiring a submodule defined
> within the enclosing file it fact TR attempts to dynamic-require the current
> source file/module again.

This program works correctly for me in DrRacket and racket (built
yesterday). What problem are you seeing?

--
sam th
sa...@ccs.neu.edu

[Ray Racine]

Did a quick sync and build and I'm seeing a Racket internal error on launching DR.
Error invoking tool #<path:/usr/local/racket/collects/drracket>;"syncheck.rkt"

Error invoking tool #<path:/usr/local/racket/collects/drracket>;"syncheck.rkt"

UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1167]


UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1167]

[Matthew Flatt]

Can you try `raco setup -c' followed by `raco setup'?

I fixed bugs in the bytecode compiler, and I forgot to increment the
version number to make sure that bytecode files are rebuilt.

[Ray Racine]

OK, the DR build issue is gone.

But the following in DR.

#lang typed/racket

(provide x)

(module M typed/racket
  (provide x)
  (define: x : Natural 3))

(require (submod "."  M))

x

;; end

Give me the following when run:

. . ../../usr/local/racket/collects/typed-racket/env/env-req.rkt:9:4: standard-module-name-resolver: cycle in loading
  at path: /home/ray/test.rkt
  paths:
   /home/ray/test.rk

[Sam Tobin-Hochstadt]

On Mon, Nov 19, 2012 at 11:04 AM, Ray Racine <ray.r...@gmail.com> wrote:
> OK, the DR build issue is gone.
>
> But the following in DR.
>
>
>
> #lang typed/racket
>
> (provide x)
>
> (module M typed/racket
> (provide x)
> (define: x : Natural 3))
>
> (require (submod "." M))
>
> x
>
> ;; end
>
> Give me the following when run:
>
> . . ../../usr/local/racket/collects/typed-racket/env/env-req.rkt:9:4:
> standard-module-name-resolver: cycle in loading
> at path: /home/ray/test.rkt
> paths:

> /home/ray/test.rkt

I believe that this is a problem in Racket, which Matthew believes
will require significant changes in the expander. Unfortunately, that
means we won't have a fix that soon.

[Matthias Felleisen]

Shouldn't this problem be documented with Typed Racket? I believe we have had several inquiries concerning this problem.