If the Arc Forum adds a link to anything, I hope it adds a link to the community-maintained Arc website (https://arclanguage.github.io/). We can add links to other resources from there.
"Programs written by individual hackers tend to follow the scratch-an-itch model. These programs will solve the problem that the hacker, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone hacker's own setup, but may not be portable to other Scheme implementations or to the same Scheme implementation on other platforms. Documentation may be lacking. Being essentially a project done in the hacker's copious free time, the program is liable to suffer should real-life responsibilities intrude on the hacker. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem."
Yeah! It might be a little confusing for people who lurk here and don't follow the discussion into the Slack, but I think a Slack would open up some communication opportunities.
I wonder if anyone would like to try writing a Slack bot in Arc. :)
Yeah, there were several such stories during what I think of as Lisp's angsty mid-life crisis during and after the AI winter :) A couple more good ones:
The error has to do with looking up the variable "Rtl". The "R" probably comes from a bug in Racket's reader where certain things pasted into a Windows terminal window are parsed incorrectly. Where you typed "(tl)", somehow it saw "Rtl)".
In my experience, the bug doesn't occur as long as the text I'm pasting has a newline at the end. Maybe you could try that. That is, instead of just selecting the text you want to copy, select a blank line after it too.
Alternatively, you could type everything by hand instead of pasting... but that sounds pretty painful. Hopefully you don't have to resort to that.
EDIT: I tried to reproduce that pasting issue with Racket 6.4 on Windows 10, and I don't get it anymore. You're using Racket 6.4 too, so are you using a particular version of Windows?
I would want to follow my mzscheme instructions to install arc, but I'll let it pass for now because i want us to solved this Issue.. If I do that your instructions might work but not knowing what's exactly going on without mzscheme, (i think so) :)
[issue] "I've reformatted my Windows and tried your installations instructions above. When I first followed this instructions it worked out just fin [maybe because of the prior mzscheme installations I've made my own]. This time around I'm following your instructions without first installing my first instruction method, and here's the error:
Hello, I have launched a study group at https://www.facebook.com/groups/arcofili/ that aims to program Arc language in Arch Linux but not in computers but inside of single board computers [SBC], i.e. ODroid - C2
I can't really answer that. Somebody would need to write an "eval" function in Arc. That would give you a pretty good starting point for figuring out how many axioms you need.
I'm wondering first, exactly what axioms pg settled on. And I'm also curious as you've described it, if the hardware were built for the language and rather than the language being built for the hardware, "what is the least number of axioms need for a practical language".
Well... the axioms of Arc are enumerated in the source code. But that might not be satisfying unless you think Racket is a simple metatheory. :)
Even mathematical axiom systems are always in terms of some metatheory, and the metatheory itself might be in doubt. There's no right answer.
That said, Arc's implementation in terms of Racket is rather large and ad-hoc, and Racket's own implementation is rather large and ad-hoc. There are nicer foundations than these already, like Martin-Löf type theory.
1) What is the least number of axioms needed for a practical language?
2) What is the least number of axioms needed to write an evaluator for the language in the language itself?
As I demonstrated, you need a lot of axioms to support practical programming, because practical programming involves I/O, threads, sockets, exceptions, etc.
Trying to find the smallest axioms necessary for I/O is a cool idea. But any I/O axioms will be intimately tied to the hardware, and the hardware is currently more C based than Lisp based. So the result won't be very elegant.
If you ignore practical programming and I/O, and only care about mathematical elegance, then McCarthy's original Lisp is already a quite good answer for question number 2.
Arc is quite a bit more elegant than most other programming languages, but at the end of the day it is still a practical language.
So my question to you is: what are you looking for?
I thought that was the whole thing that pg was arguing/exploring. 'What's the least number of axioms necessary for a practical programming language?' And that arc was the product of that exercise.
"Of course, as soon as McCarthy's spec fell into the hands of hackers, all this theorizing was cut short. In Lisp 1.5, read and print were not written in Lisp. Given the hardware available at the time, there is no way they could have been. But things are different now. With present-day hardware you can continue till you have a runnable spec for a complete programming language. So that's what I've been doing.
The question I'm trying to answer at the moment is, what operators do you have to add to the original seven in order to be able to write an eval for a complete programming language?
I'm not finished yet with this exercise, but so far I've been surprised by how few primitives you need to add to the core in order to make these things work. I think all you need to define new types is three new primitives (plus assignment and lexical scope). One of the new primitives replaces the original atom, so you still only end up with nine total."
Arbitrary metadata is cool. Clojure has arbitrary metadata, which the compiler uses to optimize function performance, but you can use it for other purposes as well:
You're right: dynamic type systems tend to provide very weak guarantees. But I'll still take those guarantees over silent failures.
In my opinion, static guarantees (including static types) are the best, followed by unit tests, followed by dynamic guarantees (including dynamic types).
