At Wed, 6 Jun 2012 13:32:19 -0400, Sam Tobin-Hochstadt wrote:
However, we can't just
add `module*` to the stop list at the moment, because if anything is
in the stop list, then all the core forms are added, and then we
wouldn't fully expand the program.
However, I think we can relax this
At Fri, 9 Mar 2012 17:21:26 -0700, Matthew Flatt wrote:
At Fri, 9 Mar 2012 15:58:11 -0700, Jay McCarthy wrote:
I just pushed...
- module**
Like module* but combines multiple occurrences of the same submodule
name into one module*
I like this direction --- and like everyone, I
Yes, dependencies abound if we include tests and doc in the same module. At the
same time it is good practice to have things together.
Can't this problem be solved with module-flattening tools? From what I can
tell, these test and doc modules could be dropped leaving the running residual,
The current demodularizer would do that. Presumably we could make a
tool that operated on a single module's zo and removed such
submodules. The main problem would be that the source is
un-compilable.
Jay
On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Yes,
Sorry Matthias, I don't think I understand your question.
At the bytecode level, it would be easy, so we could change the
distribution scripts to do that.
At the source level, it's not really possible because of macros that
generate code in a submodule.
My personal taste is that it is bad to
Why does it not compile? Do you mean it doesn't compile to the same byte codes?
On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote:
Sorry Matthias, I don't think I understand your question.
At the bytecode level, it would be easy, so we could change the
distribution scripts to do that.
He's saying that there is no easy way to, without expanding the code
(and perhaps without going one step further beyond a fully expanded
program, but nevermind that detail), split apart the submodules that
come from a single module. You just cannot tell, without expanding
everything, which of the
I know that. But we could consider the pruning step as part of compilation.
On Mar 12, 2012, at 2:57 PM, Robby Findler wrote:
He's saying that there is no easy way to, without expanding the code
(and perhaps without going one step further beyond a fully expanded
program, but nevermind that
Yes, I think the point that Jay's making is that the thing you'd
distribute wouldn't be rkt code, but some low-level thing. Well,
either that or you distribute .rkt code that doesn't actually run.
Robby
On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
I know
Or you make the pruning step a part of the compiler.
On Mar 12, 2012, at 3:01 PM, Robby Findler wrote:
Yes, I think the point that Jay's making is that the thing you'd
distribute wouldn't be rkt code, but some low-level thing. Well,
either that or you distribute .rkt code that doesn't
Yes: In other words, there could be a parameter that causes the macro
expander to drop `test' submodules before it even attempts to expand
them --- roughly like not using `-g' with `gcc'.
Meanwhile, the after-the-fact pruning tool could be called `raco
strip'.
At Mon, 12 Mar 2012 15:02:58 -0400,
Ya, even if someone does their best by moving dependencies into the
tightest module*, there is a compilation problem:
m.rk
#lang racket
(module* test #f
(require tests/eli-tester))
simply does not compile if tests/eli-tester is not there. If you did
compile it but didn't instantiate the test
Oh, I get it now. Thanks.
This also seems like something that you'd want to put control over at
the package level, I guess. That is, a package can depend on another
package, but without that second package's test modules or something.
Robby
On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt
I thought Matthew was pointing out how we can distribute some source
that works if you set a parameter properly and that same source will
contain no test-based dependencies.
Boy, this conversation sure makes me wish for the ability to just
gather everyone up around a whiteboard or something :(
I agree with Robby.
Jay
On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
I thought Matthew was pointing out how we can distribute some source
that works if you set a parameter properly and that same source will
contain no test-based dependencies.
Boy, this
On Mar 10, 2012, at 6:26 PM, Eli Barzilay wrote:
I first
thought that the whole point of allowing a sub-`module' would be to
have some otherwise-inaccessible private code in it (as the fictitious
author of that `my-code' module thinks).
I second this impression, as I have done in previous
At Sat, 10 Mar 2012 18:26:52 -0500, Eli Barzilay wrote:
Perhaps a more obvious question is why aren't all `submod' uses get
. as an implicit first expression?
I don't see how lets you reach a submodule from the top level or from
within a different top-level module.
So, this is the
An hour and a half ago, Matthew Flatt wrote:
If I understand what you mean, then all of the interesting uses I
see involve extracting a submodule from the outside:
* Extracting the `reader' submodule of a given module.
* Running a `main' submodule of a given module.
* Running a
I agree with your point #1 heartily.
I don't follow point #2. Do you mean that currently by having two
files the tests can depend on things that the code does not (for
purposes of distribution, etc) and having those tests embedded in the
files increases the cross-collection dependencies as well
Just now, Jay McCarthy wrote:
I agree with your point #1 heartily.
I don't follow point #2. Do you mean that currently by having two
files the tests can depend on things that the code does not (for
purposes of distribution, etc) and having those tests embedded in
the files increases the
Two days ago, Matthew Flatt wrote:
I don't think that explicit `module' or `module*' forms will be that
common. Instead, I expect that they'll mostly be generated by
macros, such as a `main' macro or Jay's `define-test' macro. But if
they become common, or if we often want to re-export an
Yesterday, Matthew Flatt wrote:
At Fri, 9 Mar 2012 16:35:25 -0500, Eli Barzilay wrote:
(require (submod 'zoo monkey-house))
[...] a shorthand for `(submod . zoo)' [...]
...especially here -- why is there a quote only on the first and not
on the second?
That jumped out at
At Wed, 7 Mar 2012 10:14:35 -0700, Matthew Flatt wrote:
I've added submodules to a version of Racket labeled v5.2.900.1
Submodules are now pushed to the Racket git repo.
I haven't yet added a syntactic form to simplify
(module* main #f
)
My first idea was `main', as in
(main
I'll pushed an improved version of the test macro shortly.
Jay
On Fri, Mar 9, 2012 at 11:04 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Wed, 7 Mar 2012 10:14:35 -0700, Matthew Flatt wrote:
I've added submodules to a version of Racket labeled v5.2.900.1
Submodules are now pushed to the
[Some of these points may have come up earlier, I just didn't want to
lose comments so reply as I read it.]
[To be clear in advance, the following should be qualified by an I
love it.]
Two days ago, Matthew Flatt wrote:
Given the term submodule, the first thing that you're likely to try
I just pushed...
- module**
Like module* but combines multiple occurrences of the same submodule
name into one module*
- when-testing
An abbreviation of module** with the name test and the #f language
- raco test
Finds all the files in a directory and requires their test module
I like the
On Fri, Mar 9, 2012 at 5:58 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
I just pushed...
- module**
Like module* but combines multiple occurrences of the same submodule
name into one module*
- when-testing
An abbreviation of module** with the name test and the #f language
- raco
Just now, Jay McCarthy wrote:
I just pushed...
- module**
Like module* but combines multiple occurrences of the same submodule
name into one module*
But... it adds more stars... I don't think that there's any need for
a convenience macro that does just the combining, since that feature
A few minutes ago, Eli Barzilay wrote:
[...] Here's what I have in mind:
(Other things were broken there...)
Here's the code that works now:
(sub tests (require tests/eli-tester)) ; make it known before main
(sub main (printf Welcome to MY library!\n))
(define (plus x y) (+ x y))
At Fri, 9 Mar 2012 15:58:11 -0700, Jay McCarthy wrote:
I just pushed...
- module**
Like module* but combines multiple occurrences of the same submodule
name into one module*
I like this direction --- and like everyone, I wish for a better name.
I don't like `submodule' or `sub' for this,
I'll reply to the rest later, but two quick ones:
Just now, Matthew Flatt wrote:
How about just (submodule foo ...) be a more memorable syntax for
(module* foo #f ...)?
That was Jon's suggestion, and my objection is that submodule
means something more general than those nested modules
On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
I intend to change DrDr so that it always uses raco test -r rather
than racket -t.
I assume you mean just changing the defaults. Will this resulting in
running any less code?
--
sam th
sa...@ccs.neu.edu
Yes, just changing the default.
raco test -r will behave like racket -t unless there is a test
submodule, in which case, it will actually run the tests.
Jay
On Fri, Mar 9, 2012 at 10:04 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy
I've made a test collecting macro.
https://gist.github.com/2003201
test.rkt gives you 'define-test'
(define-test id e ...)
will create a module named 'test' that can see you local bindings
(like module* #f) at the end of the module that contains all the code
in e In addition, you get the
One more thing, I anticipate that the 'main' module in my test.rkt
will be raco test and I would extend it to allow you to give a
directory that it will require (if present) all the test modules.
You could also have Test button in DrRacket.
Jay
On Thu, Mar 8, 2012 at 1:29 PM, Jay McCarthy
This sounds great! I haven't tried it out yet, but here are some
preliminary comments.
On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote:
Submodules declared with `module' are declared locally while expanding
a module body, which means that the submodules can be `require'd
afterward by the
On Thu, Mar 8, 2012 at 1:41 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
Maybe a pattern that could avoid this is to have something like
#lang racket/main
#:main driver.rkt
#:tests tests.rkt
which would bring in the given modules (in the filesystem) as
submodules. That way you could
At Thu, 8 Mar 2012 15:41:38 -0500, Asumu Takikawa wrote:
This sounds great! I haven't tried it out yet, but here are some
preliminary comments.
On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote:
Submodules declared with `module' are declared locally while expanding
a module body, which
Nice -- just what I wished for last spring. -- Matthias
On Mar 8, 2012, at 3:39 PM, Jay McCarthy wrote:
One more thing, I anticipate that the 'main' module in my test.rkt
will be raco test and I would extend it to allow you to give a
directory that it will require (if present) all the test
39 matches
Mail list logo
