*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?
On Thursday, April 30, 2015 at 6:11:05 PM UTC+8, Thomas Lynch wrote:
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/8bcf9378-e41b-4969-beb5-07e814e3dcf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
