Yes, it's a desired feature that a suite can't contain two things with the same name -- either suites, tests, or one suite and one test. This is because I want names to be unique. Saying (test cut.finds-element-in-suite) shuld run only one test.
What you ran into is actually a bug I fixed at a meetup on Tuesday. The current error message is:
Error: "In suite cut, there are two things named finds-element-in-string."
I've updated my script to auto-upgrade Anarki tests[1], and things look pretty good. Just a couple of minor comments:
a) I see a message about redefining assert. Perhaps we should change the name in Anarki or unit-test.arc?
b) The new version complains about duplicate nested suite names inside a test suite. That seems like a reasonable idea, and I just want to confirm that it's intended.
c) If you have a duplicate test name in a suite the error is confusing. Here's the example I ran into from Anarki:
I just want to point out a conversation I had with fauria on GitHub, in case others here have ideas. Currently the HN code doesn't support keeping the HN data (.../anarki/www) on a separate partition from the code (.../anarki) as Docker would like to do to maintain stateless containers. This is because any file creation which performs a create-then-rename first creates the temporary file in .../anarki/tmp. Renames then fail if .../anarki/www is in a different volume.
Heh, no worries. It's taken me, oh, 202 days to update the dang library (I feel like my macro skills have something to be desired, or it would be easier). So no worries about taking four to see this. I was planning on pinging you in a few days if you hadn't seen this.
A coordinated launch would be cool. I'm pretty much ready here; the readme is updated (although it does not explicitly have a version number, which I should add).
But before we get into that, would you mind playing with it a little bit to see if there's anything broken or not working? Thanks.
I've reread the article and You are right, the author's intention seems to be getting rid of unnecessary constructs. I guess then that I'm looking for something that Arc is not (powerful abstractions included in the language from the get-go).
I don't think there is any one particular feature that is groundbreaking in Arc, although as a whole, Arc does have some interesting qualities. For example, code in Arc is much more succinct than code in other languages. When designing Arc, Graham would write a piece of code. He would then look at that piece of code and figure out what features would allow him to make that piece of code shorter. From there, he would implement that feature and rewrite the code. Due to this process, Arc has a large number of very simple utilities (e.g. check). With all of these utilities, code in Arc is much more concise than the equivalent code in other languages.
"Hundred Year Language" is a bit of misnomer. Graham's original essay is a thought experiment on what the language we will be using in a hundred years will look like. Graham believed it would be useful to try and implement the language we will be using in a hundred years and in doing so, came up with Arc.
Others may disagree here, but I don't think Arc was really intended to contain new concepts. The phrasing of "Hundred Year Language" was I think a nod to timelessness rather than novelty. It was an attempt to take questionable novelties out of Lisp (like hygienic macros) and to clean up ill-thought-out interfaces (the keyword choices you alluded to).
Looks like Scala has some experimental macro feature: http://docs.scala-lang.org/overviews/macros/overview.html. I imagine people will be about as likely to use it as they've been to use previous non-lisp macros (i.e. not very likely).
OP isn't about macros because the output of the function isn't automatically evaluated. It's a step in the direction of allowing any programmer to perform compiler transformations and optimizations on his/her own code. I'm very interested in that area.
I think it would be useful to have things built in Arc. That way the language can feel like there's more life in it. Right now there aren't too many things built in Arc that aren't part of the language ecosystem.
I was wondering which pages you're aware of, since that will help put your statements in context. Can you share a few links?
I no longer do much programming in Arc. I mostly just hang out here to talk about interesting programming language ideas, and to answer any questions from newcomers. It's unclear how much benefit there is in polishing a language nobody uses. But if you choose to create new docs I'd love to help proof-read them. Who knows, maybe I'll even be inspired to contribute.
If you've seen something like the Rust Handbook, that would be one end-goal of documentation I would want to implement. For most other programming languages, there's a multitude of resources available for people to study and learn with. Arc just has a couple of web pages focused towards it, to be honest. We have the tutorial and the various documentation on the different functions of the Arc language.So, I DID spot a couple of web pages, but I'm not so sure if they'll be helpful for new programmers to the language.
Responding to my own post is kind of tacky, but it's a good place for me to throw out ideas.
One thing for certain is that I think documentation for newbies needs to be improved HEAVILY. For anyone starting out, they should be able to get a basic application up and running in no time. Still need to figure out a way to host it somewhere.
> I think you should be able to shadow @'s names, and then, if you need them, call them with the @.
Ah, that is a good idea! That can work
> Imagine a service which supports both int/number's actions and variable actions. [...]
I see. I really think that would be an awesome improvement of the language. I have made a git issue for it. And when I have the time I would love to branch the code and make an attempt at it.
Really appreciate your input on the language. Now I just need some spare time to do these things :)
