If you used something like CLN (http://www.ginac.de/CLN/) then you could get the full numeric tower basically for free. But perhaps you'd rather implement numbers in Arc instead.
As you probably know, I submitted a GSoC proposal for CL-Arc. I could write up a quick proposal for Arc-C, but there are only two more days before applications are due. Also, someone from the Arc community would need to apply to mentor the project in order for it to be funded.
I've taken a look at CLN and it seems to be a C++ library. I suppose this means we need to create some sort of set of wrapper functions and wrapper data types to handle this for us.
Also since allocation is all from the heap it seems we can use Boehm GC. Limited stack allocations (for leaf functions) would be cool too ^^. Edit: Oops. Since we don't actually end the function until at HALT(), it seems we can't free memory allocated via alloca().
"Google does not have specific eligibility requirements for mentors, as we know our mentoring organizations will be best able to determine the selection criteria for their mentors."
I don't know if LispNYC has any specific requirements.
As a mentor, I think you have to be in email contact with your student, give them advice as necessary, and evaluate their work. I believe I read somewhere that they estimate mentoring will take about 5 hours a week depending on the number and difficulty of projects.
If there's no need to be physically there, I'm willing to mentor you, in case sacado is somehow disqualified or is otherwise unable to mentor you (I'll probably ask sacado to unofficially mentor my mentoring you, though, sort of a meta-mentor). Anyway I've just applied, although I'll gladly defer to sacado (it'll be mostly his code anyway) if he is able to mentor you.
Note that due to various circumstances, I won't be able to leave my country until about a year or so, so if my physical presence is needed, sorry!
Ok, I submitted my proposal to GSoC. If you'd like to mentor, I would appreciate it. (Otherwise I can't get funded.) And please note that if you want to mentor, you need to apply today, or tomorrow (March 31) before 5:00 PM PDT.
No, apply can take any number of args. The last arg is interpreted as a varargs parameter. This is in fact the entire reason 'apply exists at all, so it can expand the final list into individual args.
"In the old days, they say (I wasn't there), many Lisps had only special variables (are they really that special when they're all you have?). The problem is that bugs associated with the dynamic/special behavior are quite difficult to debug. You can have one part of the program affect another part and it isn't clear what the connection between the two is unless you're looking at the call graph."
> Have I missed an elegant solution that doesn't make the code bigger, harder to read or not thread-safe?
Perhaps CL style special variables? You can reference them without extra code (although you need naming conventions to prevent mixing lexical and special variables), and I think most CL implementations automatically make thread-local copies when using special variables in a thread. (See the rest of that article I linked above.)
>The problem is that bugs associated with the dynamic/special behavior are quite difficult to debug. You can have one part of the program affect another part and it isn't clear what the connection between the two is unless you're looking at the call graph.
Yep, that's a reasonable argument for a language designed
for average programmers. But if Arc is designed for
expert programmers then I think expert programmers will
want to make a different trade-off. I'll risk shooting
myself in the foot to get a more powerful language.
> Perhaps CL style special variables?
Yep, that would be good. That would be adding
dynamic binding to Arc.
Do you think this would be a realistic amount of work for one summer?
What about part two (converting the compiler to compile Arc instead)? I suppose I would gain something on an understanding of the operation of the compiler while doing part one, but this seems rather intimidating to me.
And I'm not really sure Stalin is the right compiler to base an Arc in Arc on. (Although I suppose that wasn't really the point of your post.)
Can you suggest any other Scheme compilers I might try to port?
I don't know much about Scheme compilers (or Scheme for that matter, I'm a Lisp guy), so I can't really say.
For the conversion to an Arc compiler, it's similar enough to Scheme that I don't think it'll be a big issue, especially as it's implemented on MzScheme. Quite a few tricky Arc functions are just MzScheme functions under a different name (e.g. threading, I/O stuff). That brings up a point: you really want a compiler for the subset of MzScheme that Arc uses, not Scheme itself (although a Scheme->Arc compiler would be cool too).
Is it too much work for a summer? Depends on what you want to achieve. A completely non-optimising Arc compiler, based on code ripped from other projects, would probably be really easy to implement. Writing a Scheme compiler in one semester is standard coursework on some CS courses. So I guess the important questions are:
1. What good Scheme compilers written in Scheme already exist?
2. How much actually needs to be converted? (Most of the runtime will probably be implemented in C anyway, so no conversion necessary).
3. Given the spread of possible compilers you could convert, do any of them look like a summer's worth of work?
I agree with you that 'let and 'with are redundant (although I still disagree about 'fn and 'def).
But I think the difference between the 'let and 'with forms would be removed better simply by removing the implicit progn. This was brought up previously in http://arclanguage.org/item?id=3234 .
This would allow (let a 1 form) like the current 'let, or (let a 1 b 2 form) like the current 'with. For multiple statements you would need (let a 1 (do forms)), but pg already said how he liked that 'do highlighted non-functional code.
Maybe you could set a hook on 'safeset that would trigger Arco whenever you changed a variable holding a function definition? Then you could reanalyze the function and produce a new optimized definition. In between you would be able to assume that the function hadn't changed à la Stalin. Or am I missing something that would prevent this from working properly?
If that isn't possible, I guess CL style is the next best. But I don't like how verbose CL type declarations are. I don't really want to code C in Arc.
Of course, a native code compiler in Arc would provide a huge boost in speed, but I think that is a long term goal.
Another random idea: if you wrote a version of Arco for CL-Arc you could take advantage of CL's type declarations. This could result in even greater boosts in speed. Just a thought.
I chose 'safeset only because that is what is used internally in 'def. But I see that you would need to watch 'set to be completely sure no redefinitions had occurred.
So if you put a hook in 'set, and watched for local variables (really function parameters, because 'let is implemented in terms of 'fn) overriding function names, that would probably be enough to know a function hadn't changed. And that would hopefully remove the need for CL style type declarations.
Maybe this should be added as an option to the poll?
In fact, yes you really have to watch for locals either way - it's entirely possible to do this (I have, since I wanted to package Arki in a module-like object):
(let (localfn localfn2
help* sig source-file*) nil
; protect 'def from bashing Anarki help docstrings
(= help* (table) sig (table) source-file* (table))
(def localfn ()
(prn "localfn!"))
(def localfn2 ()
(prn "!2nflacol"))
(def globalfn ()
(localfn) (localfn2)
(prn "haha only global!")))
I appreciate everyone's comments, both the support and the criticism. And I'd like people's help with something.
At the moment I have one major problem: LispNYC does not deem CL-Arc to a be a full summer's worth of work. So unless I can show them that CL-Arc really is a summer's worth of work, I'm left with either coming up with additional ideas which I can work on after CL-Arc, or writing an entirely new proposal on another topic.
I'm wondering if anyone has ideas for what I could work on after completing the basic CL-Arc. If the axioms and core language take a couple of weeks, and the libraries take a couple of weeks, and FFI (probably just a port of the current FFI on Anarki) takes two weeks, that leaves a lot of time in the summer. What can I do with this time?
One idea is I could port Arco to CL-Arc. Unfortunately Arco isn't complete and is undergoing rapid changes, and might be completely different by the time I get around to CL-Arc. This makes it even more difficult to write a definite proposal.
> How long do you think defcall and settable-fn would take?
About a week, maybe less ^^. Defcall is reasonably trivial although it requires some rethinking. settable-fn is implementable using defcall (see nex-3's settable-fn2) but I'm personally dubious of such a style, and prefer my own.
> (But I'm a little dubious about working on something pg may have already done.)
We don't have evidence either way - pg hasn't commented on this (none that I've seen, anyway). Up to you to decide whether to act as if pg made it, or act as if pg didn't make it.
You could add to the proposal various useful libraries, such as libraries to use HTTP, FTP, SMTP, etc. protocols, bindings to access databases, graphic libraries, etc. You just have to choose.
I ended up creating a public copy of my own git repo not to mess with Anarki...
As for your concerns, I think you shouldn't be too worried. Just check it out, there is ample room for improvement, especially in speed, which I understand is your primary objective. No network yet, no threads, continuations are implemented as chains of closures (I honestly don't know better than that)... it just loads plain arc.arc, and I haven't checked it thoroughly.
For me, this was a very nice opportunity to learn about the CPS transformation. Arc is perfect in this respect (only 4 special forms). I'm pretty sure that, as an exercise, it's full of bugs and misconceptions, because I love to learn by doing (and make lots of silly mistakes along the way)...
I'll be happy enough if it helps just a tiny bit...
Thanks. I appreciate the constructive criticism :)
> This project has little relevance to the world outside arclanguage.org.
I don't see how much of anything I do here affects the outside world.
> I'd suggest looking to see if anyone has made a Scheme to Common Lisp compiler.
That seems like a rather roundabout method of compiling Arc to CL. Should we always use existing cross language compilers whenever we want to port Arc to a new language?
Say we have a language X, which only has a CL to X compiler. Compiling is then a conversion from Arc to Scheme, then to CL and finally to X. Is it really a good thing to have all the middlemen? And say we have a language Y which only has a X to Y compiler....
> I don't see how you're going to handle continuations or tail recursion.
Continuations are a difficulty, but I think one of CL's libraries may do the trick. They might not be truly first-class, but if they work I don't intend on worrying about it until I've got everything else working.
I don't see how tail recursion would be a problem. As far as I know most CL implementations provide tail recursion. (pg's ANSI Common Lisp talks a lot about using tail recursion in CL, which is one reason why I am not too worried about it.)
> It seems to me that if you get Arc running, then srv.arc should just work and give you the web server for free.
I hope it works out that way. (I will be more than happy to move on to other things if that step goes quickly.)
In my previous posting, I didn't mean to use the Scheme layer as a middleman; I meant to take an existing Scheme compiler and do s/lambda/fn/g on the code (as well as other necessary changes :-) to end up with an Arc compiler.
If you're implementing a Scheme-like system, I highly recommend Dybvig's "Three Implementation Models for Scheme" (http://www.cs.indiana.edu/~dyb/pubs/3imp.pdf). The three models are a heap model, a stack model, and implementation on a crazy string-based research processor; you'd probably want the stack model. Despite being a PhD thesis, it is very practical; it describes how the author implemented Chez Scheme and gives a pretty much full Scheme implementation running on a simple virtual machine. It handwaves about converting the virtual machine code to assembly, and gives some sample VAX code in an appendix.
I'll reiterate that you should look at how to make your project have a larger impact and relevance; what could you do (perhaps using your compiler as a base) that 1000 people would benefit from?
So basically you propose writing a meta-circular Arc compiler by porting a Scheme compiler to Arc, and modifying the compiler to compile Arc instead? That actually sounds like a really cool idea, if I understand you correctly. But what Scheme compiler would you use as a base?
I presume the paper you posted is meant for implementing Scheme from scratch? (So this would be an alternative to the previous option?) I'll look over it if I get the time.
Now perhaps I'll see if I can make a proposal out of this. (I might as well, assuming I have the time, since I am allowed more than one.) Although there is one issue: in order for such a proposal to get funded, I need someone from the Arc community to step up and mentor it.
