collection, module, library, package, project, installed, catalog ... nomenclature question

[Thomas Lynch]

I suspect there is an opportunity to tighten up the use of these terms.  Starting out I'm looking at module-basics.scrbl where all of these terms appear.

I suggest reading the whole of this post before commenting, as in places it suggests concrete reads of things, and then goes back and asks about alternative reads.

To start off with, the only concrete proposal in this post, does this look useful/correct? :

A module is a programmer defined grouping of syntax objects which defines bindings and
access to those bindings. A module may be defined implicitly by putting the syntax
belonging to the module together in a file.  The name of the file is then taken as the
name of the module.  Modules may also be defined explicitly using the @racket[module]
form.

For example, suppose the file @filepath{cake.rkt} defines a module: ...

I gather there is no way to list modules?  One might wish for something like raco module show or some such.  Using 'ls -R' on a directory gets the files, which is close.   Also, no way to list the modules and their dependencies?  Or perhaps all this is in DrRacket, and this geiser just didn't see it ..

The module defines syntax groupings within the context of racket, which is a little different than a file within a file system (which is place to put bits).   It would be good to understand the term 'collection' in a parallel manner, though corresponding to a subdirectory tree rather than a file.

The section organizing modules sets the stage for this.  So I gather that within that discussion it would make sense to interject at some point that such the organization of modules being described is called a collection.

Just as the file system may be used as a container for collections (via the vehicle of subdirectory trees) -- is it the case that a package may also be called a container for one or more collections?  I suppose a package would have some additional information?  Now a collection is a container for modules, so I wonder, is not a collection of collections really just a bigger collection?  Then the distinction between collection and package is one of context.  A collection is functionally defined form the point of view of the language, indeed implied by the syntax - in particular that of the path syntax in require;  while a package is a utility used for transferring and installing collections.

In the context of racket,  what does 'library' mean?  Dearsay it seems that in some places modules are called libraries, and in other places collections are called libraries, and in yet other places the term library seems to indicate that something is installed in a standard place.  We also see the term 'installed' used.  Particularly to distinguish between quoted and unquoted paths in require statements.  However, all software is installed, rather this term seems to mean that there is a process for binding modules to the unquoted path names in require - this process is then called 'installing'.  

So trying to put this together.   In racket then, there is a unique special place called "The Library".  One may place collections in The Library, by installing them via a packet manager command.   Then "library modules" (i.e modules found within a collection within The Library)  may be accessed via unquoted path names embedded in require syntax.   We then nix the terms 'installed module'  and instead use 'library module'.  Installing is then a process for copying collections from packages and putting them in The Library.  It would make sense to point at a package and say that it has been installed -- this would mean that the contained collections are in "The Library".  Are there other processes for putting a module into The Library?  

Now by this nomenclature every racket installation would have a standard library that comes with racket version x, and then installation specific additions to that library added by the administrator later.   So now we have 'standard library' specific to a racket version, and 'local library' specific to an installation.   Is this accurate?  However, in this doc though the term library is used, we are never told about The Library, a distribution specific 'standard' library, or a local library.  Would this be summarily rejected, or if done nicely, be useful?

The argument of require is a series of identifiers separated by slashes with special meaning whether it is in quotes or not. The last identifier indicates a module by name.  The first identifier is the collection name.   The string as a whole is called the collection relative module pathname ?? is that correct?   And the string except for the last identifier (except for the module name)  is called ??  It is analogous to a directory, but directory is a file system terminology.  We might call it a module path, distinguished from a module pathname, Or is this too subtle. Perhaps "relative module location with respect to the collection top" for the prefix to the module name?

Can collections contain collections?  My sense is no.  However, if there can be collections in collections then there is a top collection, and sub-collections, etc.  Then listing collections in The Library  only gives the top level collections.  We also then have to wonder where in the collection tree installation puts things when we install a package.

Though the term library is used, in the current nomenclature refers to installed packages, but an installed package is a package we can point at and say 'hey that was installed'  rather than a directory we can point at and say 'hey that is a library of collections'.  These two things live in different place.  Indeed I'm likely to delete an installed package because it takes up disk space and all I need is the library.   Or is it the case, that a package is not like a conventional zip file, but that the racket uses it even after installation?  The catalog apparently lists paths to collections?

