Since everyone talks about how useful it would be to have a good set of libraries but so few have been written so far, I'm thinking about what kind of tools, documentation, etc. could ease the development of a library. I'm currently working on pack.arc, that I hope will make developing, installing and loading library easier. What would make library development/usage easier for you? Let me know!
An alternative method of distributing individual libraries other than by dumping them all on Anarki.
Say we make a convention that we can make a new post on arclanguage.com with the post title "<library>my-library" in order to define a new library called "my-library". Library code must be indented by two spaces as normal to differentiate commentary on the library from the library code itself.
Then when 'require can't find my-library on the local copy, it uses http-get, trawls through http://www.google.com/search?q=site:arclanguage.com+%22<... , and searches for the newest post on arclanguage.com, downloads it, then parses out the library code.
LOL.
That would be cool, but probably stupid.
Basically, a really nice way to package and distribute individual libraries, a really nice way to specify dependencies.
With pack.arc you can pack a library in a directory, and then you can distribute that directory and put it wherever you like. I don't like too much the method of abusing the forum to distribute libraries. I would really like an ad-hoc application (maybe at arclanguage.org/libs), so that if require doesn't find a lib it tries to install it from arclanguage.org/libs?name=my-lib or something similar. As of today, dependencies are already handled, but the needed package must be in the search path of pack.arc.
Something else that would be hard to develop, but possibly pretty innovative, is if an arc package system were tied to a git-like patching system:
This means that a package could "modify" instead of just "adding" to the code.
In most languages, this wouldn't be a feature that makes sense. In those languages, packages simply override code instead of mutating it. However, since a central tenet of arc is to have extreme minimalism, it would be interesting if packages could avoid adding unnecessary bulk to the base language by allowing mutation of existing code.
So, for instance, a package that improves a basic arc language feature could actually "clean out" the previous version of the code right out of the base language. (The packaging system would of course retain a copy of the old code, in case the package is ever removed and the previous code needs to be restored)
Or, a package could just be a patch on a core file (like ac.scm) that enhances the core in some way. This way, a package system could be used even for aggressive language experimentation.
Seems interesting, but I don't know if it could be implemented in a simple manner. I think it would create quite a lot of confusion especially in the following situation: package A requires package B, package C requires a "modified" B, and package D requires both A and C. The conflict doesn't seem solvable, even with namespaces: B and B modified would live in the same namespace, unless the latter modifies also the namespace.
I suggested adding "interfaces" to packages. So A might require <B>v1, while C requires <B>v1-modified. At the very least, loading C would fail if the copy of B available on the user's machine is the original that does not provide <B>v1-modified.
OF course, it still requires that the modified B provide the semantics for the original B so that it provides <B>v1 seamlessly.
Interesting idea, but I'm having a hard time visualizing how it would work. How do you patch source code after it is compiled and being used in a running image? I am aware of the existing (let old foo (def foo (...) (bar (old ...)))) pattern, but you seem to be implying something more that this... Or am I completely off on that aspect of it?
An easy way to get an overview of what libraries are available. The Anarki libraries are spread over half a dozen different folders, and for a few of them I don't know what they're meant for even after I read the source code. There needs to be something akin to "gem list".
Nice idea. It would be really great if we had a central website where to put packaged library, so we could query that. I'll try to develop an Anarki-local version.
I've put something on Anarki. You can query installed packages (i.e. packages in the search path) using regular expressions:
> (pack-query "a regular expression")
The query looks in the packages' name and description. The first time it also builds a cache of installed packages name/description in ~/.arc/cache . After installing new packages, use
> (pack-build-cache)
to update the cache. If you try it now on Anarki you'll get no result because there are no packages on Anarki.
How long would 'pack-build-cache have to run? Is it possible for it to just check for newer packages? Because if it's not too long, it might be useful to have it start automatically, or even as a:
(thread
(while t
(pack-build-cache)
(sleep 1000)))
It just dumps the title and the description to a text file and there is no way to check only for newer packages. Maybe it would be possible with a real implementation, this is just a prototype. Making it run continously in the background is thus unacceptable. I don't think it's a problem for the user to type (pack-build-cache) after installing new libraries.
A possible implementation: use the Anarki repository as the website and build the package manager on top of git. I don't know much about gems so I don't know if this would work, but it would save a lot of reinventing the wheel.
To knock down my own suggestion: git isn't suitable for this because it doesn't have any way of partially downloading a repository. At least, none that I can find.
Perhaps we need applications more desperately than we need libraries. There is a desire for more libraries in the Arc community but no pressing need. Creating and sharing even the most basic web apps would start to create a vacuum that new libraries could fill.
I think all libraries should be refactored regularly.
For example, your int->str function is general enough to be in "the Arc Prelude", so you do not have to access the pack.arc module (when we have a decent Module system). Other developers may me unaware of the inner workings of pack.arc and duplicate this functionality.
The package manager should detect funny dependencies or duplication and warn/ask the developer to refactor his code.
