But ^ is the symbol for conjunction, i.e. "and"-ing (well, not the literal caret, but the upwards-pointing symbol -- $\wedge$ in Latex). Did you mean to suggest ^ instead of +?
I think that Lisp can support good quality syntax parsers. An example of this, although it's not a full fledged language, is CatDancer's JSON parser built on top of a general-purpose parser library: http://hacks.catdancer.ws/parser-combinator-approach-to-json... (it's a long article, the relevant parts are the ones about the parser-combinator approach).
Also, it seems as though your in-house language isn't completely specified yet. One area where Lisp excels is implementing unspecified things, and changing them with great flexibility on-the-fly.
Shader mentioned that Arc is slow, and this does seem to be the case. If you really want to use a Lisp, and Arc is too slow, it's probably worth looking at a few other Lisps before turning to Option A -- there are very fast implementations of both Common Lisp and Scheme.
I'm a tiny bit confused. You refer to arc handling the packages, which suggests to me that the core stuff deals with the packages. I think you mean that whatever tool gets written in arc for managing arc hacks would handle the packages. Am I putting words in your mouth?
Yes, that is correct. I'm sorry if I confused you. Maybe in the future the core of arc would handle packages to provide namespaces, but I meant more that since arc functions will be handling the use of the meta-data, it should be easy to turn that around and generate the meta-data from how you're using it, and a little more information about who you are and what you're trying to do.
I just had an idea about fixing conflicts and better documentation of dependencies:
Rather than (or in addition to) documenting dependencies on libraries, we should document dependencies on specific functionalities. That would also give a clue about which parts of a library are being depended on. When a library is changed or updated, people would know exactly where to look for incompatibilities.
What made me think of this is mainly the dependency on pg's Arcn releases, and the way that arcfn.com documented the changes to Arc3. Comparing a list of functionalities changed, to a list of those depended upon, seems to me to be a quick way of pinpointing where compatibility issues can be fixed, or could arise in the future.
NOTE: I don't intend this as a way of keeping libs static. In other words, a few libraries depending on a certain functionality foo shouldn't require or pressure the producer of foo to maintain the same "interface". This is intended more as a way to streamline the conflict-resolution and updating of the code which depends on foo, when it does happen to change.
I agree with everything you've written here. Earlier, I thought that hacks should be entire directories, but now that I think about it more, if a hack spans multiple files, it should probably be broken into multiple hacks (for example, your JSON parser is two hacks -- the parser combinator, and the JSON parser built using the combinator).
How will meta-data be transfered? One option that I can think of is to just put it at the top of the file containing the hack. If it's just a list of data, "compiling" it won't be a problem when the hack is loaded.
However, that doesn't really work for hacks distributed as patches. So, another option would be to have the info distributed as a file with the same name as the hack, but a .info extension (or .meta, or something along those lines).
Should there be a periodical (i.e. once/twice a month) effort to merge together various publishings of the same hack? I think it's important to do that, so that we don't have five differently-named but almost identical versions of a hack floating around after a few people add features. A list of contributers to a hack/library can be kept as commented "meta-data" within the file, and the hack can then be renamed to anarki.hackname.release.
However, I will point out that the name of the project/community is "Anarki", and so it is very likely to be distributed and each person will probably want their own version anyway.
Just like Linus Torvalds decided he wanted to be the Linux integrator, someone will emerge who wants to put together the best version of various variations of various hacks. If he or she does a good job, he or she will become respected and people will look first to him or her to find a version of a hack they want to use.
Information about a hack, like "this hack is the best of the bunch", is really best not put into the hack name, because later if the information changes (maybe you find out the hack has a bug), now you have a name that's giving bad information.
EDIT: I didn't explicitly say this here, but I will now: I think that the version numbers should make a definite statement that "catdancer.toerr.3" is an inferior predecessor to "catdancer.toerr.4". I think that in the interest of avoiding "dependency hell", people should be expected to use the latest stable version of a library. However, to ease backwards compatibility, if a library developer sees that the next stable version of their library will break compatibility with other libraries which depend upon their library, they should inform the developers of the other libraries about this, so that once the new library is released, other libraries can be quickly updated to work with the new version.
I think that a good system for version numbers (and who doesn't love copying good systems?) is to have two "latest" versions always available -- a stable version, and an alpha/beta version. The stable versions are the odd version numbers, and the alpha/beta are the evens. Obviously that could be switched, but everybody should use the same convention, and I think this one makes sense because a project starts at version 0, and then the first stable version would be 1.
If this system were used, than only the odd-numbered versions would be required to remain constant. The even-numbered versions could vary as the dev(s) fixed bugs or added features. Odd-numbered versions which depended on other libraries would have to depend on odd versions of those libraries. An even version could depend on any library.
I like the idea of using forum nicknames, because they're unique. URLs are (not entirely, thanks to Internet Explorer...) case-insensitive, so maybe pg should change the forum so that two usernames can't be case-insensitively equal? (If that's the case already, scratch what I just said...)
Meta-data can come in a separate file, named the same as the library. It should probably be some form of alist:
This last part could work because libraries would be uniquely identified by a string, as CatDancer explained above.
Also, some form of standard directory structure could be good. Each person would be able to customize where their lib/ directory would be, and what it would be called (in the example, my directory is arc/keystones/). However, within that directory, I think there should be some convention of how libraries would be organized. I think one that makes sense is that each library would have a directory, within which each version would have a separate directory. If this is nested too deeply, it could instead be a wide nesting -- arc/keystones/foo.xyzlib.3/
Within the library directory, the file which gets loaded should have some standard name too -- the most obvious one would be the name of the library. The directory could contain other files containing more code, and those files would be loaded (or required) by foo.xyzlib/3/xyzlib.arc. Meta-data would be in the file meta.arc.
Customizability of the lib folder is probably a good idea, but it will probably done via hacking the code for the lib functions ;) It shouldn't be that hard to do anyway. With my naming scheme, you'd just change the string that was prepended to the library name.
I'm not sure that odd/even version numbers is such a good idea. It could be very confusing that way. I think that CatDancer's requirement of libraries to be static is a much more reliable concept. Otherwise like he said you'd need to check periodically for updates.
Libraries should also be able to depend on whatever they want. That's the author's decision. If they need the beta version, but they've tested it and know that what they have written is stable, then they should be allowed to publish it that way. They can always make a new version if they need a bug fix.
Also, since the version is just part of the lib name, you can have as many layers of minor version that you want i.e. 1.5.200906015.
Libraries should also be able to depend on whatever they want
Dependencies should actually be managed outside of the libraries themselves. For example, I have a library foo that depends on bar. Later a new version of Arc comes out that implements what bar did. Now foo doesn't need bar any more. But foo itself hasn't changed, so I shouldn't have to release a new version of foo just to say that it doesn't need bar with this new version of Arc.
Instead we publish dependency information about libraries. For example, I can say that foo needs bar 0 and arc 3, or just arc 4... something like:
The odd/even numbering doesn't have to be exactly that way. It could also be something like foo/xyzlib/1b for the beta, and foo/xyzlib/1 for the "stable" version.
only the odd-numbered versions would be required to remain constant
the version numbers should make a definite statement that "catdancer.toerr.3" is an inferior predecessor to "catdancer.toerr.4"
There's a difference between a release number and a version number. A version number, as you say, can be used to indicate that a later release is better, or indicate the stable vs. alpha/beta status of a release, etc. The release number merely identifies releases.
For example, pg had several releases of arc3. Under my naming system, they would have been named "pg.arc3.0", "pg.arc3.1", "pg.arc3.2", etc.
Regardless of the alpha/beta/stable status of a release, two releases of a library should never be released with the same name and release number for several reasons:
- If I'm telling you about a bug in your library, then I can tell you which release if saw the bug in. If you change your library without giving it a new release number, then we won't know if I'm talking about your old release or your new release.
- It's clear when a tool such as my "lib" library which downloads a library from a URL needs to download a new release. If there's a new release number, and I want that new release, then "lib" knows it needs to download the new release. If the release can change at the same URL, then "lib" has to periodically check to see if the file at the URL has changed.
- Just because I think that a release of mine is a "alpha/beta" version doesn't mean that you might not want to keep using it.
I see what you mean -- I was a bit confused about version vs release.
However, I still think that the name of the library should be "arc". Maybe the releases would be named "pg.arc.3.0", "pg.arc.3.1", etc. I just think that the library name should be distinct from the version and release numbers.
DRY (Don't Repeat Yourself). I'm generalizing an existing function. Doing it this way keeps the code shorter, and in the event that 'ac-qq1 has a bug, then 'ac-qqx probably does too, and if I do it this way then when I (or someone else) tries to merge fixes for 'ac-qq1 they'll get a conflict indicating that they need to modify the fixes for 'ac-qqx rather than having it silently succeed, leaving bugs in 'ac-qqx.
I think the reason that lists are usually flat lists is that a flat list is homogenous -- each car is data, and each cdr is the next element, or nil. Dotted lists add another case which you'd have to handle. It's just simpler to deal with flat lists.
If you're just dealing with two- or three-element lists, then it might pay off to use dotted lists. In such short lists, you'd be getting a space saving of 33% or 25% per list.
Arc uses vectors to implement tagged procedures. Type the name of a macro in on the repl, and it displays a vector:
arc> def
#3(tagged mac #<procedure:.../arc/arc.arc.scm:151:11>)
That's a vector with 3 elements: tagged, mac, and a procedure.
Arc doesn't currently let you construct or manipulate your own vectors, but they could be used to provide transparent meta-data attached to functions and variables, such as where they were defined, and what the source code was that did so.
