Not that this is necessarily a bad thing - it's good to take your time thinking about hard problems. I just hope the Arc community doesn't get too pissed off with pg's slow pacing that they go off and create yet another could-have-been-great-but-for-x-y-and-z new lisp dialect.
newLISP's default dynamical scoping fits very neatly among its other daring innovations (and, let me remark, such are wholly in the spirit of Lisp.)
One of those is the notion of a "context". Apart from neatly giving provision for all your lexical scoping needs, it adds the freedom of choice between argument passing by-value (which is default - another idiosyncratic bold feature of newLISP) and by-reference (through contexts). And - again, in line with Lisp's more traditional superiorities - contexts are first-class objects in newLISP.
My initial proposal here was not that newLISP is anyhow better than Arc. It cannot be, for Arc may eventually turn out to be anything; and, after all, this is an Arc forum.
It was, rather, that we should all go and use newLISP, to help Arc's developers learn from an existing complete powerful Lisp that has brought into practice many new design ideas.
Ah, but of course dynamic scoping is bad for any, any language, whatever the design goals. Everybody knows that since ages ago. <end of my turn to be clever>
My fascination about newLISP was exactly that: "What?! Dynamic scope by default?! ...Oh, but look, they say you can scope lexically & do closures with no fuss... Context as an explicit first-class object? hey, that's an idea, for once."
newLISP indeed has real flaws, - which can be mistaken for mistakes, unless you take into account the exotic design requirement for newLISP: to fit a Swiss-army-knife function library, together with functional and O-O programming support & a stand-alone web server, into a 300kb executable.
We can but guess of the author's intent. My guess is that the built-in distributed computing functionality has something to do with the plan.
You would need help from the compiler. Basically a macro would be called with a list of bound variables as an extra argument. For a compiler, this would be quite easy. Now a macro would look like:
Then insert stuff in Scheme-side 'ac to use (apply macro the-free-list-or-whatever (cdr ex)) instead of (apply macro (cdr ex))
That way macros that need it can get it, while macros which don't need it can ignore it.
We can potentially define 'expansion-context as a table or function, and potentially we could allow an implementation to have expansion-context!line, say provide line number etc. information so that the macro can give decent error messages. Of course if we have a dorky backend (like mzscheme) then we can just have it return expansion-context!line as nil, because it can't somehow extract line numbers, but for implementations that can, then good.
edit: Oh and ye: the 'ac compiler on scheme-side really does keep a list of bound variables ^^
This is a solution, but I consider this cheating, because it is nearly as tedious as manually inserting symeval around global functions.
w/var:do in my mexpr.arc is an example of a macro/dsl which can not take a free-var list as 1st arg (it could be changed, but that would make it useless)
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.
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.
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.
Seems a good idea. When require sees a string it would have its standard behavior, and when it sees a symbol it loads it as a packaged library. I'll add it. I'd also like to integrate it with a namespace system, but there is none yet. You've been working on a system based on symbols, right? What's its current state? Is it usable?
This is becoming unavoidable. This is really a pity, but the official Arc development is simply too slow (assuming it is moving, a quite optimistic assumption).
Integrating it into my forked Arc, but sadly something is interacting badly with the compiler and some macro is getting stuck in an infinite loop (which, if I don't catch with a ^C early enough, will force me to actually restart my computer T.T), probably from an incorrect compile. I'm debugging it currently >.<
Debugged! Now I just need to rewrite bits and pieces of arc.arc to clean it up and make it follow a more "axiomatic" path that will allow you to do neat things, like define how (+ (your-type 1 2) 42) will be (and adding hacks into ac.scm so that the axiomatic path isn't so slow).
I like the idea of using { and } for hash tables. But without taking {} (they could be useful in the future) we could use a syntax like #h(key val ...). E.g:
Yes, but then you can't print hash tables in a way that is also readable, and unambiguous with a list.
Right now:
arc> (= codes (obj "Boston" 'bos "San Francisco" 'sfo "Paris" 'cdg))
#hash(("Boston" . bos) ("Paris" . cdg) ("San Francisco" . sfo))
