RE: [racket-users] submodule order dependency

2016-03-22 Thread Jos Koot
Hi Matthias,
Thanks,
I did see that part of the docs, but overlooked the word "preceding".
Apologies for my noise.
On second thought, I agree with the choice of order,
because comparing with 'define' (in a non-lazy language) we can't allow:
(define b a)
(define a 'whatever)
So indeed, the choice of order as has been made seems more natural.
Thanks again,
Jos
 

-Original Message-
From: Matthias Felleisen [mailto:matth...@ccs.neu.edu] 
Sent: martes, 22 de marzo de 2016 17:13
To: Jos Koot
Cc: 'Racket Users'
Subject: Re: [racket-users] submodule order dependency


On Mar 22, 2016, at 8:47 AM, Jos Koot <jos.k...@gmail.com> wrote:

> The following works in the definitions window of DrRacket:
>  
> #lang racket
> (module a racket (display 'dog))
> (module b racket (require (submod ".." a)))
> (require 'b)
>  
> Display 'dog' when run.
>  
> But reversing the order of the submodules a and b does not work:
>  
> #lang racket
> (module b racket (require (submod ".." a)))
> (module a racket (display 'dog))
> (require 'b)
>  
> Gives already before running (background expansion enabled):
> require: unknown module module name: #<resolved-module-path:(submod
'anonymous-module a)>
>  
> May be this order dependency is documented, but I could not find it.
> If it is not documented, should'nt this order dependency be included in
the docs?


Reference, evaluation model, 1.1.10.5:

 "A submodule declared with module can import any preceding submodule
declared with module."



> It would be nice to allow a submodule to require a submodule yet to
follow,
> just like the body of a procedure definition may refer to a procedure yet
to be defined.
> I can imagin that it would be impossible, or at least difficult, to remove
the order dependency.


Remember that modules cannot refer to each other in a mutually recursive
manner. 
What might want to argue for is that the order is reversed. I can see the
advantage
of that and I definitely need this for plain defines. For submodules I have
wanted this
at first but after years of programming with them, I have come to the
conclusion that
what we have is fine. Either order would have worked, the one we have is a
bit more
natural than the other way round. 

-- Matthais

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] submodule order dependency

2016-03-22 Thread Matthias Felleisen

On Mar 22, 2016, at 8:47 AM, Jos Koot  wrote:

> The following works in the definitions window of DrRacket:
>  
> #lang racket
> (module a racket (display 'dog))
> (module b racket (require (submod ".." a)))
> (require 'b)
>  
> Display 'dog' when run.
>  
> But reversing the order of the submodules a and b does not work:
>  
> #lang racket
> (module b racket (require (submod ".." a)))
> (module a racket (display 'dog))
> (require 'b)
>  
> Gives already before running (background expansion enabled):
> require: unknown module module name: # 'anonymous-module a)>
>  
> May be this order dependency is documented, but I could not find it.
> If it is not documented, should'nt this order dependency be included in the 
> docs?


Reference, evaluation model, 1.1.10.5:

 "A submodule declared with module can import any preceding submodule declared 
with module."



> It would be nice to allow a submodule to require a submodule yet to follow,
> just like the body of a procedure definition may refer to a procedure yet to 
> be defined.
> I can imagin that it would be impossible, or at least difficult, to remove 
> the order dependency.


Remember that modules cannot refer to each other in a mutually recursive 
manner. 
What might want to argue for is that the order is reversed. I can see the 
advantage
of that and I definitely need this for plain defines. For submodules I have 
wanted this
at first but after years of programming with them, I have come to the 
conclusion that
what we have is fine. Either order would have worked, the one we have is a bit 
more
natural than the other way round. 

-- Matthais

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.