Arc Forumnew | comments | leaders | submitlogin
6 points by absz 6143 days ago | link | parent

Beautiful, nex3. Works exactly like I had been thinking about. But I'm not sure that making the table live in Arc is the best idea... it relies on a table of a certain name, which I think is slightly odd. Nevertheless, excellent--including the move of everything but functions into arc.arc. Exactly how it should work. Thank you.

Now, if I could only understand defset, I'd be all set... :)



5 points by nex3 6143 days ago | link

I put the table in Arc because I was trying to make it work as closely as possible to stuff like defset and help. Although it is a little weird to have the core code relying on stuff going on in Arc-land, I think that's going to be necessary to give Arc as much power as possible.

Also, the core code only relies on call to be defined when it's actually trying to resolve a functional-position object. Doing something like (= call nil) will only fail when you actually try to use a non-function object as a function.

-----

3 points by absz 6143 days ago | link

That's a good point. And I do understand when it will fail, it just seemed odd. But you do make a good point about the power; it also reduces the number of axioms.

-----

4 points by CatDancer 6143 days ago | link

Think of it that the ideal Arc would be written entirely in Arc, except that some parts are written in Scheme for performance reasons or to allow something to actually run.

-----

7 points by kens 6143 days ago | link

I've been thinking that the Scheme code (ac.scm) should be split in two parts: an "axiomatic" part that defines car, cdr, set, annotate, etc; and a "library" part. The "library" part would define OS stuff like current-gc-milliseconds, open-socket, probably atomic-invoke, etc. There would probably be a "math" library that defines exp, sqrt, and all the missing math functions.

This structure would make it clear what parts of the language are really axioms, and what parts are in Scheme for performance, convenience, or because they are OS things that require low-level hooks.

-----

3 points by sacado 6142 days ago | link

"in Scheme for performance" : in never thought I would ever read that sentence :) (You're right, by the way)

-----

1 point by CatDancer 6143 days ago | link

Being able to call out to MzScheme from Arc would be cool. Then all the "library" parts could be written in Arc.

  (def file-exists (name)
    (scheme-istrue ((scheme-fn file-exists?) name)))
Here "scheme-fn" is a macro that returns an Arc function that calls the named Scheme function, but still expects to be passed Scheme values and returns a Scheme value. Then various functions such as "scheme-istrue" can be used to convert Arc values to Scheme values and back again.

-----

5 points by kens 6143 days ago | link

Anarki provides the $ operator, which allows callout to MzScheme.

I've been thinking that support for a foreign function interface such as SWIG would also be good.

-----

6 points by nex3 6143 days ago | link

Anarki has a macro, $, for just this. In general, I've taken to using $ for what kens refers to as the "library" part. Note, for example, files.arc.

-----

1 point by CatDancer 6142 days ago | link

Very nice!

-----