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 thi
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 e
On Monday, Matthias Felleisen wrote:
>
> I think Jay is expressing an Eli-concern: we need to distribute the
> full source to determine whether something can be thrown away.
It's more than just the dependencies between libraries -- it's the
fact that expanding the code (before "stripping", but se
I agree with Robby.
Jay
On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler
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 conversation sure makes
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 :(
Ro
I think Jay is expressing an Eli-concern: we need to distribute
the full source to determine whether something can be thrown away.
On Mar 12, 2012, at 3:13 PM, Robby Findler wrote:
> Oh, I get it now. Thanks.
>
> This also seems like something that you'd want to put control over at
> the pac
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 wrote:
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 m
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,
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 ac
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
wrote:
>
> I know that. But we could cons
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 th
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
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 tha
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 s
On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote:
> 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.
Meaning? Removing docs and tests shou
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
wrote:
>
> Yes, dependencies abound if w
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,
whi
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 th
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 as
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
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.
>
>
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 previ
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?
>
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 a
On Sat, Mar 10, 2012 at 11:00 AM, Matthias Felleisen
wrote:
>
> Two minor notes:
>
> 1. .. is a valid binding *SL
>
> 2. I would much prefer 'section' over 'slice'. Think of projects as books,
> modules as chapters, which consist of sections, and we may even have a need
> for paragraphs one day.
>
Two minor notes:
1. .. is a valid binding *SL
2. I would much prefer 'section' over 'slice'. Think of projects as books,
modules as chapters, which consist of sections, and we may even have a need for
paragraphs one day.
_
Racket Developers list:
http://lists.r
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 wrote:
> On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy wrote:
>>
>> I intend to c
On Fri, Mar 9, 2012 at 9:54 PM, Jay McCarthy 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
_
R
I've renamed
module* to slice
and removed its ability to specify a language other than #f (maybe it
could be a #:keyword later)
I've removed when-testing because (slice test ...) is shorter than
(begin-for-testing test ...) [which, btw Carl, is the best name.]
I've expanded 'raco test' to suppo
30 minutes ago, Matthew Flatt wrote:
>
> How about `facet', with the terminology that "facets" are
> implemented as "submodules"?
I like using a different term with just that explanation (ie, "a facet
is a particular kind of a submodule").
But I still don't like `facet' -- not only because of my
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 mo
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
At Fri, 9 Mar 2012 16:35:25 -0500, Eli Barzilay wrote:
> Two days ago, Matthew Flatt wrote:
> >
> > Given the term "submodule", the first thing that you're likely to try
> > will work as expected:
> >
> > #lang racket/base
> >
> > (module zoo racket/base
> > (provide tiger)
> > (defi
Some more comments:
* There's probably a better way to collect the expression lists than
set!-ing it.
* `sub' is probably a bad name, though `submodule' looks too long for
this.
[
* I should have said earlier that if there's a `when-testing' then the
bad result is adding a `when-in-main'
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))
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 feat
On Fri, Mar 9, 2012 at 5:58 PM, Jay McCarthy 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 test
>
> Find
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 na
[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
30 minutes ago, Jay McCarthy wrote:
> I'll pushed an improved version of the test macro shortly.
Please don't put it in `racket/test', since it's not a testing thing.
(I haven't got to reply to that yet, but it looks like a more general
convenience macro for pulling some expressions into a submod
What about specially treating the #:main keyword when it appears in a
module top-level. Everything that follows it gets wrapped in a
(module* main #f), perhaps with #:niam as an end delimiter. Or maybe
#:submodule , if it appears at the top-level of a module could
mean that. Or maybe all new syntax
I'll pushed an improved version of the test macro shortly.
Jay
On Fri, Mar 9, 2012 at 11:04 AM, Matthew Flatt 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 Racket git repo
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
.
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 th
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, w
On Thu, Mar 8, 2012 at 1:41 PM, Asumu Takikawa 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 define sub
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 e
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
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 t
I love it---especially for the test collecting macro.
I will try to write it and report back.
Jay
On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt wrote:
> I've added "submodules" to a version of Racket labeled v5.2.900.1
> that's here:
>
> https://github.com/mflatt/submodules
>
> After we've so
51 matches
Mail list logo