Now we have a catalog of collections, is this the same as a library?  So we don't have a special place where things go as part of an installation process, but rather the installation process inserts an file pathname into a catalog and this locates the collection.  But what distinguishes a collection from a package at that point.   I could have a zipped collection, that I unzip, then install.  

There you go .. that is the walk I took through the docs trying to get my head around these terms.  

[Thomas Lynch]

project as a term is also mentioned in module-basics.  Does this term have a technical meaning in racket, or was it being used in the colloquial?  If it is technical racket centric, what is it?

[Thomas Lynch]

editing a bit ... suggest this instead:

A module is a programmer defined grouping of syntax objects. The syntax in a module

defines bindings, access rules for other modules to see the bindings, and dependenices on

other modules. A module may be defined implicitly by putting the sytax belonging to the

module in a file.  The name of the file is then taken as the name of the module.  Modules

may also be defined explicitly using the @racket[module] form.

For example, suppose the file @filepath{cake.rkt} defines a module:

On Thursday, April 30, 2015 at 6:11:05 PM UTC+8, Thomas Lynch wrote:

[Thomas Lynch]

^sytax^syntax

[Matthew Flatt]

At Thu, 30 Apr 2015 03:11:05 -0700 (PDT), Thomas Lynch wrote:
>
> I suspect there is an opportunity to tighten up the use of these terms.

I'm enthusiastic about this effort to improve terminology! For now,
I'll try to offer clarifications on the current intent --- although I
don't expect to get even that completely right here.

> To start off with, the only concrete proposal in this post, does this look
> useful/correct? :
>
> A module is a programmer defined grouping of syntax objects which
> defines bindings and access to those bindings. A module may be
> defined implicitly by putting the syntax belonging to the module
> together in a file. The name of the file is then taken as the name of
> the module. Modules may also be defined explicitly using the
> @racket[module] form.

Ok. I'd use the word "declared" instead of "defined" for modules.

> I gather there is no way to list modules? One might wish for something
> like raco module show or some such. Using 'ls -R' on a directory gets the
> files, which is close. Also, no way to list the modules and their
> dependencies? Or perhaps all this is in DrRacket, and this geiser just
> didn't see it ..

It's possible to enumerate collection-based module paths by inspecting
`current-library-collection-paths`, etc., but there's no tool for that
so far, I think.

> The module defines syntax groupings within the context of racket, which is
> a little different than a file within a file system (which is place to put
> bits). It would be good to understand the term 'collection' in a parallel
> manner, though corresponding to a subdirectory tree rather than a file.
>
> The section organizing modules sets the stage for this. So I gather that
> within that discussion it would make sense to interject at some point that

> such the organization of modules being described is called a *collection*.

Yes.

> Just as the file system may be used as a container for collections (via the
> vehicle of subdirectory trees) -- is it the case that a package may also be
> called a container for one or more collections? I suppose a package would
> have some additional information? Now a collection is a container for
> modules, so I wonder, is not a collection of collections really just a
> bigger collection? Then the distinction between collection and package is
> one of context. A collection is functionally defined form the point of
> view of the language, indeed implied by the syntax - in particular that of
> the path syntax in require; while a package is a utility used for
> transferring and installing collections.

Yes, mostly.

One detail is that multiple packages can have different modules that
are in the same collection. For example, the "gui-lib" package includes
modules in the "racket" collection, specifically the "racket/gui"
subcollection. So, when we say that a package provides a collection,
it's a shorthand for a more precise statement: a package provides a set
of modules that are organized via collections.

> In the context of racket, what does 'library' mean?

I use "library" to refer to a module --- particularly one that is meant
to be access via `require`. Other modules I refer to as "languages" ---
the ones meant to be referenced via `#lang`. I think "library" and
"language" together cover all "module"s.

See also 4.2.1 in the Scribble manual (which is probably not the right
place for that information, but no one has moved it to the overall
Racket style guide, so far.)

> Dearsay it seems that
> in some places modules are called libraries, and in other places
> collections are called libraries, and in yet other places the term library
> seems to indicate that something is installed in a standard place.

Can you point to a place where "library" refers to a collection? That
sounds like a mistake to me.

> We also
> see the term 'installed' used. Particularly to distinguish between quoted
> and unquoted paths in require statements. However, all software is
> installed, rather this term seems to mean that there is a process for
> binding modules to the unquoted path names in require - this process is
> then called 'installing'.

