6 hours ago, Sam Tobin-Hochstadt wrote:
>
> > Also, Sam: can you explain what "externally visible" means in this
> > context?
>
> Just that we don't typically require `redex/tests` or
> `drracket/scribblings` into other modules written outside of those
> collections, whereas for `typed/file`, for example, the whole point
> is to be used outside of the `typed` collection.
In case it wasn't clear -- while the rule in that case is relatively
simple, I still think that having `redex/tests' and
`drracket/scribblings' makes much more sense. I take it as "it just
happened" that some of these things are in the current directories,
and really, new packages should have all their belongings in one
place.
(More high-level view later on, in reply to Matthias's point.)
Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote:
>
> One difference between these cases is that they're done by programs,
> not by people. For me, being able to tell programmers the rule that
> "if you want the typed version of collection X, it's typed/X" is
> valuable. [...]
It's important to have uniform rules in both cases. This is why I
dislike your new addition, which has a single file instead of
following the directory hierarchy. I understand where it's coming
from -- you want `typed/FV' to be the same as `FV' for requires, but
in terms of directory hierarchy, it should be in "typed/FV/main.rkt",
which makes a need for revising the distibution code.
6 hours ago, Robby Findler wrote:
>
> I always thought that racket/typed is the more forward-looking name.
> But I think it is fine to leave that alone and have two rules (in
> the interest of progress).
>
> We start to get into backwards compatibility issues, tho. So maybe
> the right thing is to decide that x/typed is better than typed/x but
> treat the existing set of things as existing for backwards
> compatibility (and thus do require path munging to make existing
> programs not break).
+1 on both points.
6 hours ago, Matthias Felleisen wrote:
>
> Extensibility really needs a matrix and eventually cubes. Is it
> possible to think along these lines, really big?
[This part is long, but I think that it's worth reading over and reach
a conclusion instead of rehashing this N more times.]
The summary:
In theory you're right if X/Y is code that deals with both X issues
and Y issues. For example, it's a question whether a typed lazy
language should live in `lazy/typed' or `typed/lazy', and it's a
question if some `foo' that is written in this language then which
permutation of `lazy', `typed', and `foo' it should be in.
But in practice, all of the cases we have ("tests", "scribblings",
and now "typed") are things that are at a high level so there's an
obvious decision where to put the code. IOW, some `typed/foo' code
is related to Sam in that he implemented TR and the initial version
of the file, but the file should be owned by `foo'. Similarly, in
the above case of a lazy typed foo, it's clear that the `foo' part
is important since that *is* the library so whoever implemented
`foo' would implement the other or at least maintain a contributed
version of it -- which means that it should clearly be in `foo/L/TR'
or `foo/TR/L'.
More verbiage:
In theory it does, since when you're talking about something like
"foo/bar" you really mean some code that both the "foo" person and the
"bar" person are responsible for, and will possibly have a dialog for
its implementation. In this case, we have "typed/FV" which involves
both Sam and James, and in other cases we have "scribblings/foo" and
"tests/foo".
But in practice, I think that there's a very clear advantage for doing
thins the other way: "FV/typed", "foo/scribblings", and "foo/tests".
Each of this should be inspected individually:
* "tests" are something generic that is done independently of each
other, and there is no single "tests magician" that you'd consult.
So having a toplevel "tests" is (IMO) no more than an artifact of a
project that started small with a single set of tests -- and now the
view *should* be that it's a bunch of projects all maintained in a
single repository, so there's no sense in a single "tests".
* "scribblings" was never intended for more than the few "core"
documentations that are there, and I think that several of them can
and should move out into their respective proper homes. (IIRC,
there was only some technical problem with "scribblings/scribble".)
This is mostly similar to the above. There is a small difference in
that there is a scribble magician, but with enough existing
documentation on scribble and enough samples to look at, the
magician role is not too important, so I should be expected to
maintain my own documentation.
* "typed" is the newcomer to these kind of meta-properties. Here
there is a very obvious magician called Sam, one that has created
*all* of the contents there. Yet the code there is a description of
the original author's code -- so it does belong to the original
author, it just happens that Sam created that code. In fact this is
not just a theoretic point, IIRC, there were a few cases where
`typed/foo' was not updated when `foo' did, simply because the `foo'
author wasn't aware of that other code. (Or in my case, because of
advanced senility and an overuse of "grep".)
Another way to see why `foo/*' makes sense is to consider what happens
when some of these sub-projects leave the main repository. They
become their own repositories, and in terms of installing them onto
the main tree, it is far easier to drag a single directory in than
throw a bunch of additional files around. This is not only important
for going towards such moving of code outside (which I think is
ultimately inevitable) it's also because this way you get the
immediate benefit of treating these directories in a very similar way
that you'd treat other project that are not in our tree ATM.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
