Arc Forumnew | comments | leaders | submitlogin
rainbow update
7 points by conanite 5794 days ago | 7 comments
Two improvements: it's faster, and it offers command-line args as described at http://arclanguage.org/item?id=6602 . I had previously been lazy with evaluation of lexically-bound symbols; now they're all indexed at macro-expansion time, hence the speed up. It's still not as fast as the scheme version however.

The latest rainbow is available on the git at http://github.com/conanite/rainbow/tree/master and a source zip is at http://www.softify.com/rainbow-src.zip

What do you think would be useful to do next in a java implementation of arc? Here are some ideas:

  - anarki compatibility
  - java interface (as suggested in http://arclanguage.org/item?id=6655 for library access)
  - byte-compile for better performance (suspect this is not possible with continuations and TCO)
  - java-web-start launcher
(I'd love to make a poll out of this but I can't, is it a karma thing?)

These are the functions I had imagined for a java interface: am I missing anything, or is this over the top?

  (java-new "classname")   ; --> new com.foo.Foo()
  (java-class "classname") ; --> Foo.class
  (java-invoke object 'method) ; --> myFoo.bar()
  (java-static-invoke object 'method) ; --> Foo.toto()
  (java-field object 'field [value]) ; --> foo.baz; foo.baz = true;
  (java-static-field object 'field [value]) ; --> Foo.yadda
  (java-new-implementation "interface-name" table) ; --> new MouseListener() { public void onMouseDown(MouseEvent e) { /* do stuff */ } }
Rainbow is on github and is open to modification by anybody.


4 points by almkglor 5794 days ago | link

http://arclanguage.com/newpoll

It's not linked to at all yet, you have to be "in the know" so to speak.

As an aside, I think someone mentioned that rainbow has "true" local macros, but ArcN and Anarki does not: i.e. macros that are shadowed by 'let, 'with, or function parameter names are overridden. Since "true" local macros would be difficult to compile except with a full data flow analysis, we might expect you to reverse this otherwise desirable behavior to be more ArcN/Anarki compatible.

Basically macroexpansion will have to be done before actual evaluation, using only global bindings for macros, which is how ArcN does it (and, of course, which is the "spec", hahaha).

Some features in Anarki that will require modification of the base set:

1.

  defcall
This is implemented by using an Arc-accessible hashtable. Basically your 'apply function has to lookup the type of the object being applied in this hashtable, and use the function you get, unless it's a 'fn:

  (def arc-apply (hd args)
    (case (arc-type hd)
      fn (apply-function hd args)
      ; else
         (let handler ((arc-symeval 'call*) (arc-type hd))
           (if handler
               (apply-function handler hd args)
               (err "Call on inappropriate object")))))
Note that 'arc-type above is different from the arc-side type ^^. The arc-side 'type can be redefined from Arc, but we don't expect you to use the redefined 'type (redefining 'type is used to fool Arc code, i.e. to create 'file-table that quacks like a 'table, but it depends on the base call* system actually working properly)

Note that you (or we could implement it, for that matter) could possibly use the 'defcall system to transform (java-field object 'field) to (object 'field) - you just have to give a good type code for java objects. We can then redefine (sref ....) to accept (sref object value 'field), where object is a java object, as a call to (java-field object 'field value)

2.

  thread-local ; thread-local boxes
  sema ; semaphores
thread-locals are boxes whose contents are settable per-thread. Currently child threads inherit the contents of the parent thread's thread-locals. thread-local objects are accessible via thread-local-ref and thread-local-set in the base system, but arc.arc helpfully redefines 'sref and adds an entry to the call* table:

  (sref call* thread-local-ref 'thread-local)
  ((fn (old)
    (set sref
      (fn (c v . i)
        (if (is (type c) 'thread-local)
            (thread-local-set c v)
            (apply old c v i)))))
   sref)
So, yes, for full Anarki compatibility your first priority is the call* table/defcall.

3.

  ssyntax
  ssexpand
In ArcN only 'ssyntax is accessible from Arc-side; 'ssyntax simply returns a boolean which determines if the symbol has ssyntax, while ssexpand (not on ArcN!) performs the actual expansion. Note that ssexpand may return symbols with ssyntax (i.e. it's assured of expanding only once).

In Anarki, the base system actually uses the Arc-side 'ssyntax and 'ssexpand. By default they are defined in 'ac.scm, but they can be redefined in Arc-side: http://www.arclanguage.org/item?id=6370

-----

1 point by conanite 5791 days ago | link

These are the functions defined in anarki's current ac.scm that aren't in arc2:

  quotient
  vec
  vec-ref
  vec-set
  ref
  which-os
  make-directory
  make-directory*
  datetbl
  seval
  connect-socket
  flush-socket
  pipe
  pipe-len
  thread-local
  thread-local-ref
  thread-local-set
  sema
  sema-wait
  sema-post
  sync
  synct

defcall support - done

inheritable thread-locals? ouch! java has non-inheritable thread-locals out of the box, but if inheritance is really important it could be done ...

scheme semaphores appear to work much like java's wait/notify ... does anybody know java and scheme well enough to comment? Or where is a good place to find scheme docs?

> In ArcN only 'ssyntax is accessible from Arc-side

I don't understand: ssexpand is also callable from arc. Do you mean the arc-side definition of ssexpand is not necessarily the one used by the base system?

'ssexpand appears to be invoked at the same time as macro-expansion - is this correct? I'm guessing that the base system should invoke the ssexpand defined in arc in order to expand symbols correctly.

Does any anarki code depend on the implementation of 'annotate using vectors? Rainbow uses a custom "Tagged" class, and anything that assumes 'annotate returns a vector would break in this case.

-----

1 point by almkglor 5791 days ago | link

> inheritable thread-locals?

Err, this is just what I defaulted it to. Normally underlying scheme doesn't default to inheritable, but I thought it might be useful.

Note that as of now there are zero applications/libs which make use of thread-locals, and there are zero applications that require inheritability. In theory, you could still safely modify Anarki's thread-locals away from that default, but then what if...

> scheme semaphores appear to work much like java's wait/notify

Being a complete JAva noob, I wouldn't actually know. However in the mzscheme docs a semaphore is a synchronized up/down counter. A wait (via 'sema-wait) on a semaphore will wait for the counter to be nonzero. A post (via 'sema-post) on the semaphore will wait for the counter to be nonzero, and then decrement it. So it's really a generalization of a mutex (which is just a flag).

I'm building a shared-nothing message-passing processes library which depends on the "counter" behavior (specifically the semaphore contains the number of messages that the process has received that it hasn't put into its own mailbox yet.)

> > In ArcN only 'ssyntax is accessible from Arc-side

> I don't understand: ssexpand is also callable from arc.

This is correct. My bad ^^

> 'ssexpand appears to be invoked at the same time as macro-expansion - is this correct?

Yes.

> I'm guessing that the base system should invoke the ssexpand defined in arc in order to expand symbols correctly.

For Anarki compatibility.

As an aside, this feature is currently unused in Anarki because of the severe slowdown in macroexpansion.

> Does any anarki code depend on the implementation of 'annotate using vectors?

Yes, lib/settable-fn.arc . However, take note that this was written before defcall, and in fact 'defcall was written in response to this. lib/settable-fn2.arc is a rewrite which uses 'defcall.

-----

2 points by stefano 5794 days ago | link

I'd really like a Java interface!

-----

2 points by sacado 5793 days ago | link

Yep. A java interface would give access to so many libraries that it would solve a lot of problems as for arc's lack of popularity...

-----

2 points by conanite 5791 days ago | link

working on it. Are there any libraries you're thinking of using already?

-----

2 points by stefano 5791 days ago | link

Being able to access graphic libraries would be great.

-----