That's the intent, although you're getting to an area where the
terminology is less precise in my mind.

> So trying to put this together. In racket then, there is a unique special
> place called "The Library". One may place collections in The Library, by
> installing them via a packet manager command. Then "library modules" (i.e
> modules found within a collection within The Library) may be accessed via
> unquoted path names embedded in require syntax. We then nix the terms

> 'installed module' and instead use 'library module'. *Installing *is then

> a process for copying collections from packages and putting them in The
> Library. It would make sense to point at a package and say that it has
> been installed -- this would mean that the contained collections are in
> "The Library".

I like the idea of having a name for this concept, but since I (intend
to) consistently use "library" as a subset of "module", I'm not
enthusiastic about calling it "The Library".

> Are there other processes for putting a module into The
> Library?

There's `raco link`, and the PLTCOLLECTS environment variable can point
to additional collection-containing directories. Those other methods
are not common or encouraged, though.

> Now by this nomenclature every racket installation would have a standard
> library that comes with racket version x, and then installation specific
> additions to that library added by the administrator later. So now we
> have 'standard library' specific to a racket version, and 'local library'
> specific to an installation. Is this accurate? However, in this doc
> though the term library is used, we are never told about The Library, a
> distribution specific 'standard' library, or a local library. Would this
> be summarily rejected, or if done nicely, be useful?

I'm not enthusiastic about the "standard" part of "standard library".
We use the phrase "main distribution" to refer to the set of packages
(and therefore modules, as organized into collections) that you get
from the current download at download.racket-lang.org.

> The argument of *require *is a series of identifiers separated by slashes

> with special meaning whether it is in quotes or not. The last identifier
> indicates a module by name. The first identifier is the collection name.
> The string as a whole is called the collection relative module pathname ??
> is that correct? And the string except for the last identifier (except
> for the module name) is called ?? It is analogous to a directory, but

> directory is a file system terminology. We might call it a *module path*,
> distinguished from a *module pathname*, Or is this too subtle. Perhaps

> "relative module location with respect to the collection top" for the
> prefix to the module name?

A reference to an module is a module path. I agree that the usual forms
of reference are "collection-based module paths".

I don't think there are good terms for pieces of various module-path
forms, and it's tricker than distinguishing pieces before and after a
"/". For example, the module path `racket` refers to the "main.rkt"
module within the "racket" collection.

> Can collections contain collections? My sense is no. However, if there
> can be collections in collections then there is a top collection, and
> sub-collections, etc. Then listing collections in The Library only gives
> the top level collections. We also then have to wonder where in the
> collection tree installation puts things when we install a package.

Collections can contain collections. We do sometimes call the contained
ones "subcollections".

> Though the term library is used, in the current nomenclature refers to
> installed packages, but an installed package is a package we can point at
> and say 'hey that was installed' rather than a directory we can point at
> and say 'hey that is a library of collections'. These two things live in
> different place. Indeed I'm likely to delete an installed package because
> it takes up disk space and all I need is the library. Or is it the case,
> that a package is not like a conventional zip file, but that the racket
> uses it even after installation?

You're right that there's a useful distinction between "package" as an
implementation that you can install and "package" as something that is
already installed. I tend to use "package implementation" for the
former and "installed package" for the latter, but I doubt that we have
consistent terminology here.

When you install a package by referring to a ".zip" file, the installed
package does not refer back to the ".zip" file. The same is true if you
refer to a directory and use `--copy`, but the default behavior of
referring to a directory is to link it directly as an installed package.

> The catalog apparently lists paths to
> collections?

I think the terminology here is relatively well defined (see chapter 2
of "Package Management in Racket"): a catalog is a mapping from package
names to package sources, where a package source is a reference to a
package implementation.

> Now we have a catalog of collections, is this the same as a library?

Hopefully it's clear from the above that I think this is a misuse of
"catalog" and "library".

> So we
> don't have a special place where things go as part of an installation
> process, but rather the installation process inserts an file pathname into
> a catalog and this locates the collection. But what distinguishes a
> collection from a package at that point. I could have a zipped
> collection, that I unzip, then install.

I think you're trying to get at the idea of the mapping from module
paths to the filesystem --- as in "The Library", where we don't have a
name for it, and it would be nice to have one.

