Module system ELS20 presentation
Frédéric Hamel just presented our work on Gambit's new module system at the European Lisp Symposium. You can watch the presentation here: https://www.youtube.com/watch?v=8hoJBNHHg5I (including the “termite clock” demo at the end). The slides are here: https://www.european-lisp-symposium.org/static/2020/hamel-feeley-slides.pdf The paper is here: http://doi.org/10.5281/zenodo.3742443 Marc
Afficher les réponses par date
Very interesting indeed! I will look at the paper. I'm particularly glad to see that the module system is R7RS-compatible. A Termite-specific question: why send bytecode rather than C (perhaps minified by removing whitespace)? Presumably that would cost nothing at the source node (it's already been done) and be faster and cheaper at the destination node? Is the bytecode so much more compact as to make transmitting C untenable? John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." On Mon, Apr 27, 2020 at 8:37 AM Marc Feeley <feeley@iro.umontreal.ca> wrote:
Frédéric Hamel just presented our work on Gambit's new module system at the European Lisp Symposium. You can watch the presentation here: https://www.youtube.com/watch?v=8hoJBNHHg5I (including the “termite clock” demo at the end).
The slides are here: https://www.european-lisp-symposium.org/static/2020/hamel-feeley-slides.pdf
The paper is here: http://doi.org/10.5281/zenodo.3742443
Marc
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
On Apr 27, 2020, at 9:26 AM, John Cowan <cowan@ccil.org> wrote:
Very interesting indeed! I will look at the paper.
I'm particularly glad to see that the module system is R7RS-compatible.
Well… one of the supported module systems is R7RS compatible. There’s also a “primitive” module system that is much more Gambit specific, but has some features not found in the higher-level R7RS compatible module system. The intent is to promote the R7RS compatible module system for typical use and the primitive module system mostly for internal use. One of the extensions motivated by Termite was the use of library names that include the URL of the VCS repository and version, for example: (import (github.com/gambit hello demo @2.1)) It allows running that code with: gsi github.com/gambit/hello/demo@2.1 Gambit also has “builtin” modules that are named like this: (import (gambit list)) (import (_test)) It would be good if the Scheme community came to a set of rules for managing the “namespace” of library names, beyond reserving (scheme …) and (srfi …) and (<scheme-system> …). Specifically, I think a library name starting with a URL should be automatically reserved to the person or organisation that controls that URL. Also, a library name starting with an underscore should be reserved for the Scheme implementation, and have a meaning that depends on the Scheme implementation.
A Termite-specific question: why send bytecode rather than C (perhaps minified by removing whitespace)? Presumably that would cost nothing at the source node (it's already been done) and be faster and cheaper at the destination node? Is the bytecode so much more compact as to make transmitting C untenable?
Termite does not send bytecode. If you are referring to the slides, we were just saying “one way to implement portable code is with bytecode” but Termite does not do that. It can either send what is essentially an AST (in the “interpreted” code case), or a symbolic reference to the compiled code control point (in the “compiled” code case). A symbolic reference is basically the pair <procedure_name, seq_number>. Marc
[+srfi-discuss] On Mon, Apr 27, 2020 at 10:24 AM Marc Feeley <feeley@iro.umontreal.ca> wrote:
It would be good if the Scheme community came to a set of rules for managing the “namespace” of library names, beyond reserving (scheme …) and (srfi …) and (<scheme-system> …). Specifically, I think a library name starting with a URL should be automatically reserved to the person or organisation that controls that URL.
An excellent idea for a no-code SRFI that would be easy to write for people who haven't written one before. It should specify both the petname convention and the URL convention. Attention should be drawn to mailto: URLs, which allow people who don't control any conventional URL to have their own library namespace. I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars. I am juggling too many SRFIs as it is, so I can't do this myself. Also, a library name starting with an underscore should be reserved for the
Scheme implementation, and have a meaning that depends on the Scheme implementation.
By reserved, you mean that it is not to be imported from user code? If so, I am fine with it. If not, my objection is that if you get some code that imports (chibi ...) and you try to run it on some other implementation, you will probably get an unknown module error. But if it imports (_foo ...) and your implementation is using that name you don't know what will happen. In any case, I think putting such modules under the implementation petname is probably good enough. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org The man that wanders far from the walking tree --first line of a non-existent poem by me
Am Mo., 27. Apr. 2020 um 17:38 Uhr schrieb John Cowan <cowan@ccil.org>: [...]
It would be good if the Scheme community came to a set of rules for managing the “namespace” of library names, beyond reserving (scheme …) and (srfi …) and (<scheme-system> …). Specifically, I think a library name starting with a URL should be automatically reserved to the person or organisation that controls that URL.
I agree it is a good idea to have some management of namespaces. I am not so convinced about the use of URLs for that purpose. (Apart from aesthetics, will `https://www.nieper-wisskirchen.de' and `http://www.nieper-wisskirchen.de' be different URLs for that purpose?) If the library names become long (like with URIs), it would be nice each Scheme system allows to use or install a mapper (a simple association) from long names to short names so that I can access libraries as `(nieper foo)' instead of `(|https://www.nieper-wisskirchen.de| foo)'. If we go this route, we can drop URLs altogether and replace them with UUIDs, which everyone can generate (version 4 UUIDs). In fact, they are shorter than most URLs and no less pretty in library names.
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
Many R7RS systems don't define the mapping from library names to file names for library names that include characters like the slash or the dot. There may be other limitations.
Also, a library name starting with an underscore should be reserved for the Scheme implementation, and have a meaning that depends on the Scheme implementation.
By reserved, you mean that it is not to be imported from user code? If so, I am fine with it. If not, my objection is that if you get some code that imports (chibi ...) and you try to run it on some other implementation, you will probably get an unknown module error. But if it imports (_foo ...) and your implementation is using that name you don't know what will happen.
Do we really need this? Instead of `(_foo)', where `_foo' is supposed to be internal to Chibi-Scheme, it is already enough to put the code in `(chibi foo)' to make it private. The further conventions about the library namings inside the implementation namespace should be up to the implementation. psyntax, for example, uses `$' to mark internal libraries.
In any case, I think putting such modules under the implementation petname is probably good enough.
Indeed. Marc
I agree it is a good idea to have some management of namespaces. I am not so convinced about the use of URLs for that purpose. (Apart from aesthetics, will `https://www.nieper-wisskirchen.de' and `http://www.nieper-wisskirchen.de' be different URLs for that purpose?)
If the library names become long (like with URIs), it would be nice each Scheme system allows to use or install a mapper (a simple association) from long names to short names so that I can access libraries as `(nieper foo)' instead of `(|https://www.nieper-wisskirchen.de| foo)'. If we go this route, we can drop URLs altogether and replace them with UUIDs, which everyone can generate (version 4 UUIDs). In fact, they are shorter than most URLs and no less pretty in library names.
A standard way to rewrite library names (in the same way that individual identifiers exported from libraries can be renamed in R7RS) would be useful. Re: URIs and UUIDs, we just worked out this problem a few weeks ago with John in a different context: <https://github.com/unisig/unisig>. Our solution was to use either UUIDs, or URIs of the form "example.com/myname#fragment". I'd recommend that same form for Scheme libraries as well. Maybe drop the fragment part; we should think about it some more. Gambit is tentatively using "@v" as the last part of the library name for versioning, where "v" is a Git ref (tag or commit).
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
Many R7RS systems don't define the mapping from library names to file names for library names that include characters like the slash or the dot. There may be other limitations.
It might make sense to have a convention to treat any library name with a dot as a URI by default. With the possibility for each user to manually add their own rewrite rules to override that default where needed.
On Apr 27, 2020, at 11:54 AM, Marc Nieper-Wißkirchen <marc@nieper-wisskirchen.de> wrote:
Am Mo., 27. Apr. 2020 um 17:38 Uhr schrieb John Cowan <cowan@ccil.org>:
[...]
It would be good if the Scheme community came to a set of rules for managing the “namespace” of library names, beyond reserving (scheme …) and (srfi …) and (<scheme-system> …). Specifically, I think a library name starting with a URL should be automatically reserved to the person or organisation that controls that URL.
I agree it is a good idea to have some management of namespaces. I am not so convinced about the use of URLs for that purpose. (Apart from aesthetics, will `https://www.nieper-wisskirchen.de' and `http://www.nieper-wisskirchen.de' be different URLs for that purpose?)
That’s to be debated, but frankly I think the protocol part “http[s]://” should not be part of the library name in general.
If the library names become long (like with URIs), it would be nice each Scheme system allows to use or install a mapper (a simple association) from long names to short names so that I can access libraries as `(nieper foo)' instead of `(|https://www.nieper-wisskirchen.de| foo)'. If we go this route, we can drop URLs altogether and replace them with UUIDs, which everyone can generate (version 4 UUIDs). In fact, they are shorter than most URLs and no less pretty in library names.
Adding vertical bars should only be needed if… it is needed. There’s no point in forcing it if the name is a correct symbol.
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
Many R7RS systems don't define the mapping from library names to file names for library names that include characters like the slash or the dot. There may be other limitations.
Also, a library name starting with an underscore should be reserved for the Scheme implementation, and have a meaning that depends on the Scheme implementation.
By reserved, you mean that it is not to be imported from user code? If so, I am fine with it. If not, my objection is that if you get some code that imports (chibi ...) and you try to run it on some other implementation, you will probably get an unknown module error. But if it imports (_foo ...) and your implementation is using that name you don't know what will happen.
Do we really need this? Instead of `(_foo)', where `_foo' is supposed to be internal to Chibi-Scheme, it is already enough to put the code in `(chibi foo)' to make it private. The further conventions about the library namings inside the implementation namespace should be up to the implementation. psyntax, for example, uses `$' to mark internal libraries.
It is something that became useful as a way to easily specify builtin names on the command line for Gambit, i.e. to do gsi _hamt/test rather than gsi gambit/hamt/test It doesn’t seem like much difference at first sight, but with this idea of permitting library names on the command line you can start using them as a kind of flag to enable certain modes of execution, like quiet testing: gsi _test/quiet _hamt/test rather than gsi gambit/test/quiet gambit/hamt/test The shorter “_” prefix makes a difference and almost looks like the “-” in front of normal options. Marc
On Mon, Apr 27, 2020 at 11:38:10AM -0400, John Cowan wrote:
An excellent idea for a no-code SRFI that would be easy to write for people who haven't written one before. It should specify both the petname convention and the URL convention. Attention should be drawn to mailto: URLs, which allow people who don't control any conventional URL to have their own library namespace.
Assuming/hoping there will at some point be a registry where one can download r7rs libraries (maybe there already is? snowfort?), I think it can be as simple as suggesting people use their library name as it occurs in the registry as a prefix. This is lightweight, easy to understand and remember, and not as ugly or fraught with issues like the URI proposal. For programs, one could use the main binary's name as a prefix. If the binary is going to be installed into PATH under the scheme system's bin directory, that has to be unique already, anyway. And if it's installed somewhere else, it shouldn't cause any problem as long as the search path for binaries matches the search path for libraries (e.g.., first the current working directory, then system paths).
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
That would be a problem because then you'd need an additional mapping of URL to filesystem location for the module. A colon is not allowed in Windows file names, more than one dot might be a problem in some OSes as well, and slashes can't occur in file names either. There's many more specifal characters: https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations So an e-mail address might not work either. Cheers, Peter
Assuming/hoping there will at some point be a registry where one can download r7rs libraries (maybe there already is? snowfort?), I think it can be as simple as suggesting people use their library name as it occurs in the registry as a prefix.
Yes, snow-fort.org already has a nice collection of R7RS libraries. It doesn't enforce any particular library name conventions. We should set up something like lib.scheme.org that aggregates everything. Scheme.org news coming soon. Nevertheless, experience with golang shows that arbitrary URI imports are still a good idea. There are so many Go packages that they cannot hope to gather all of them in one registry, no matter how nice that would be.
This is lightweight, easy to understand and remember, and not as ugly or fraught with issues like the URI proposal.
Do you have specific issues in mind with the URIs?
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
That would be a problem because then you'd need an additional mapping of URL to filesystem location for the module. A colon is not allowed in Windows file names, more than one dot might be a problem in some OSes as well, and slashes can't occur in file names either. There's many more specifal characters:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
So an e-mail address might not work either.
Good call. I have a generic solution in mind to the filename mapping mess that would involve having a special metadata file in the lib directory. That file could have instructions about library lookup and compatibility, which would then drive a small library name rewriting engine in the Scheme implementation. By rewriting, I mean things like "assume all library names of the form (srfi-NNN) are aliases to equivalent names of the form (srfi NNN), and those can be found at filenames of the form srfi/NNN.sld".
On Apr 27, 2020, at 12:14 PM, Peter Bex <peter@more-magic.net> wrote:
On Mon, Apr 27, 2020 at 11:38:10AM -0400, John Cowan wrote:
An excellent idea for a no-code SRFI that would be easy to write for people who haven't written one before. It should specify both the petname convention and the URL convention. Attention should be drawn to mailto: URLs, which allow people who don't control any conventional URL to have their own library namespace.
Assuming/hoping there will at some point be a registry where one can download r7rs libraries (maybe there already is? snowfort?), I think it can be as simple as suggesting people use their library name as it occurs in the registry as a prefix.
A registry would be useful but it should not be the only way to name libraries. A registry forces authors to register their libraries for every new library they want others to use. But that can become a rather tedious process, especially if you are into rapid development and sharing a new idea “right now”. I want to put the library up on my github account and share the link… a 60 second process at most.
This is lightweight, easy to understand and remember, and not as ugly or fraught with issues like the URI proposal.
For programs, one could use the main binary's name as a prefix. If the binary is going to be installed into PATH under the scheme system's bin directory, that has to be unique already, anyway. And if it's installed somewhere else, it shouldn't cause any problem as long as the search path for binaries matches the search path for libraries (e.g.., first the current working directory, then system paths).
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
That would be a problem because then you'd need an additional mapping of URL to filesystem location for the module. A colon is not allowed in Windows file names, more than one dot might be a problem in some OSes as well, and slashes can't occur in file names either. There's many more specifal characters:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
So an e-mail address might not work either.
My main point is for library names that include a URI (at the head) to be under the control of the person or organisation that controls that URI (or mail address). This avoids the need for a registration step and is lightweight (no administrativia involved for the author). Marc
A registry would be useful but it should not be the only way to name libraries. A registry forces authors to register their libraries for every new library they want others to use. But that can become a rather tedious process, especially if you are into rapid development and sharing a new idea “right now”. I want to put the library up on my github account and share the link… a 60 second process at most.
+1 Last I checked, Racket requires new packages to be registered in order to download them using their "raco pkg" tool. The registration process is completely automated, and it's very painless and nicely done, but it'd still be nice to be able to skip it if a geographically distributed group of people is working by themselves and doesn't (yet) need to share their work. npm (node.js package manager) arguably shows that it may not even be desirable to publish all libraries people write in a central registry. With too many of them it becomes difficult for users to figure out which ones are polished enough for serious use. Collections like snow-fort, Akku, Chicken eggs and Emacs MELPA strike a good balance between quality and comprehensiveness IMHO.
At Mon, 27 Apr 2020 20:01:59 +0300, Lassi Kortela wrote:
Last I checked, Racket requires new packages to be registered in order to download them using their "raco pkg" tool.
No, `raco pkg` supports package sources in the form of URLs, Git repo references, local paths, etc. Racketeers sometimes use those alternatives to avoid delays in the catalog refresh. https://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3aso... Matthew
On Apr 27, 2020, at 1:01 PM, Lassi Kortela <lassi@lassi.io> wrote:
A registry would be useful but it should not be the only way to name libraries. A registry forces authors to register their libraries for every new library they want others to use. But that can become a rather tedious process, especially if you are into rapid development and sharing a new idea “right now”. I want to put the library up on my github account and share the link… a 60 second process at most.
+1
Last I checked, Racket requires new packages to be registered in order to download them using their "raco pkg" tool. The registration process is completely automated, and it's very painless and nicely done, but it'd still be nice to be able to skip it if a geographically distributed group of people is working by themselves and doesn't (yet) need to share their work.
The problem with registering a name is that it becomes reserved. So the first one to reserve “list”, “sort”, “gui”, etc will prevent others to use those names even if they have a “better” library. With URLs you don’t have that problem. Yes URLs are longer, but they point unambiguously to a specific library.
npm (node.js package manager) arguably shows that it may not even be desirable to publish all libraries people write in a central registry. With too many of them it becomes difficult for users to figure out which ones are polished enough for serious use.
Collections like snow-fort, Akku, Chicken eggs and Emacs MELPA strike a good balance between quality and comprehensiveness IMHO.
Perhaps and I’m not at all against it. It seems there are two needs… what you could call “community agreed portable libraries” and “libraries in the wild”. Marc
[+srfi-discuss]
Thanks for broadening the audience. Good call.
An excellent idea for a no-code SRFI that would be easy to write for people who haven't written one before. It should specify both the petname convention and the URL convention.
+1
Attention should be drawn to mailto: URLs, which allow people who don't control any conventional URL to have their own library namespace.
I'd advocate focusing on web URLs and only supporting other types if that falls out naturally from the overall design. There are now tens of thousands of hosting sites where anyone can get their own web URLs for free, both conventional GeoCities-style webhosts as well as social sites like GitHub that give everyone a github.com/username. Of course, if a library name part can be a URN (Uniform Resource Name, https://en.wikipedia.org/wiki/Uniform_Resource_Name) that's one way to solve the problem. We can do the same thing we did for Unisig (https://github.com/unisig/unisig) where the default URI scheme is whatever protocol is the most popular way to transfer web pages at any given time (previously http, now https, in the future http/2 or something else).
I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
I'd recommend simply not using any fancy URLs. A simple "foo.com/bar/baz" with lowercase [a-z0-9], dash, slash, and dot ought to be enough for almost everything. I guess we can permit arbitrary URIs (or URNs), and people can them use vertical bars for portability.
Also, a library name starting with an underscore should be reserved for the Scheme implementation, and have a meaning that depends on the Scheme implementation.
By reserved, you mean that it is not to be imported from user code?
Gambit has library names beginning with an underscore already. Most of those can be imported from user code, but only if the user knows the code doesn't need to run in other Scheme implementations.
If so, I am fine with it. If not, my objection is that if you get some code that imports (chibi ...) and you try to run it on some other implementation, you will probably get an unknown module error. But if it imports (_foo ...) and your implementation is using that name you don't know what will happen.
Good point. It might make sense to have the "_" alias in the interaction environment only, meaning that source files need to import using the name of the implementation.
Am Mo., 27. Apr. 2020 um 18:15 Uhr schrieb Lassi Kortela <lassi@lassi.io>: [...]
I'd advocate focusing on web URLs and only supporting other types if that falls out naturally from the overall design. There are now tens of thousands of hosting sites where anyone can get their own web URLs for free, both conventional GeoCities-style webhosts as well as social sites like GitHub that give everyone a github.com/username.
Do we want advertising for commercial services in library names in Scheme?
Of course, if a library name part can be a URN (Uniform Resource Name, https://en.wikipedia.org/wiki/Uniform_Resource_Name) that's one way to solve the problem. We can do the same thing we did for Unisig (https://github.com/unisig/unisig) where the default URI scheme is whatever protocol is the most popular way to transfer web pages at any given time (previously http, now https, in the future http/2 or something else).
To encode a protocol in library names is crazy if you ask me, especially because the most popular protocol changes over time as you write. But without the protocol, we don't have URLs anymore.
I'd recommend simply not using any fancy URLs. A simple "foo.com/bar/baz" with lowercase [a-z0-9], dash, slash, and dot ought to be enough for almost everything.
I guess that most R7RS systems will map the library `(foo.com/bar/baz)' to the same file system location as `(foo.com bar baz)'. To me, this shows some flaws in the approach. To use the example from above, GitHub may distribute a library `(github.com hacker foo)' under this proposal. Mr. Hacker owning a GitHub account wants to distribute `(github.com/hacker foo)'. This won't work without a clash.
Do we want advertising for commercial services in library names in Scheme? I'd leave that up to users. Is there a particular way we can restrict it? If we have a lib.scheme.org it will hopefully be neat enough that people will voluntarily want their libraries to have scheme.org instead of github.com.
More generally, any large-scale distributed namespace is going to end up with lots of messy names. I don't think there's a general way to avoid that problem (other than not being popular enough to have mutually unknown people coining names :)
To encode a protocol in library names is crazy if you ask me, especially because the most popular protocol changes over time as you write.
Fully agreed.
But without the protocol, we don't have URLs anymore.
From Python 3:
import urllib.parse urllib.parse.urlparse("example.com/foo") ParseResult(scheme='', netloc='', path='example.com/foo', params='', query='', fragment='')
So if you give it a URL without a scheme, it returns scheme='' which we can fill in with the default. I'm not sure what the RFCs say about such URIs, but that can be remedied with a specification like "parse as a URI; if invalid, try prepending https:// and parsing again". It shouldn't be hard to come up with a practical rule.
I guess that most R7RS systems will map the library `(foo.com/bar/baz)' to the same file system location as `(foo.com bar baz)'. To me, this shows some flaws in the approach.
To use the example from above, GitHub may distribute a library `(github.com hacker foo)' under this proposal. Mr. Hacker owning a GitHub account wants to distribute `(github.com/hacker foo)'. This won't work without a clash.
Good point. I'd advocate for standardizing a simple rewriting and filename mapping engine to work around problems like this (which I believe will come up no matter what kind of practical naming scheme we choose).
On Mon, Apr 27, 2020 at 07:35:06PM +0300, Lassi Kortela wrote:
Good point. I'd advocate for standardizing a simple rewriting and filename mapping engine to work around problems like this (which I believe will come up no matter what kind of practical naming scheme we choose).
The progrmming language Eiffel has a module linking notation used to direct its compiler. It recognised that modules get aggregated into packages, that packages get aggregated into larger packages and so forth. Each level of this hierarchy can get name clashes. So this notation has a mechanism to rename anything on import or export The idea is that each complete program comes with such a file telling the compiler in what hierarchy all these modules are to be combined and be renamed and have their imports and exports renamed. Presumably such a file can contain information where these modules and such can be found. Presumably it can also be wrapped with instructions about finding these modules, perhaps even rewriting the URLs or module names. I found this notation described near the end of one of the books describing Eiffel. I no longer have access to this book, or I'd give yo a detailed reference. But I suspect this mechanism shouls be considered when making similar decisions about Scheme. -- hendrik
On 27.04.2020 21.56, Hendrik Boom wrote:
Good point. I'd advocate for standardizing a simple rewriting and filename mapping engine to work around problems like this (which I believe will come up no matter what kind of practical naming scheme we choose).
The progrmming language Eiffel has a module linking notation used to direct its compiler.
It recognised that modules get aggregated into packages, that packages get aggregated into larger packages and so forth.
Each level of this hierarchy can get name clashes. So this notation has a mechanism to rename anything on import or export
The idea is that each complete program comes with such a file telling the compiler in what hierarchy all these modules are to be combined and be renamed and have their imports and exports renamed.
Presumably such a file can contain information where these modules and such can be found.
Presumably it can also be wrapped with instructions about finding these modules, perhaps even rewriting the URLs or module names.
I found this notation described near the end of one of the books describing Eiffel. I no longer have access to this book, or I'd give yo a detailed reference.
But I suspect this mechanism shouls be considered when making similar decisions about Scheme.
Very valuable tip, thank you for writing it up! The Eiffel site uses the term "cluster": "A group of related classes or, recursively, of related clusters." It says Eiffel projects have .ecf files that describe their configuration and dependencies. Here's one example: <http://seldoc.eecs.yorku.ca/doku.php/eiffel/faq/ecf>. Does this seem familiar to you?
On Mon, Apr 27, 2020 at 10:11:36PM +0300, Lassi Kortela wrote:
On 27.04.2020 21.56, Hendrik Boom wrote:
Good point. I'd advocate for standardizing a simple rewriting and filename mapping engine to work around problems like this (which I believe will come up no matter what kind of practical naming scheme we choose).
The progrmming language Eiffel has a module linking notation used to direct its compiler.
It recognised that modules get aggregated into packages, that packages get aggregated into larger packages and so forth.
Each level of this hierarchy can get name clashes. So this notation has a mechanism to rename anything on import or export
The idea is that each complete program comes with such a file telling the compiler in what hierarchy all these modules are to be combined and be renamed and have their imports and exports renamed.
Presumably such a file can contain information where these modules and such can be found.
Presumably it can also be wrapped with instructions about finding these modules, perhaps even rewriting the URLs or module names.
I found this notation described near the end of one of the books describing Eiffel. I no longer have access to this book, or I'd give yo a detailed reference.
But I suspect this mechanism shouls be considered when making similar decisions about Scheme.
Very valuable tip, thank you for writing it up!
The Eiffel site uses the term "cluster": "A group of related classes or, recursively, of related clusters." It says Eiffel projects have .ecf files that describe their configuration and dependencies. Here's one example: <http://seldoc.eecs.yorku.ca/doku.php/eiffel/faq/ecf>. Does this seem familiar to you?
No. not familiar at all. The example in the book was not written in XML. I can't tell whether this is an XMLized version of that they had back then, or something completely different. I wish I still had the book. -- hendrik
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
The progrmming language Eiffel has a module linking notation used to direct its compiler.
Eiffel projects have .ecf files that describe their configuration and dependencies. Here's one example: <http://seldoc.eecs.yorku.ca/doku.php/eiffel/faq/ecf>. Does this seem familiar to you?
No. not familiar at all. The example in the book was not written in XML. I can't tell whether this is an XMLized version of that they had back then, or something completely different.
What about this? From <http://se.ethz.ch/~meyer/ongoing/etl/LANGUAGE-TABLE.pdf>: PART IV: THE LACE CONTROL LANGUAGE ........................................ 1005 B Specifying systems in Lace (in progress) 1007 B.1 OVERVIEW 1007 B.2 A SIMPLE EXAMPLE 1008 B.3 ON THE ROLE OF LACE 1009 B.4 A COMPLETE EXAMPLE 1010 B.5 BASIC CONVENTIONS 1012 B.6 BASICS OF CLUSTER CLAUSES 1014 B.7 STORING PROPERTIES WITH A CLUSTER 1016 B.8 EXCLUDING AND INCLUDING SOURCE FILES 1016 B.9 SPECIFYING OPTIONS 1018 B.10 SPECIFYING EXTERNAL ELEMENTS 1022 B.11 ONCE CONTROL 1023 B.12 GENERATION 1023 B.13 VISIBLE FEATURES 1024 B.14 COMPLETE LACE GRAMMAR 1027 B.15 LACE VALIDITY RULES 1027
On Mon, Apr 27, 2020 at 10:43:13PM +0300, Lassi Kortela wrote:
The progrmming language Eiffel has a module linking notation used to direct its compiler.
Eiffel projects have .ecf files that describe their configuration and dependencies. Here's one example: <http://seldoc.eecs.yorku.ca/doku.php/eiffel/faq/ecf>. Does this seem familiar to you?
No. not familiar at all. The example in the book was not written in XML. I can't tell whether this is an XMLized version of that they had back then, or something completely different.
What about this? From <http://se.ethz.ch/~meyer/ongoing/etl/LANGUAGE-TABLE.pdf>:
PART IV: THE LACE CONTROL LANGUAGE ........................................ 1005 B Specifying systems in Lace (in progress) 1007 B.1 OVERVIEW 1007 B.2 A SIMPLE EXAMPLE 1008 B.3 ON THE ROLE OF LACE 1009 B.4 A COMPLETE EXAMPLE 1010 B.5 BASIC CONVENTIONS 1012 B.6 BASICS OF CLUSTER CLAUSES 1014 B.7 STORING PROPERTIES WITH A CLUSTER 1016 B.8 EXCLUDING AND INCLUDING SOURCE FILES 1016 B.9 SPECIFYING OPTIONS 1018 B.10 SPECIFYING EXTERNAL ELEMENTS 1022 B.11 ONCE CONTROL 1023 B.12 GENERATION 1023 B.13 VISIBLE FEATURES 1024 B.14 COMPLETE LACE GRAMMAR 1027 B.15 LACE VALIDITY RULES 1027
Can't tell for sure because the pdf doesn't contain anything beyond the table of contents, but this seems to be the right set of concepts. And from the number of pages, it may be more extensive than what I remember. Maybe I had an earlier edition. Or maybe I misremember the size. -- hendrik
What about this? From <http://se.ethz.ch/~meyer/ongoing/etl/LANGUAGE-TABLE.pdf>:
Can't tell for sure because the pdf doesn't contain anything beyond the table of contents, but this seems to be the right set of concepts.
And from the number of pages, it may be more extensive than what I remember. Maybe I had an earlier edition. Or maybe I misremember the size.
LACE stands for Language for Assembly Classes in Eiffel. The files in which it is written are called "Ace files". More links: http://se.inf.ethz.ch/courses/2013b_fall/eprog/additional_materials/eiffel_t... https://archive.eiffel.com/doc/online/eiffel50/intro/studio/index-05.html https://wiki.liberty-eiffel.org/index.php/ACE https://dev.eiffel.com/ACE_to_ECF:_The_Transition_Explained ("ACE to ECF: The Transition Explained. This page addresses the rationale behind EiffelStudio's new ECF configuration format, and clarifies which needs were covered by the new system. ECF stands for Eiffel Configuration File.")
On Mon, Apr 27, 2020 at 11:02:44PM +0300, Lassi Kortela wrote:
What about this? From <http://se.ethz.ch/~meyer/ongoing/etl/LANGUAGE-TABLE.pdf>:
Can't tell for sure because the pdf doesn't contain anything beyond the table of contents, but this seems to be the right set of concepts.
And from the number of pages, it may be more extensive than what I remember. Maybe I had an earlier edition. Or maybe I misremember the size.
LACE stands for Language for Assembly Classes in Eiffel. The files in which it is written are called "Ace files". More links:
http://se.inf.ethz.ch/courses/2013b_fall/eprog/additional_materials/eiffel_t...
https://archive.eiffel.com/doc/online/eiffel50/intro/studio/index-05.html
https://wiki.liberty-eiffel.org/index.php/ACE
https://dev.eiffel.com/ACE_to_ECF:_The_Transition_Explained ("ACE to ECF: The Transition Explained. This page addresses the rationale behind EiffelStudio's new ECF configuration format, and clarifies which needs were covered by the new system. ECF stands for Eiffel Configuration File.")
Yes, it now looks like its tie up-to-date successor to what I saw a decade or more ago and what I was talking about. -- hendrik
On Apr 27, 2020, at 10:24 AM, Marc Feeley <feeley@iro.umontreal.ca> wrote:
A Termite-specific question: why send bytecode rather than C (perhaps minified by removing whitespace)? Presumably that would cost nothing at the source node (it's already been done) and be faster and cheaper at the destination node? Is the bytecode so much more compact as to make transmitting C untenable?
Termite does not send bytecode. If you are referring to the slides, we were just saying “one way to implement portable code is with bytecode” but Termite does not do that. It can either send what is essentially an AST (in the “interpreted” code case), or a symbolic reference to the compiled code control point (in the “compiled” code case). A symbolic reference is basically the pair <procedure_name, seq_number>.
I notice my answer doesn’t cover all your questions. Even though the C code generated by the Gambit compiler is portable and could be compiled on all the platforms, it is not quite sufficient to do it that way because macros can observe properties of the system where the library was built. So it is conceivable that a macro could affect the generated C code. This has the potential to ruin deserialization of procedures if the macro behaves badly, but if the “programmer knows what he’s doing” (like have a macro that simply put’s the build machine’s hostname in the binary, or a random number stamp) then all is well. Apart from that problem, there are lots of ways to represent the code, with various levels of space usage (tested with lib/_num.scm): 3396 KB _num.c (C code generated by gsc from _num.scm) 446 KB _num.scm 296 KB gzip -9 _num.c 276 KB _num.scm (read-all of _num.scm followed by write) 153 KB binary serialization format (read-all of _num.scm followed by object->u8vector) 88 KB gzip -9 _num.scm 60 KB gzip -9 of (read-all of _num.scm followed by write) 55 KB gzip -9 of binary serialization format So there’s a factor of 62x between the most compact and least compact representation. The various forms of the C code are not on the best side of that scale… Marc
participants (7)
-
Hendrik Boom -
John Cowan -
Lassi Kortela -
Marc Feeley -
Marc Nieper-Wißkirchen -
Matthew Flatt -
Peter Bex