"Possibly sacado's Psyco for Arc (http://arclanguage.org/item?id=5162), if sacado is willing to let someone else work on it." Sure, if you want to work on that, you're welcome ! ;)
In the same vein as your first idea, an Arc compiler to native code (C, asm, JVM, LLVM, ...) written in Arc would be a great idea... We would then have a bootstrapped interpreter/compiler...
An Arc native code compiler would be very nice, but unfortunately I don't really know anything about compiler implementation. So for me it would probably too long a haul for one summer.
Still thinking about Arc Psyco... or a CL implementation of Arc....
Seriously, I think a CL implementation would be a good thing to have, so as to have access to all the CL library and world, but that would also mean having a somewhat competing implementation, and I'm not abig fan of that. Mainly because time spent on maintaining this implementation is not time spent on the "canonical" one.
But that's just my opinion and the CL implementation could be very valuable to others around here... And maybe a fully compatible CL Arc is possible (I mean one where you run your "canonical" Arc code unmodified, what ever this arc code is, should it deal with hard things to port such as FFI or ccc...), I don't know...
I think pg's On Lisp contains some samples on transforming code to continuation passing style, which would allow us to create ccc. It would also mean bashing the code quite a bit, and CL doesn't necessarily optimize functions that are passed around and called in tail position, unlike Scheme which requires such to be optimize.
Yes, it is not required by the norm, but as far as I know, ACL, SBCL, CMUCL and CLisp all implement tail call optimizations (for the latter, only on compiled functions though). Maybe that could be considered enough to rely on it.
Perhaps I'll have to go back and read that part of On Lisp some time. (I stopped after mvdo because the macros were hurting my head. But perhaps I've developed a thicker skin since then.)
Peter Norvig has a simple Scheme interpreter (tail recursive, with call/cc) implemented in Common Lisp at http://norvig.com/paip/README.html - it would probably be a reasonable basis. One option would be to implement Scheme in Common Lisp, and then simply run the existing Arc ac.scm on top of that. But it would probably make more sense to cut out the middle layer and modify Norvig's code to run Arc instead of Scheme.
"Possibly this could make a good Arc Summer of Code project?" Yes, probably. Well, actually I don't know how these things work. At all. But I guess it is...
Edit : yes, I think that would be a good idea !
Btw, yes, these are really hard problems I think. It won't be done in a few hours. However, in our case, we already have mzscheme doing a good part of the work (it could be interesting to get even closer to the bare metal, though, but that could be done later). Psyco, on the other hand, compiles down to assembly code.
I found a few references about how Psyco works, I'll give back the links here next time I use my regular machine.
I'm pretty heavily involved with LispNYC, and they're the lispiest of the Google SoC sponsoring organizations. I'm also pretty interested in psyco, so if someone finds a student who wants to work on this, I'd be happy to mentor.
probably to discourage commenting about URL submissions, which would confuse voting for the article (nice URL, shitty comment,) give a higher presentation priority to the submitter's comment, muddy up the analysis of the URL, and prematurely guide conversation
I don't like it. If you want to get rid of def, use =. If you want to teach anonymous functions, just say : "you see, (def foo (x)) is the same as assigning the variable foo a function that takes one parameter named x. This can be written : (= foo (fn (x))".
And it makes fn have a strange behavior, plus the fact that we lose the simple syntax for varargs functions. And how do you read (fn nil nil) ? Is it a function I try to call nil with no argument and no body ? Is it a no argument anonymous function that returns nil ?
with the requirement that the parameters always be in parens, that would be an error
[edit]the inspiration for giving fn an optional parameter is that def is redundant. i don't think it would be strange at all. except for full-vararg cases, a straightforward 'def -> fn' search & replace would be sufficient
"with the requirement that the parameters always be in parens, that would be an error" : not really, because without parameters, you would have '() which is automatically translated to nil. You could do (fn (nil) nil), however, but I don't like the look of it. Not enough consistent, I guess (and a list containing the empty list to denote the empty list does not look right to me).
well, as a special form i don't think it would have trouble differentiating between () and nil. () seems to be different from '() even though (is () '()) is t
'() is (quote ()) while () is (). You won't notice the difference if you pass both to a normal function but you might if you passed both to a macro or special form.
While superficially (fn (. args) ...) may look decent, it is entirely inconsistent with the Arc reader. Function definitions have to be entirely representable in lists, and the example you list above is not a valid list. Not only would this break the current Arc, but you would have to reimplement the entire reader that Arc currently borrows from Scheme. Not to mention that you would have to define what it even means to have a cons with no 'car field.
Nice idea ! You are more reasonable than I am. I was trying to write a meta-circular Arc->C compiler. For the moment, I can tell whether a value is a fixnum (and which one), t or nil. I don't know if I'll go any further :)
It had to be put on this forum, not only because questions on how Unicode works were asked recently, but also because of the polemic about the preliminary Arc version and the "We only deals with ASCII, period" story ;)
"We're making an informally-specified, ad-hoc, bug-ridden implementation of half of CLOS"
That's what I thought when I was thinking about solutions for these problems :)
I think (1) could be solved simply by using redef on each polymorphic function : if car becomes polymorphic, just encapsulate the desired behavior in a new definition of car that will do the dynamic dispatch for you. If you want a specific version of car (e.g. the array implementation), just call it explicitly : (array-car x) .
Looking at my code I realize it is inconsistent with respect to underscores, but that was because I did testing on both official and Anarki, and forgot to check the code I pasted into the submission.
I'm not sure if that has anything to do with your comment about three underscores or not. (I'd appreciate an explanation either way.)
I hadn't read very close your code, so obviously I'm wrong.
Anarki's FFI is based on mzscheme's (of course), which itself imports symbols beginning with an underscore (_int, _pointer, _string, ...) These can clash with Arc's names (and they actually do, the string function for example). To overcome this issue, I added an underscore to Arc's names in Anarki (Arc's string is now mzscheme's __string).
Reading the original ac-global-name code and the corrected one I saw yours had one more underscore. I thought it was part of the correction, but it seems you just give arc2's original ac-global-name and Anarki's corrected code. Hence the mistake. Sorry for that noise :)