[Thomas Lynch]

On Thursday, April 30, 2015 at 9:00:08 PM UTC+8, mflatt wrote:

I'm enthusiastic about this effort to improve terminology! For now,

Great 

 

Ok. I'd use the word "declared" instead of "defined" for modules.

alright

 

> The section organizing modules sets the stage for this.  So I gather that
> within that discussion it would make sense to interject at some point that
> such the organization of modules being described is called a *collection*.

Yes.

I'll make a mod for that.

 

> In the context of racket,  what does 'library' mean?

I use "library" to refer to a module --- particularly one that is meant

See also 4.2.1 in the Scribble manual (which is probably not the right
place for that information, but no one has moved it to the overall
Racket style guide, so far.)

ok I'll look at that and move the material
 

> Dearsay it seems that
> in some places modules are called libraries, and in other places
> collections are called libraries, and in yet other places the term library
> seems to indicate that something is installed in a standard place.

Can you point to a place where "library" refers to a collection? That
sounds like a mistake to me.

Got this impression from the heading name "6.1.2 Library Collections", though the text in that section then

talks about library modules ( library as opposed to non-library?  so library modules make library collections but non-library modules make for ? ..)

 

[Thomas Lynch]

for the rest of this, I think I better study this some more before typing too much on the docs.  I'll just try to get this into module-basics for the new reader (such as myself).

Thanks for that understanding of library. 

 The term 'standard lib' made me wince when I wrote it, just didn't know a better way to say it.   Main distribution collection.  Thanks.  And the collections installed later?  Perhaps add-on collections or some such?  Then taken together the collections with modules that can be accessed without quotes (or via #lang)  are  ___ collections.   

If for the blank we insert installed collections, then there is conflation with install as a process, and as an adjective for a package or other file that was used in that process (as described earlier).  It is even difficult to disambiguate with an explanation.  Seems like the term used for this concept in other language contexts is library.   User stuff, and library stuff.   hmm main distribution library.  Additional libraries.     Access library stuff with unquoted arg on require, or #lang.   But library has another meaning already.

How about 'native collections' and 'local collections'.   Native collections come in two flavors, main distribution, and contributed.  A collection is made native through the process of installing it.  If it is installed via adding a directory to the catalog then the installed collection can not be deleted as racket will use it directly.  If it is installed via a package, then the installed package can be deleted.   native/local  .. other word pairs can work here.  suggestions?  

So then when talking about native/local or installation, emphasis is on collections rather than on modules.  The understanding is that the module inherits its native/local status by virtue of 'being in the collection'.  If it is in a native collection then when using require is accessed without quotes.  If it is local then it is accessed with quotes.  

... though there is a nuance with packages where installation might take a scatter shot and put modules in more than one collection.  Still only native modules will be affected.

Would this native/local thing be good racket speak?

[Robby Findler]

Thomas: thank you for helping to clean all this up! It's quite welcome.

One thing to consider: if it is at all possible, I think it would be
good if we tried to focus on a distinction between collections from
ring-0 packages and those that aren't instead of a distinction between
collections from pkgs that come from particular authors. That is, one
thing we'd like to do is to make distinctions between pkgs that work
well and those that don't instead of distinctions between pkgs that
come from centralized place or are distinguished only because of some
notion of "privilege", instead of some approximation to "quality".

Robby

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/9c9689ed-76a6-47ec-99f4-97e366f5f01f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Greg Hendershott]

I also found this confusing when becoming familiar with Racket.

1. I wonder if some diagram(s) could help organize this cluster of
concepts with has-a and is-a(-kind-of) relations?

2.

>> So trying to put this together. In racket then, there is a unique special
>> place called "The Library". One may place collections in The Library, by
>> installing them via a packet manager command. Then "library modules" (i.e
>> modules found within a collection within The Library) may be accessed via
>> unquoted path names embedded in require syntax. We then nix the terms
>> 'installed module' and instead use 'library module'. *Installing *is then
>> a process for copying collections from packages and putting them in The
>> Library. It would make sense to point at a package and say that it has
>> been installed -- this would mean that the contained collections are in
>> "The Library".
>
> I like the idea of having a name for this concept, but since I (intend
> to) consistently use "library" as a subset of "module", I'm not
> enthusiastic about calling it "The Library".

