See how it uses LUA_BIN = "bin/lua"? Apparently SL4A is set up to execute a native application in a separate process. Lua for instance builds from a C project. The agcc/ folder probably has something to do with this (just to throw out vague vacuous suggestions ^^ ).
As far as JRuby goes though, I really like Ruboto IRB, a completely separate project. Or is it? At one point I think I heard that Ruboto IRB kinda branched off of SL4A. Not trying to start rumors, just not equipped with a convenient way to check my facts right now. :-p
Yeah, I guess Rainbow doesn't bother with bignums. Jarc has exactly the same result, probably because they both use JVM longs. They both still let us use JVM bignums the long way though:
; This code will work on both Rainbow and Jarc.
(when (errsafe jarc.Jarc.class) use!rainbow)
(def big (x)
(java-static-invoke "java.math.BigInteger" 'valueOf x))
(def bigfact (x)
(if (< x 0) nil
(< 0 x) ((bigfact:- x 1) 'multiply big.x)
big.1))
Rainbow:
arc> (= foo bigfact.50)
30414093201713378043612608166064768844377641568960512000000000000
arc> type.foo
java-object
arc> foo!getClass
class java.math.BigInteger
Jarc:
Jarc> (= foo bigfact.50)
#java.math.BigInteger(743210128)
Jarc> foo!toString
"30414093201713378043612608166064768844377641568960512000000000000"
Jarc> type.foo
java.math.BigInteger
Jarc> foo!getClass
#class(java.math.BigInteger)
I used http://af.searchyc.com/ a lot, but for the past month or two I was noticing new posts weren't showing up in the search results, so I kinda expected something to happen to it pretty soon anyway.
I'm having a lot of "shoulda mentioned that earlier" moments recently. O-o;
This is a bit off-topic, but despite your best efforts, you are probably not using the latest version of Arc. Sounds like you've been following the instructions at http://www.arclanguage.org/install for the whole time you've been posting here, and those are out of date by almost two years, even linking to a version of Arc 3 (one of a few Arc 3s, I think :-p ) instead of Arc 3.1. I think this is a better starting resource: http://sites.google.com/site/arclanguagewiki/.
Old versions of Arc needed to run on MzScheme 372 because it was the last MzScheme with mutable lists, but now Arc 3.1 uses some pointer manipulation to mutate lists behind Racket's back, meaning any version of Racket is fine. However, this actually introduced a rare garbage collection bug, if you can believe it. ;) That means there is actually a legitimate reason to keep using MzScheme 372, but as described at http://sites.google.com/site/arclanguagewiki/arc-3_1/known-b..., pretty much every Arc setup besides the official one avoids this bug, and it's possible to patch the official one too.
Anyway, you're the first person I've heard of who's tried Arc on Windows 7 (which isn't to say there aren't Arc Forum lurkers in the same position ^_^ ). If you encounter Arc-on-Windows-7 stumbling blocks, please continue talking about them like you have in this thread!
The -m option means to call the "main" function now. Just leave it out. It used to mean "--mute-banner", which suppressed the "Welcome to MzScheme" line.
That "racket -f as.scm" command is the right one. The 'setuid issue is one of a few known issues on Windows, and it has a known fix: http://arclanguage.org/item?id=10625.
That "reference to undefined identifier: _M" error happens for me all the time. If I copy from a CRLF source into a console window on Windows XP, and then I complete the entry by just pressing enter, then all the versions of MzScheme/Racket I've used get confused about what counts as a newline. They apparently treat carriage returns as a capital M (in MzScheme) or a capital R (in Racket v5.1.1).
Scary that the letter corresponds with the name of the application. ^^; Actually, by the time the Racket rename happened, I was already in the habit of working around this by including newlines at the end of what I was pasting, so I never noticed Racket treated it as an R until just now....
Nice. Since we're on different versions of Windows, I can totally believe that. But you only got it for one definition of factorial and not the other? Did you type them in differently somehow? (Say, by putting a newline at the beginning of the second one, or by entering the first one as the very first command of the REPL session?)
Actually, there's a chance I may be able to even though I'm on XP, since it may have more to do with the version of MzScheme being used. I'll see what I can do.
I think that was my original theory. I probably even saw the R at some point, thought it came about because of the \r escape sequence, and forgot it wasn't like that all along.
Keep in mind that the underscore is added by the Arc compiler though. The M or R is being successfully compiled as a global variable reference. ^_^
Use (quit) to quit, (tl) to return here after an interrupt.
arc>
'(
Pocket-N/A)
(Rocket-N/A)
arc>
Guess Pauan broke the link by replacing the master branch with one that could be pull-requested back into awwx/ar. Here's import.arc on the "old" branch: https://github.com/Pauan/ar/blob/old/lib/import.arc
By the way, Pauan, how did you manage to make that switch? Your GitHub history has an entry that says "master is now 2be9ac7", and your pull commit worked out better than mine did. I'd like to know your secret. ^_^
Yeah, sorry, that was intentional, but I didn't realize the links would break. In hindsight, I should have.
Well, it's pretty simple[1], really. I used git fetch upstream to grab all the changes from ar. Then I used git reset --hard to reset my master branch to ar's branch, completely destroying everything on my branch, including commits.
Then I used git push -f to force my changes onto GitHub. Voila, now my fork is in the exact same state as ar. Of course, before I did all that, I created the old branch, so I wouldn't lose my work. Here's roughly what I did:
git branch old
git push origin old
... do stuff ...
git fetch upstream
git reset --hard 2be9ac75f67edfe9b3c43a9515dd78acebba6f1c
git push -f origin
At least, I think that's what I did. I actually had to experiment and mess up some stuff before I figured out how to do it. So my directions may be wrong and you may bork your repo!
But their directions are somewhat different from mine. I don't think I needed git pull for instance, and git push origin :master didn't work for me. So I had to use -f to force the push, since git was kindly telling me that it might destroy my commits (which I wanted to do).
---
After using git for a while, I gotta say, I like it a lot more than Mercurial. git gives you the power to do stuff, whereas Mercurial seems to hold your hand a lot more, and say, "no I can't let you do that, Dave"
Now, I'm not saying Mercurial is bad, just that I like the raw power of git, in the same way that I like the raw power of Arc. So for me personally, git seems to be the winner.
It's too bad the links break. But wait, the pull requests' links don't break, because they link directly to the blobs.... I bet the blobs will stick around as long as at least some branch points to them, so playing fast and loose with lots of branch-renaming is only going to hurt tip-of-branch links. Too bad GitHub doesn't have some way to specify redirects (or at least I think it doesn't).
Also, I'm not actually sure how well my old branch actually works, since I've moved onto working on ar. I do plan to port import.arc so it works on ar, since ar now has defcall (yay).
In Lathe/arc, I filter on the first argument's type using "ontype" or multiple first arguments' types using "ontypes":
(use-fromwds-as rc (+ lathe-dir* "orc/orc.arc"))
(= my (nspace))
; These are already defined in orc.arc, but I'm redefining them here
; for the sake of example.
(rc:ontypes rc.oiso2 (a b) (cons cons) my.cons
(and (rc.oiso2 car.a car.b) (rc.oiso2 cdr.a cdr.b)))
(rc:ontype rc.otestify () fn my.fn
self)
; General pattern:
;
; (rc:ontypes <rulebook> <parameters>
; (<type of a leading parameter> ...) <rule label (optional)>
; <implementation>)
;
; (rc:ontype <rulebook> <parameters other than the first>
; <type of the first parameter> <rule label (optional)>
; <implementation, where "self" is the first parameter>)
In orc.arc, this comes with an inheritance system I don't use much, but I've found I use 'ontype itself a lot when defining new types. Porting the inheritance system would be hard without porting Lathe's rule precedence system along with it.
In lathe.js, I recently tried adding lathe.instanceofRule( ... ), which defines rules that check the type of their first argument. This was largely a failure, as it clutters up the signature line so much that I end up spreading it over three lines of code, when often I could have had a one-line signature and a one-line explicit check. I haven't given up on it completely, though, since it decreases my token count slightly. :-p
I feel like having an implicit variable for the namespace is a bit of a low-level approach, since the core Racket namespace tools default to the dynamic (current-namespace) already. That's also an intuitive default for them to have, so I don't see anything wrong with Arc code doing it the same way. Whether or not it's beneficial in an in-the-large way, at least it's concise.
Anyway, how about this for "multiple layers of function calls": If you call 'load, that calls 'eval. Two whole layers! ^_^
---
"I think "namespace" may be too narrow a description since a runtime may have other configuration settings (such as how it handles optimizations) besides just which global variables it has."
I agree. I think "runtime" is a pretty good name for what you're headed for. :)
"I feel like having an implicit variable for the namespace is a bit of a low-level approach, since the core Racket namespace tools default to the dynamic (current-namespace) already."
Yeah, I have nothing against making macros or functions that handle namespaces in other ways, but I'd rather have a simple and concise low-level way too.
---
"I agree. I think "runtime" is a pretty good name for what you're headed for. :)"
Yeah, but I think the word "namespace" makes perfect sense for my library, especially considering that a namespace is a simple mapping between names and values. You can even pass in tables, so I think "namespace" is just fine.
Of course, in ar itself, using "runtime" is also perfectly fine, because ar namespaces might contain things other than a simple mapping, so I don't see a problem with ar using "runtime" and my library using "namespace".
My rulebooks aren't what you're thinking, I think. They're only a more bureaucratic kind of 'extend. I tend to store extensible operators as mutable collections of extensions, which mostly comes in handy so I can store a reference to a rulebook somewhere (like in a variable in a namespace) before all the extensions have been introduced, and it'll automatically reflect those later extensions. I can also sort rulebooks to establish precedence or peek into rulebooks to troubleshoot individual rules without leaving the REPL.
Whether you would actually use such a macro in practice, I don't know, but it was relevant to my point that you can use a macro to make extending less verbose.
My apologies for using the term "rulebooks", I couldn't recall the name of the macro you were describing.
Oh, I implemented 'def-extension-type in lathe.js as lathe.deftype().
// Define a constructor _.Seq and a rulebook _.iffirstRb.
lathe.deftype( _, "Seq", "iffirstRb" );
// Define a constructor _.Seq using an existing rulebook.
lathe.deftype( _, "Seq", _.iffirstRb );
This is not to be confused with the 'deftype I was talking about in that thread. >.>
I use it in exactly two places so far, and the rest of the time I've been cheating by defining types in a more traditional OO JavaScript way. But I'm totally interested in figuring out things like this that could help. I think Traits.js is a pretty interesting option for this, and I'm not against message-passing at this point either. ^_^
