Just a question, but I wonder if you could give eds write access to the repo? And of course, if there's anyone else out there who would like to contribute, just let us know, I think sacado would be glad to accommodate you ^^
I'd like to have access too. Currently I don't have much free time to contribute, but if I find some time i'll be glad to contribute. My github username is, surprisingly, 'stefano'.
I've been following up on the forum threads but I haven't had time to actually read the code yet. (And the last time I checked, the arc2c executable gave me a segfault.)
The current arc2c output assumes that you have a proper Boehm GC installation, but since I can't seem to get a good install here (prolly something to do with being AMD64 again) I just disable the GC for now.
I finally got arc2c to work (without GC as you suggested). One note though: apparently arc2c relies on rm-global.arc, but doesn't load it by default. So under the current version of the compiler, 'compile-file will error until you (load "rm-global.arc").
Oops. Must have forgotten to add it to arc2c.arc then ^^. Unfortunately I won't be able to fix this until maybe 7 hours from now T.T, haha, I'm in the office ^^
The thing about GC working: well, you need to somehow download the development version of Boehm GC, and, well, that's what's stopping me for now T.T
There are a number of problems with the official distribution on several operating systems (e.g. Windows). This should be fixed on Anarki in the stable branch, which you can download from git://github.com/nex3/arc.git (or http://github.com/nex3/arc/tree/stable if you don't have git installed).
An Arc to C compiler in Arc might be able to do it, with appropriate optimizations. I might actually work on that for GSoC next summer. I guess we'll see where it goes...
We may need to define extensions for optimization purposes though.
As an aside, defm may help, by ensuring that certain variables always belong to certain types (although the other problem is with regards to . rest arguments). Really, having an optional type declaration is good, and helps make it easier for the compiler to optimize.
> In the sample we already have a "built-in" which is in fact added to the source to be compiled: ccc or call/cc. We could extend/generalize this to include a set of built-ins that are added to the source to be compiled.
I suppose the set of functions to be included would be those in arc.arc and libs.arc, in which case you would just compile arc.arc and libs.arc before compiling the target file, right?
Basically, ccc is handled by detecting if it is used. If it's not used, it's not inserted. When I was talking about extending this, this is what I was referring to: adding code which is defined as "inserted if used".
Simply inserting the entire arc.arc code will add bloat, because most programs don't even use most of the arc.arc code. Given the level of documentation of arc functions (arcfn.com notwithstanding), it is more than likely that the user will not use arc.arc code. So it's better if we simply insert the code if it is used.
Also, it may be better to use arc2c specific code, to take advantage of certain peculiarities in how code is generated. For example, if you decide to use unrolled lists, map1 and friends are better off allocating the full list and then iterating over the values.
This is fine if the compiler is static like Stalin, but if you omit parts of arc.arc that aren't used, you run the risk of not being able to deal with code known only at run time (e.g. (loop:print:eval:read)).
Come now, if you want real support for eval, you'll also need to include the compiler:
(eval `(fn (x) ,@my-variable)) ;how will it build the function?
The alternative is to punt: if there's ever an 'eval, then add arc.arc completely, make 'eval an interpreter which somehow uses 'symeval to lookup globals (and execute global functions as compiled functions), and when it encounters a function, will build the function as an interpreted function (and obviously allow interpreted code to call compiled functions and vice versa).
Basically you create a virtual function:
(def eval (e (o env))
(if
(caris e 'fn)
(add-attachment
'environment env
(annotate 'virtual-function
(cdr e)))
...))
(defcall virtual-function (f . args)
(with (env (get-attachment 'environment)
(arglist . body) args)
; has to be nondestructive
(zap add-args-to-environment env arglist args)
(each e body
(eval e env))))
But if you don't get the standard library right, then everyone is going to start using their personal version of it, and then you lose portability, etc.
It is worth getting the language right, even if the fix is trivial.
Basically 'marcup would accept a list representing an abstract syntax tree for the HTML code to be generated.
Then I decided to implement w/html instead, which was almost as good ^^; >.< In fact it's arguably better, since the copious ' marks denote non-Arc code (i.e. HTML tags), as opposed to the marcup style above where , marks denote Arc code.