At the risk of bike-shed-naming (naming is hard, and everyone has an opinion):

Inventory
Cornucopia
Treasury
Locker
Trove

I suppose in the Racket/Scheme tradition it should allude to a cache
of dubiously-acquired gains, loot or plunder. :) Some of the above are
close to that but not perfect.

[Thomas Lynch]

stash

stash of native collections ..

[Anthony Carrico]

On 04/30/2015 10:20 PM, Thomas Lynch wrote:
> stash
>
> stash of native collections ..

I'm not sure you can reduce the confusion by adding yet another name to
the list. Isn't "the installed packages", or "the set of installed
packages" ok?

--
Anthony Carrico

[Thomas Lynch]

Anthony noted the problem of ambiguity of this term in the posts above.  .. please don't make me repeat all of that ..

[Thomas Lynch]

Robby, I don't know if this is good enough, but I was considering, based on Matt's feedback,  to call your ring-0 packages  "main distribution collections" and those that might be a bit suspect and still attribute to individuals, rather than being blessed as part of the distributions, as "contributed collections".   I'm suggesting placing emphasis on 'collection'  rather than package, as I see a package as a vehicle for distributing collections (for the most part).  Other vehicles also exist for making collections native to the installation.  Accordingly one would be able to say things like "if you want the X collection, then go get the Y package - that is the best way to do it.  ... The Y package will also give you the Z collection, and the A and B modules that will be added to .."

  Don't know, this nomenclatures seems to work for what you are getting at.

[Robby Findler]

