Arc Forum | arc2c update

Arc Forum

arc2c update

7 points by almkglor 6041 days ago | 10 comments

Sitting bored in the office, so I decided to start documenting a little what has happened to arc2c so far.

From my checklist in http://www.arclanguage.org/item?id=5818 :

1) Decoupling of primitives from globals - DONE. Pretty much done with the inlining globals step. However some of the existing primitives still need to be decoupled, notably the arithmetic operators.

2) Macros. Especially 'def - IN (very slow) PROGRESS. Currently 'def, 'and, 'or are handled specially, but no other macro-forms are. http://www.arclanguage.org/item?id=6458 contains a discussion of what I'm doing and why.

3) Strings - DONE (by sacado)

4) Threads - NOTHING

5) I/O - NOTHING

Currently sacado has added since the previous update:

1. association tables. Not really hash tables, more like association lists implemented as two parallel arrays, but it works much like the Arc tables (possibly slower for large tables), except with list keys (which are possibly buggy in canonical Arc).

2. Floats. The rest of the numeric stack doesn't exist yet.

My modifications so far have been mostly bugfixes of my code:

1. Intermediate results of each stage are now written to a2c.log in the current directory.

2. Fixed bug where immediate values that aren't used are not being removed. This is necessary in order for docstrings to be ignored.

3. The internal sharedvar objects (used to implement mutation of local variables) are now garbage-collected, and typed.

4. Changed handling of quoted constants slightly. http://www.arclanguage.org/item?id=6585

Now I have a few proposals:

1. Support for a (t ...) form, which acts like the C #pragma. For example:

  (set foo
    (fn ()
      (t arc2c named foo)
      42))

Basically (t arc2c ...) is a command for the arc2c compiler, in this example one which names the anonymous function as 'foo.

Of course this could simply be done in the AST's of the arc2c compiler instead, but it might be useful to allow the user to perform this (and other) specifications.

We could modify ArcN so that (t ...) is simply converted by scheme-side 'ac to plain nil.

2. Subtype closures into continuations and non-continuations. Functions explicitly stated in the source code are non-continuations, while functions created by CPS conversion are continuations.

This should allow us to more easily emit a backtrace (we backtrace continuations closures only), as well as support some memory optimizations (When a continuation function exits, its closure can be freed immediately, and/or reused for a new continuation - except when 'ccc has been used, which transforms the closure from continuation to non-continuation, since the continuation-type functions are not supposed to be passed around by Arc code).

2 points by almkglor 6040 days ago | link

Some more things:

1. Continuation guards. Should we implement these? The current Arc prevents continuations from a different thread to be executed, as well as protecting continuations from outside 'on-err from being executed within the context of 'on-err.

This is reasonably easy to implement: just have a global "current continuation guard number". Newly created continuations are given that number. If a continuation is called, the current continuation guard number should equal that continuation's guard number. Otherwise we have a call to a continuation outside the guard.

'on-err and 'new-thread would then wrap the function call around something like:

  ; ccgn == current continuation guard number.
  (let foo (%ccgn)
    (%new-ccgn)
    (f)
    (%set-ccgn foo))

(Again, this is an argument for subtyping closures into continuation and non-continuation functions)

Of course this does have the overhead that whenever continuations are called, we have to do the comparison, and call the current error handler.

2. Error handling. Possibly we could just add to lib-ac.scm.arc:

  (set $default-err
       (fn (e)
         (%pr "Error: ")
         (%prn e)
         (%backtrace)
         (%halt)))
  ; TODO: make this a thread-local in the future!
  (set $curr-err
       (%cons $default-err nil))
  (set err
       (fn (e)
         ((%car $curr-err) e)))
  (set on-err
       (fn (ef f)
         ; <insert continuation guard handling code here>
         (set $curr-err (%cons ef $curr-err))
         (f)
         ; <insert continuation guard handling code here>
         (set $curr-err (%cdr $curr-err))))

Of course, there's the slight problem of how to handle errors reported by the primitives themselves, as well as the runtime system (such as continuation guards being violated, or doing (car #\newline)). We should call the current 'err error handler.

Also, in canonical Arc, the value received by an 'on-err error handler is an opaque "exn:fail" structure, which Arc cannot manipulate. Should we also emulate this structure?

-----

1 point by sacado 6037 days ago | link

1- is interesting and important, thus it should eventually be done, but I don't think this is a priority right now.

2- is a good starting point. For exn:fail, that the same as for 1- : not a top priority, particularily as it is not yet implemented in canonical arc.

I'll work on error handling on the next days, as I'll have a little more time than last week(s).

-----

4 points by almkglor 6012 days ago | link

Further arc2c updates!!

1. Very basic error handling.

2. call* table support!!

TODO list:

1. 'apply function

2. MACROS. Please, someone, help me!!!

3. associating function numbers to names, so that we can do a decent backtrace somehow.

4. Threads and I/O. In particular: nonblocking I/O so that other (green?) threads can run!

-----

2 points by stefano 6012 days ago | link

I've been thinking about implementing macros in a compiled lisp, and I've come up with this solution: when you encounter a macro compile it to a temporary file, compile it as a shared library, load it, execute it and compile the returned value. For this approach to work the compiling environment and the compiled environment should use the same internal representation of data structures, so I think that the best way to get macros working is to have a metacircular compiler first, so arc2c would need to be rewritten in the core Arc that it currently support. I hope this helps. As of real coding help I'm under exams, but I hope to be able to help by the end of June.

BTW, on how many projects are you working currently? :)

-----

1 point by almkglor 6011 days ago | link

non-work related ones? 2, arc2c and my "snap" virtual machine.

Not sure about that solution. Certainly it seems that you need access to the macros on the same "level" as the compiler's code. Ouch, my head hurts.

-----

2 points by bOR_ 6012 days ago | link

Seriously lack the programming-fu to help you there (unfortunately)(just learning how to use macros), but following with interest what you're doing!

-----

2 points by almkglor 6012 days ago | link

apply's done. Next: Macros. ^^

-----

0 points by TookTooMany 6037 days ago | link

If you're bored I'd much rather you create a web front end to the Arc REPL with an auto-update option for version upgrades :)

-----

3 points by almkglor 6037 days ago | link

Try this:

  (create-acct "frug" "yourpassword")
  (writefile1 'frug adminfile*)
  (asv)

Then go to http://127.0.0.1:8080/login and enter "frug" and "yourpassword". Then go to http://127.0.0.1:8080/repl

As for auto-update, well, none yet.

-----

1 point by TookTooMany 6036 days ago | link

Thanks!

-----