[racket-dev] [plt] Push #25419: master branch updated

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 <samth at 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!