That sounds like the right distinction (but where the blessedness of
ring-0 is as documented here:
http://docs.racket-lang.org/pkg/Future_Plans.html). But to avoid
proliferation of names, I think we should either say "a collection
from a ring-0 pkg" or find a shorter way to express that concept that
uses some similar of those words instead of using new words.

And the ring-0 concept is independent of our current distribution. The
pkg system is designed to make it easy to make alternative
distributions that include different sets of pkgs for use in different
contexts. Really the only stable concept related to "the official
distribution" should be if the pkg is in ring 0 or not.

Overall, I think we should move away from terminology that suggests a
distinction based on a centralized storehouse of "standard" packages,
as much as we reasonably can. Does this make sense?

Robby

On Fri, May 1, 2015 at 8:01 AM, Thomas Lynch

> https://groups.google.com/d/msgid/racket-dev/2f51a866-5a4b-4c2e-9b63-bd4b8a5c678e%40googlegroups.com.

[Thomas Lynch]

Robby, 

A package is a vehicle for carrying collections. It is not the only such vehicle.  It is the collections, or rather the modules in them, which have code and thus need versions.  The modules typically inherit their version from the collection.

Currently there is no way to directly attached arbitrary property information to a collection.  When a collection is contained in a subdirectory tree, we take the subdirectory name as the name of the collection (name property). But what of the version number?  When a collection is contained in a package, we take the suffix of the package name as the version number of the collection (version property).  As packages can hold multiple collections and extensions to collections, such groups can also be given version properties in this manner.  (Or is there a more direct method, is there some mechanism for attaching properties within the package management system itself?)

You explain here that associated with each collection name and version (or collection of collections and extensions) there is a maturity property with possible value of ring-0, ring-1, or ring-2.  This association is currently done via external accounting.  Perhaps in the future there will be a more formal method of adding properties to collections, or the package naming convention will be modified to embed the information, or perhaps not.

Is it the case that the maturity value (ring-0, ring-1, ring-2) is a strong indicator, but does not decide, which collections are included in the a (version level) main distribution? I.e. that distribution choice and ring-0 assignment are not identical?

Asked another way, when I do 'apt-get install racket',  or an analogous command, do no further installation commands (fresh out of the box),  and then use (require X) in a module,  with no quotes around the X,  then can I know for certain that X is a module that was found in a collection that comes from a ring-0 package?    Also, is it true that for all X modules blessed with the property of being ring 0, X can be reached in this manner, or via #lang?

I would imagine the answer to this question is no, that the maturity grades do not exactly determine what is included in the distribution, but rather guide users in the reliability of the packages that in some cases they may or may not chose to install.   If so then it would be proper to refer to 'main distribution collections'  with the strong implication that the included collections are ring-0 stuff, but probably not all of ring-0 stuff, and gosh, perhaps a ring-1 collection is included for something new but very important.

It would be interesting information for me as an application developer who is using racket to know that distributions come with only ring-0 packages, that there are other ring-0 packages that have been contributed which I might go get, and other ring-1 or ring-2 packages out there which I might experiment with.

Or is the whole idea that if a collection is blessed as being 'ring-0'  for racket version Q that determines it is included in the distribution for racket version Q?

yeah, so the answer to these questions will help me tweak the doc mods I've made that refer to the 'main distribution collections'.   Thanks!

[Thomas Lynch]

p.s.  prior post, that is test language asking for verification not an explanation of how it is.  .. tone changed during editing, sorry abt that..

[Thomas Lynch]

perhaps what would be good is a file that appears at the top level of a collection and provides a property value list.  Perhaps something like:

prop-vals.rkt:

(intrinsic-collection-properties-hook

  '(name "splat.rkt")

  '(version "1.45")

  '(maturity ring-2)

  '(extended-by "big-deal/charles.rkt"  (added "charles-favs.rkt"))

)

[Matthew Flatt]

At Fri, 1 May 2015 18:11:20 -0700 (PDT), Thomas Lynch wrote:
> Currently there is no way to directly attached arbitrary property
> information to a collection.

An "info.rkt" file serves that role, where the `setup/getinfo` library
provides the API for querying "info.rkt" files. (The "info.rkt" format
is also used for package information. For single-collection packages,
it's the same file.)

Well, maybe it's little more complicated than that. In general,
multiple directories can be installed and spliced together as the
content of a collection. Each "info.rkt" file can have information
that's specific to it's particular piece of a collection.

In any case, collections don't have versions, ring levels, etc. Those
are properties of packages.

> Asked another way, when I do 'apt-get install racket', or an analogous
> command, do no further installation commands (fresh out of the box),

I think you're needlessly avoiding some terminology that we do have.
You mean "when I install a main distribution of Racket...".

> and
> then use (require X) in a module, with no quotes around the X, then can I
> know for certain that X is a module that was found in a collection that
> comes from a ring-0 package?

All packages in the main distribution are ring-0 packages.

> Also, is it true that for all X modules
> blessed with the property of being ring 0, X can be reached in this manner,
> or via #lang?

Not all ring-0 packages are in the main distribution.


> [...] 'main distribution collections'

I think "main distribution collections" is not going to work as a
concept, because packages other than those in the main distribution can
add to collections that are also represented in the main distribution.
That's why ring levels and such are package concepts, as opposed to
collection concepts.

> It would be interesting information for me as an application developer who
> is using racket to know that distributions come with only ring-0 packages,
> that there are other ring-0 packages that have been contributed which I
> might go get, and other ring-1 or ring-2 packages out there which I might
> experiment with.

That's all correct, at least where "distributions" is "main
distribution". (I don't know of any other distributions, yet.)

[Thomas Lynch]

On Saturday, May 2, 2015 at 10:16:23 AM UTC+8, mflatt wrote:

At Fri, 1 May 2015 18:11:20 -0700 (PDT), Thomas Lynch wrote:
> Currently there is no way to directly attached arbitrary property
> information to a collection.

An "info.rkt" file serves that role, where the `setup/getinfo` library
provides the API for querying "info.rkt" files. (The "info.rkt" format
is also used for package information. For single-collection packages,
it's the same file.)

Here is the info.rkt file for /usr/share/racket/pkgs/plot/

#lang info

(define collection 'multi)

(define deps '("plot-lib" "plot-gui-lib" "plot-doc"))

(define implies '("plot-lib" "plot-gui-lib" "plot-doc"))

(define pkg-desc "Functions (and docs and tests) for plotting")

(define pkg-authors '(ntoronto))

No mention of a version. I guess maturity will go here?  But yes, excuse me, no need of a separate file for properties as there already is one.  ... Sure looks to me like there is conflation between the terms collection and package.  

Well, maybe it's little more complicated than that. In general,
multiple directories can be installed and spliced together as the
content of a collection. Each "info.rkt" file can have information
that's specific to it's particular piece of a collection.

In any case, collections don't have versions, ring levels, etc. Those
are properties of packages.

ah, so in racket I can't have versions attached to my source code (collection)?  gosh  So if I install via package, and install via directory, I'm not allowed to know if the two are the same version by checking the info.rkt file?  May do diffs, but then what I wanted to know, say, how far apart they would be in version space.

 

> Asked another way, when I do 'apt-get install racket',  or an analogous
> command, do no further installation commands (fresh out of the box),

I think you're needlessly avoiding some terminology that we do have.
You mean "when I install a main distribution of Racket...".

I purposely avoided the terminology as I find it inconsistent and conflated.  That is probably because I'm dense and or haven't studied it enough.  So I phrased the question in a manner as to get an answer without having to interpret the terms .. sigh .. don't see an answer.

 

> and
> then use (require X) in a module,  with no quotes around the X,  then can I
> know for certain that X is a module that was found in a collection that
> comes from a ring-0 package?

All packages in the main distribution are ring-0 packages.

But not all ring-0 packages are in the main distribution -- so the answer to my question is that they are not identical.  That would mean that Robby's suggestion of not using the term 'main distribution X's'  is unnecessary and ring-0 is preferable is not possible (as the two are not identical).

 

> Also, is it true that for all X modules
> blessed with the property of being ring 0, X can be reached in this manner,
> or via #lang?

Not all ring-0 packages are in the main distribution.

=>  ring-0 Xs not equal to main distribution Xs.  So two terms are needed.

 

> [...] 'main distribution collections'

I think "main distribution collections" is not going to work as a
concept, because packages other than those in the main distribution can
add to collections that are also represented in the main distribution.
That's why ring levels and such are package concepts, as opposed to
collection concepts.

hmm .. but if installing a contributors package modifies collections in the main distribution -- then that modified collection is no longer part of the main distribution.  I miss the contradiction. 

Indeed if my nice trusted ring-0 main distribution collection is modified by installing a lower ring contribution, not only is the collection no longer a main distribution collection, but it is also no longer a ring-0 collection - indeed it should even have a different version .. and shouldn't info.rkt tell me this happened?

----

Ok, so I've got the idea here, and that is the subject is outside my comprehension.  I sure don't want to send this discussion in circles because I'm being dense. I just hope that the chat was worthwhile.  That doesn't hold me back from using racket though.  It is pretty easy to install packages.  It is the adding them that I'm not read for.  Alas.  Thanks for your patience.

 

[Robby Findler]

Hi Thomas: thank you for your energy and interest in clearing up the
terminology. I find this quite valuable. There is a certain amount of
prescriptiveness that's coming through in your messages that makes it
a little more difficult than need be to answer your questions. So I
wish to pop out a level here at the top of this message to point out
that the pkg system design has had quite a lot of thought put into its
concepts and while no one disagrees that we can explain them better, I
think that perhaps we should focus on explaining and understanding
them first and then changing them second.

One place that I think help help is if you were to read the pkg system
terminology documentation. Did you find that already? It's here:
http://docs.racket-lang.org/pkg/Package_Concepts.html

Some lower-level comments are interleaved below.

On Fri, May 1, 2015 at 10:51 PM, Thomas Lynch
<thomas...@reasoningtechnology.com> wrote:
>
>
> On Saturday, May 2, 2015 at 10:16:23 AM UTC+8, mflatt wrote:
>>
>> At Fri, 1 May 2015 18:11:20 -0700 (PDT), Thomas Lynch wrote:
>> > Currently there is no way to directly attached arbitrary property
>> > information to a collection.
>>
>> An "info.rkt" file serves that role, where the `setup/getinfo` library
>> provides the API for querying "info.rkt" files. (The "info.rkt" format
>> is also used for package information. For single-collection packages,
>> it's the same file.)
>
>
>
> Here is the info.rkt file for /usr/share/racket/pkgs/plot/
>
> #lang info
>
> (define collection 'multi)
>
> (define deps '("plot-lib" "plot-gui-lib" "plot-doc"))
> (define implies '("plot-lib" "plot-gui-lib" "plot-doc"))
>
> (define pkg-desc "Functions (and docs and tests) for plotting")
>
> (define pkg-authors '(ntoronto))
>
>
> No mention of a version. I guess maturity will go here? But yes, excuse me,
> no need of a separate file for properties as there already is one. ... Sure
> looks to me like there is conflation between the terms collection and
> package.

There is a default version. What you're calling "maturity" is a
derived concept (determined by assays external to the pkg like running
its tests, checking for its docs, etc), not declared in the info.rkt
files.

>>
>> Well, maybe it's little more complicated than that. In general,
>> multiple directories can be installed and spliced together as the
>> content of a collection. Each "info.rkt" file can have information
>> that's specific to it's particular piece of a collection.
>>
>> In any case, collections don't have versions, ring levels, etc. Those
>> are properties of packages.
>>
>
> ah, so in racket I can't have versions attached to my source code
> (collection)? gosh So if I install via package, and install via directory,
> I'm not allowed to know if the two are the same version by checking the
> info.rkt file? May do diffs, but then what I wanted to know, say, how far
> apart they would be in version space.

Collections are not "yours" in the sense you mean here. A pkg offers a
bunch of source code in a bunch of collections, but different
(non-conflicting) pkgs can supply code that ends up in the same
collection, thought a kind of "splicing" operation. For example, the
racket/snip library (in the racket collection) comes from a different
pkg than the racket/set library (also in the racket collection).

>
>>
>>
>> > Asked another way, when I do 'apt-get install racket', or an analogous
>> > command, do no further installation commands (fresh out of the box),
>>
>> I think you're needlessly avoiding some terminology that we do have.
>> You mean "when I install a main distribution of Racket...".
>
>
> I purposely avoided the terminology as I find it inconsistent and conflated.
> That is probably because I'm dense and or haven't studied it enough. So I
> phrased the question in a manner as to get an answer without having to
> interpret the terms .. sigh .. don't see an answer.
>
>
>>
>>
>> > and
>> > then use (require X) in a module, with no quotes around the X, then
>> > can I
>> > know for certain that X is a module that was found in a collection that
>> > comes from a ring-0 package?
>>
>> All packages in the main distribution are ring-0 packages.
>
>
> But not all ring-0 packages are in the main distribution -- so the answer to
> my question is that they are not identical. That would mean that Robby's
> suggestion of not using the term 'main distribution X's' is unnecessary and
> ring-0 is preferable is not possible (as the two are not identical).

This is correct, ring-0 and main distribution are not the same. The
point of my earlier messages is to say that we wish to maek ring-0 be
the more focused and more widely used concept and main distribution be
a secondary concept. This is a matter of writing and emphasis and our
desire to present a certain face of Racketyness to the world.

Also relatedly, our hope and plan is that there will be multiple
different distributions of racket that are all just as useful as each
other, but for different classes of users. This will erode the notion
of "main" in "main distribution" as well.

> ----
>
> Ok, so I've got the idea here, and that is the subject is outside my
> comprehension. I sure don't want to send this discussion in circles because
> I'm being dense. I just hope that the chat was worthwhile. That doesn't
> hold me back from using racket though. It is pretty easy to install
> packages. It is the adding them that I'm not read for. Alas. Thanks for
> your patience.

Thanks for yours as well. :)

Robby

[Thomas Lynch]

On Saturday, May 2, 2015 at 10:14:39 PM UTC+8, robby wrote:

Hi Thomas: thank you for your energy and interest in clearing up the
terminology. I find this quite valuable.

Oh good.

 

There is a certain amount of
prescriptiveness that's coming through in your messages that makes it
a little more difficult than need be to answer your questions.

After 18 posts I made one design suggestion about collection versions, and you explain it is already there (good!).  Others were terminology proposals, such as native/local -- terms I thought would help the module-basics guide - as would some collective centric language.  (I know it would have helped me pick it up the first time.)

So I
wish to pop out a level here at the top of this message to point out
that the pkg system design has had quite a lot of thought put into its
concepts and while no one disagrees that we can explain them better, I
think that perhaps we should focus on explaining and understanding
them first and then changing them second.

I know you are guys are brilliant and have put a lot of thought into this.  That is why I'm bowing out after discovering I don't don't have a firm grasp of it, and leaving it in your capable hands.  I'm just relieved you found some value in the chat/search/tryout of some terminology.

 

One place that I think help help is if you were to read the pkg system
terminology documentation. Did you find that already? It's here:
http://docs.racket-lang.org/pkg/Package_Concepts.html

yes I did read this, though you will note in the first post, I've been talking about the language in module-basics in the guide.  There are a couple of paragraphs in the guide about packages and then it refers to the packages doc.  I wanted to tie that into the collections definition above it.