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)
Also, may I suggest indenting lines by just two spaces rather than the length of the first word. It would alleviate the horizontal scrolling on the page. Let me know if you're ok with it, and I'll fix it for you.
(I'm not presuming to suggest how you should indent your code in general, of course.)
Please go ahead and fix it. The indentation here is a direct result of Emacs's default Lisp indentation settings. I haven't bothered to change it, both because it feels difficult, and because I keep vacillating between which way is actually better. But that's another discussion entirely.
"Many of us are using Arc because it's not Python."
"I call Python from Arc when there's a Python library that would be useful to me."
Yup, I agree with both of those. Python is ew compared to Arc, but it does have some nice libraries.
Incidentally, I started on Arubic for fun, to learn more about how an Arc interpreter works, and also to enable nice integration with Python. Then I can finally use multi-expression lambdas with Python. :P
Oh yeah, and change some stuff that I felt Arc was lacking in.
Plus, I like Python better than Racket. So if I'm going to hack in one of the two...
Seems interesting, but kinda heavy-weight. If the Python version of Arubic were in better shape, I might recommend that, but it doesn't have a Python compatibility layer yet, and I've gotten sidetracked implementing Arubic in ar/Arc.
Seems like there's a significant disconnect in this thread.
I think d0m's saying: Why do Arc folks do things like X by making a new language? Shouldn't we put features in Arc itself, if it's going to be a language people will actually use?
I think aw's saying: Why not ask instead, "How can I do X in Arc?" In fact, here's a way I do X without making a new language.
I think Pauan's saying: I'd like to do X, and aw's approach seems clunky. I think a new language would be better.
---
As I see things, d0m, we pursue our own languages because there are certain improvements we want to make that take a complete rework of the language.
Python interop is a great example. Clojure-Java interop is possible because they both run on the same rather high-level platform, the JVM. Official Arc runs on the Racket runtime, and Python (at least CPython) is its own whole runtime, so there aren't many ways to bridge the gap except for the C FFIs and the kind of IPC aw's lang hack uses. One of the best ways to get a clean integration between Python and Arc would be to reimplement Arc and/or Python to run on the same high-level platform--and yet that means reimplementing a language, rather than improving an existing one.
Or does it? The reimplementations may already exist. If you could use Jython for your Python project, then you could probably achieve a good degree of interoperability with Jarc and Rainbow, which are high-quality Arc implementations for the JVM.
---
But really I think Python interop was only one example, and your point was any that features we could put into the main Arc language should be put there. In that case, you'll need to define what counts as Arc.
There's an official release of Arc, maintained by Paul Graham, but keep in mind that he only updates once in a blue moon and tends to leave out features that aren't obviously necessary to him. A brief language implementation is one of his primary goals for Arc.
We do have Anarki, a community fork of Arc, but keep in mind that Anarki is held back a little by a desire to be similar to official Arc, so that the next time Paul Graham releases an update, it's easy to merge it in. This similarity also makes Anarki a bit more useful in practice, since it's compatible with most official-Arc code people write.
We could probably relax that policy on Anarki, but what big changes should we allow? I'd make radical changes and turn it into Penknife. Pauan would make sorta big changes and turn it into Arubic. It could be useful to make radical implementation changes and turn it into aw's ar, and akkartik may want to radically reorganize the project's file tree.
All in all, Arc's philosophy isn't well-defined and persuasive enough to drive us all toward the same future. Although we do want to make big changes, it's easy for us to be unsure about them or disagree. So we tend to experiment with big ideas by implementing them in our own language projects, where at least we know what we like.
If it helps, think of it this way: We don't make our own languages just to let Arc stagnate. We make our own languages so that we can improve Arc in various ways all at once. This fracturing is kind of unfortunate, but we still do build upon each other's ideas, so we're just advancing the state of the Arc in an unusual way. ^_^
Still, I suppose it means we have a community that's a little hard for non-language-implementors to appreciate. There are some less vocal people who talk about Arc only for Arc, like thaddeus and kens, but even then the topic can diverge to how our fractured Arc variants deal with the issue. :-p But you know, I wouldn't have it any other way. Maybe if the community were larger, we could have separate forums for in-Arc and around-Arc discussions.
I suspect that for the most common uses the disadvantages of providing language interoperability in the same process outweigh the advantages, and so personally I'd be surprised if implementing Python and Arc in the same runtime would have much impact on the uptake of Arc. I could be wrong of course... and then I'd be surprised :-)
With respect to there being lots of variants of Arc, I think about Arc as a personal programming language. Thus that it allows extensive personalization, and people publish many personal variants, is to my mind a feature not a bug.
This diversity of course raises its own issues: we're concerned not just with interoperability between Arc and other languages, but interoperability between variants of Arc! :-) But solving this provides a more powerful platform than one stuck with providing the lowest common denominator of standard language features to ensure interoperability.
I also think that the idea of personal programming languages remains largely unexplored territory. Thus if there is significant uptake of Arc, I imagine it may not come at the expense of other languages, but instead it could be for new uses. Because of this belief I tend not to pay much attention when someone says "Arc should have X because other languages have it", but I'm very interested when someone says "I'd like to use Arc myself, and I'd be able to if only it had X".
"I suspect that for the most common uses the disadvantages of providing language interoperability in the same process outweigh the advantages"
I've never thought of that. I'm used to using Racket stuff from Arc without hesitation, but then the stuff I use is provided with the Racket language, like parameters and regexes. Most of my non-Arc personal code is in Java or Groovy, and I'm very glad I can use it from Rainbow, but I haven't actually done that yet....
Still, I can personally attest that this kind of feature has played a role in my adoption of languages, regardless of whether I've used it. :)
Through-out this whole thread I've wanted to kick in and say: "boy I wish Arc was built on top the jvm, similar to Clojure's implementation", but then I also realize one might as well just switch to Clojure if that's what one wants.
Would have been be nice though. Smart move by Rich.
The way clojure implemented it allows for seamless integration between libraries. With clojure I can load and easily make use of any java code out there. I can use cron job libraries, database libraries etc. etc. And I really don't require much java knowledge, just a basic API used to call the library/jar file. This gets people on-board, hence larger community, building all kinds of kewl apps/libraries... More solutions, more knowledge base... Just more options.
With arc, the language syntax and base libraries are awesome, but you scratch your head more often, wondering" well how the hell am I supposed to do that. " And these problems/features are not small roadblocks... For example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen.
If arc were built atop the jvm, the way clojure is... These problems all go away.
Thanks for the offer. I think real database connections to arc could only improve the adoption + user happiness levels, but I will suggest connecting to oracle was just an example for the point I was trying to make.
What I am suggesting is not new or even surprising. Arc has no depth for libraries. Rich solved this problem right from the get-go by having tight integration with java. Arc would have had similar success had it done the same thing - too bad really. And dropping into Scheme just doesn't cut it.
I'm suggesting users of arc will google things like 'arc oracle', or even 'scheme oracle' which returns jack. With Arc you get Nada for google answers + you get unanswered posts such as these.
step-by-step recipes to connect to a myriad of databases. This was made possible through Clojures tight integration with java. Clojure can import java libraries with 1 simple import statement.
Let's not forget that Clojure is a newer language than Arc - correct?
Now, I'm just looking at the title of the thread "Effort to make it easy to use in production?", and thinking - yeah, I can understand, that's why I moved over to Clojure and its too bad Arc didn't do this.
Sure I'm no expert in the programming language industry, but if I were to come up with a new spiffy language I'd rather do what Rich did. Arc could have been built atop the jvm - correct? It was just easier not to, considering arc was not about being practical, it was about attaining some elusive mystical idealized syntax that will be practical in, possibly, a hundred years from now.
Sorry if this sounds like a rant, but it just seems like the original poster wasn't getting much love, and I can appreciate what and why he/she was asking.
When I started work on my Arc runtime project, the first thing I looked at was what I thought would be the best platform to write the runtime on top of. Racket seemed to be moving away from Arc in some ways, so I didn't start with the assumption that Racket was going to be the right choice. I looked at a number of options, and concluded that as far as I could tell that Racket still had the best mix of features.
The JVM naturally has the advantage that it's easy to call Java libraries, but it has the disadvantage that it has no built-in support for tail call optimization or continuations. Since it's not particularly difficult to make use of libraries running in a different process, it would be easy enough for me to use Java libraries from an Arc implemented in Racket if I wanted to, and so I had no compelling reason to write ar on top of the JVM.
There is a long history of languages written for people who want to use the JVM but who also want to be able to use a less terrible language than Java: Jython, Groovy, Clojure, etc. Since Clojure is a particularly nice language, it didn't surprise me that it rapidly gained popularity among people who want to use the JVM.
For any particular project that I may be working on, there are a mix of features that I need for that project. If I were working on a project that primarily needed to call Java libraries and I didn't need the features unique to Arc, I would most likely use Clojure myself (or Rainbow or Jarc, if it turned out that one of those were suitable to my project). If I were working on a project where the features of Arc were important and I also needed to call some Java libraries, I'd likely write it in Arc calling out to Java libraries.
Since this is a forum for Arc, I answer questions primarily from the perspective of Arc. Since typically a hundred people will browse a forum for each person posting, I primarily answer questions for the majority reading. For example, if someone makes a statement that is wrong, I will say that they are wrong, so that someone else reading the forum isn't left with incorrect facts.
When someone complains about Arc, I tend to suspect that either there's something they want, or else they just feel like complaining. People wanting things is useful. If someone actually wants X and says so, and we come up with a solution for them, then we also help the hundred other people who want that thing as well. Other the other hand, and I'm not saying that anyone has actually done this, but if someone were to sit at a computer and type in a complaint that other people haven't done the work to make Arc a popular language faster than some other language has become popular, that doesn't strike me as being particularly useful.
I'm not against complaining. Complaining is often a useful first step towards finding a solution. However, while I'm not trying to pass judgement, I am trying to discern whether someone is complaining because they just want to complain or because they want a solution.
Again, when I answer a question, I answer a question primarily for people in general reading the forum; and from the perspective of people wanting to use Arc. Thus if Clojure is a better solution for you for most of the projects that you work on, that's fine, I agree you should use Clojure. However when I read "for example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen" my immediate concern is that someone else is going to read that and might be left with the impression that it's prohibitory difficult to connect to oracle from Arc... which, while it's certainly harder to connect to oracle from Arc than it is from Clojure, isn't all that difficult.
Being difficult or easy is a relative thing. The hours of investment by grade-a developers contributing to making these production grade feature-x's in other languages leads me to feel pretty comfortable suggest that having them,
or a dozen other similar feature-x's would not be all that easy.
Sure, if you have spent hundreds of hours doing low level hacking between racket<->arc you can suggest these things are not all that hard, but the reality is that many of these feature-x's are just not going to happen.
Chances are that mainstream features are not a priority for the members here... And that's my message to the OP: go use Clojure or something having the features you want. I say this from 2 years of following arc, the arc forum and its members. There are probably a dozen submissions/comments about db connects and FFI, yet to this day nothing works.
The people on this forum, who know me, know I like the arc language, often promote it and that I'm not here to tear it apart, but I'm going to be real about it and make sure the op gets the right message (from my perspective).
> "If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?"
I'm thinking if you re-read the thread starting from my first comment (http://arclanguage.org/item?id=14539), you'll hopefully come to understand that I haven't been complaining, but rather I have been defending/substantiating my suggestions and thoughts.
As for why I don't take time to describe some spec, well because I'm not asking for anything and I've chosen to spend the bulk of my time learning Clojure and building applications. I guess you could say I take my own advice.
> "If you want some love on the forum, there's an easy way to get that:make a useful contribution."
It's pretty obvious, based upon your replies, that you don't see my posts as valuable contributions, but maybe you'll come to understand these posts are intended to help the OP rationalize his topic, not to gain some form popularity/acceptance with or by you.
If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?
Or, you could add a page to the wiki describing the ways that Clojure is better than Arc.
If you want some love on the forum, there's an easy way to get that: make a useful contribution.
If the JARs are in the classpath, the classes are just as accessible as any standard platform class like java.util.Map. I give a demonstration here, where I explain the custom interface I built so I could sometimes use the same code on both platforms: http://rocketnia.wordpress.com/2010/06/01/lathes-arc-to-impl...
Since then, Jarc's actually added Rainbow compatibility functions, so you might be able to get away with writing code just for Rainbow without leaving Jarc too far behind. Rainbow's faster, but Jarc has a more straightforward implementation.
I recommend having one of the JARs be a language with eval, like Groovy, JRuby, or Clojure. Jarc and Rainbow convert certain values to/from Arc in ways that are nice most of the time but sometimes lose precision, like the distinction between Boolean.FALSE and null.
Bravo. I'm bookmarking this comment. Next time we get a question about fragmentation I'll point to the final section.
---
I didn't plan to hack on programming languages when I started playing with arc. Creating new languages/implementations is an occupational hazard of hacking on arc. Or maybe it's a pleasant side effect that we get for free (a viral - and rapidly mutating - language). Depends on how you look at it.
---
I think it's beneficial that these variants aren't splitting off into their own communities. They're able to recombine features from each other. wart stole its iteratively-refined interpreter cond from ar. Pauan's gotten me thinking about message passing.
For what it's worth, everything I use Arc for is the Arc3.1 codebase -- I don't use Anarki, or any of the other alternative Arcs. What makes you think you have to "hack up a new implementation"?
As a side note, I have no idea what you mean when you say "hacking in Hack". What is the second "hack" there?
I'm not sure if you've seen it, but arcfn.com is a great arc reference guide: http://files.arcfn.com/doc/ There are a few things that I've found are out of date, but it's mostly accurate.
If that's all you want, Anarki already has it. ^_^
I'm interested in finding a documentation solution that scales up to programming-in-the-large, without being the cumbersome kind of thing that people would have trouble using even if they wanted to.
In particular, I like the Racket approach of having both an API reference, where people look up the meanings of particular functions, and a user guide, where people learn the design of the system and develop a better idea of which functions they should actually be looking for.
In-source docstrings (or Javadoc comments and the like) should be an okay way to get good coverage in the API reference, but they're kinda independent of each other and hard to automatically organize, especially in a language without modules or classes. They're not even close to being good pieces for walkthrough-like user guides.
Literate programming, meanwhile, encourages code to be arranged as though it's a user guide. (This may be just one style of literate programming; I imagine people who care about literate programming mainly just care about good documentation.) The Inform 7 docs are an awesome example of this:
However, there are usually at least some parts of the code that are left as an exercise for the reader to understand. :-p This approach also straddles the line between guide and reference without necessarily being the best at either. There's kind of a cross-cutting concern going on, the more roles you try to give to a single codebase, and it kinda drives me in the reverse of literate programming: I almost suspect it would be most ideal just to put nothing but implementation notes in the code comments, and to have code be simple enough to stand on its own (like the current state of Arc).
This ties back in with another, more important part of the Racket discussion: The version of the program you have shouldn't determine the version of the docs you have. In fact, the docs oughta be a living document that immediately collects improvements and discussions, oftentimes faster than the codebase changes. They should be some form of wiki or help forum.
I'll go farther than that: Keeping comments in the code is a brittle system because they'll become inconsistent with the real docs. Instead, people should browse the code on a website that automatically lets them see the most recent versions of the wiki content. There'd essentially be a CMS that manages:
- The code itself.
- Snippet-local API docs.
- Comprehensive, listing-like API references.
- User guides.
- Examples of various sizes (like aw's "pastebin for examples" idea).
- Tutorials.
- Bug tracking entries.
- Freeform discussions on all these things.
This is bigger than I expect to design all by myself, for sure. :-p
I definitely agree with you that there is a difference between api reference and user guides. Languages do need both.
You bring up a excellent point that documents should be living documents and can evolve faster than the version of the code. With a community this small I think it's easiest to bundle the two together since anyone can contribute to anarki.
Maybe Anarki contributor should designate a collaborative location that can serve as the official site for documentation for atleast user guides, tutorials and faq's.
For discussions I think we would all agree that arclanguage.com is the best place.
"With a community this small I think it's easiest to bundle the two together since anyone can contribute to anarki."
I like that in concept. We could just have a GitHub Pages branch on Anarki, and GitHub would automatically let us view it as a web page. However, aw mentioned having trouble with GitHub Pages: http://arclanguage.org/item?id=12934
Someone could rig up a website to serve GitHub raw file views as HTML, but I don't know if that's nice to GitHub. :)
Someone could instead have a website that somehow keeps an up-to-date clone of Anarki (perhaps triggering a "git pull" not only as a cron job but also every time a certain page was viewed) and somehow uses that to determine the website content.
One thing to consider is security: If anyone can show their own JS code on this page, they could set tracking cookies or something. If anyone can run Arc code on the server, there's even more to worry about (albeit nothing the racket/sandbox module isn't designed for).
---
"Maybe Anarki contributor should designate a collaborative location that can serve as the official site for documentation for atleast user guides, tutorials and faq's."
However, having a separate place for documentation is only one part of what I'm suggesting. I'm not sure it's worth it unless the separate parts are somehow integrated again--for instance, by showing docs and discussions as you browse code, or by letting user guide writers say {{doc:anarki:lib/util.arc:afnwith}} or somesuch to include a piece of the API reference.
---
"For discussions I think we would all agree that arclanguage.com is the best place."
Speaking of which, are arclanguage.com and arclanguage.org both legitimate? Both of their WHOIS entries list Paul Graham, but I don't know whether that means anything. I've never logged in anywhere but arclanguage.org, just because it's what most people link to.
Anyway, we totally do use the Arc Forum for discussions now, but I think things would be better if we could incorporate ideas like the ones from this thread: http://arclanguage.org/item?id=12920
I imagine that my complaints about GitHub Pages at the time were probably just growing pains on GitHub's part.
However exactly for the reason of implementing our own features at some point such as the cross references you mention I expect that we're going to want to do our own processing. Which suggests that GitHub Pages or the arclanguagewiki on Google Sites might be part of the right long term solution, but only if there's a way to e.g. insert the piece of an API reference... which we're generating.
Here's a thought. What if we had a server which went out and gathered documentation source material from various places such as Anarki. (GitHub has http://help.github.com/post-receive-hooks/ so the server could get notified of new pushes to Anarki instead of having to poll).
The server would work on the text of the sources, such as docstrings found in the Anarki source code. That way even if someone pushed something malicious to Anarki then we wouldn't have a security problem (either on the server or in the reader's browser). The server would process the documentation source material and generate static HTML files... which could be hosted on S3 or GitHub Pages. This would have an additional advantage that even if the server were down, the documentation itself would still be up and available.
"The server would work on the text of the sources, such as docstrings found in the Anarki source code."
With this approach, people might be pushing to Anarki way more, sometimes using in-browser file edits on GitHub, and the server would have to scrape more and more things each time. Then again, that would be a good problem to have. :-p
---
"That way even if someone pushed something malicious to Anarki then we wouldn't have a security problem (either on the server or in the reader's browser)."
By the same token, it would be harder for just anyone to update the server, right? Eh, that might be a necessity for security anyway.
Potentially, parts of the server could run Arc code in a sandbox, incorporating the Arc code's results into the output with the help of some format that's known to have no untrusted JavaScript, like an s-expression equivalent of BBCode or something.
Well, code that generates page contents.... Suppose I want to put "prev" and "next" links on several pages, or suppose I want an API reference to automatically loop through and include all the docstrings from a file. Lots of this could be up to the server to do, but I'd like for the documentation itself to have some power along these lines. For instance, someone might write a DSL in Arc and want to set up a whole subsite covering the DSL's own API.
Besides that, it would just be nifty to have the Arc documentation improve as people improved the Arc libraries and vice versa.
Suppose I want to put "prev" and "next" links on several pages, or suppose I want an API reference to automatically loop through and include all the docstrings from a file.
I'd just have the server code do that.
For instance, someone might write a DSL in Arc and want to set up a whole subsite covering the DSL's own API.
Sorry, not following you here. How would this be different?
Besides that, it would just be nifty to have the Arc documentation improve as people improved the Arc libraries and vice versa.
Certainly. Naturally the server code can be written in Arc itself.
Say this DSL is a stack language written in Arc, called Starc, and Starc programs are implemented by lists of symbols. I've set up a global table to map from symbols to their meanings, and I have a 'defstarc macro that submits to that table and supports docstrings.
Now I want my language to have documentation support that's seamless with Arc's own documentation. Somehow I need my Starc documentation to be split across multiple pages, with some pages created using the 'defstarc docstrings. I want Starc identifiers to be displayed in a different style than Arc identifiers, but if anything, I want it easier for a Starc programmer to refer to Starc identifiers in the documentation than to Arc identifiers.
So every time I come up with one of these requirements for the documentation, I should submit a patch to the server or something? Fair enough--the code implementing the documentation oughta be documented somewhere too, and keeping it close to the project also makes it more ad hoc and inconsistent--but I think this would present a bit of an obstacle to working on the documentation. I'd rather there be a compromise, where truly ad hoc and experimental things were doable in independent projects and the most useful documentation systems moved to the server code gradually.
This would be more complicated to design, and it could probably be incorporated into a more authoritarian design after it's underway, so no worries.
- you run a copy of the server code you're working on locally, until you see that your "Stark" documentation is being integrated into the rest of the documentation in the way that you want it to
- you push your changes to the server (say, via github for example) and they go live
OK, but what if you're a completely random person, you've never posted anything to arclanguage.org, no one knows who you are, and you want write access to the server so that you "can do stuff". Alright, fork the repo on github, push your changes there, and send a pull request. Then when you turn out to be someone who isn't trying to install malicious Javascript you are given write access to the server repo yourself. (This is pretty standard approach in open source projects, by the way).
But... what if write access to the server repo ends up being controlled by an evil cabal of conservatives who reject having any of this "Starc" stuff added? Fire up your own server, publish the documentation pages yourself, and people will start using your documentation pages because they are more complete than the old stuff.
My concern with the sandbox idea is that I imagine it's going to be hard to create a sandbox that is both A) powerful enough to be actually useful, and B) sufficiently constrained so that there's no possible way for someone to manage to generate arbitrary Javascript.
I'm finding this discussion very helpful, by the way. What I'm spending my time on now is the "pastebin for examples" site. I've been wondering if this project would stay focused on just the examples part (with the ability for other documentation sites to embed examples from the pastebin site) or if it would expand to be a site for complete documentation itself (the "code site for Arc" idea).
For the pastebin site I've thrown away several designs that weren't working and I've found one that so far does look like it's going to work. But, the catch is that by design it allows the site to execute arbitrary code in the target machine that's running the example. This isn't too terrible by itself (you can always run the example in a virtual machine or on an Amazon EC2 instance etc. instead of on your own personal computer if you want), but it does mean that the "pastebin for examples" site is going to need a higher level of security than an Arc documentation site.
Which in turn implies that while the Arc documentation site can use examples from the pastebin site (if people find it useful), the pastebin site itself shouldn't be expanding to take on the role of the Arc documentation site (since the Arc documentation site can and should allow for a much freer range of contributions).
"But... what if write access to the server repo ends up being controlled by an evil cabal of conservatives who reject having any of this "Starc" stuff added?"
The main thing I'm afraid of is the documentation site becoming stagnant. Too often, someone finds the arclanguage.org website and asks "How do I get version 372 of MzScheme?" Too often, someone who's been reading arcfn.com/doc the whole time finally looks at the Arc source and starts a forum thread to say "Look at all these unappreciated functions!" ^_^
I don't blame pg or kens; I blame the fact that they don't have all the time in the world to do everything they want. I'm in the same position, and I bet it's pretty universal.
---
"Fire up your own server, publish the documentation pages yourself, and people will start using your documentation pages because they are more complete than the old stuff."
That could be sufficient. But then while I'm pretty active on this forum, I'm not sure I have the energy to spare on keeping a server up. If the community ends up having only people as "let someone else own it" stingy as me, we'll be in trouble. >.>;
---
"My concern with the sandbox idea is that I imagine it's going to be hard to create a sandbox that is both A) powerful enough to be actually useful, and B) sufficiently constrained so that there's no possible way for someone to manage to generate arbitrary Javascript."
All I'm thinking of is some hooks where Arc code can take as input an object capable of querying the scrape results and give as output a BBCode-esque representation that's fully verified and escaped before use. But then I don't know if that would be sophisticated enough for multi-page layouts or custom styles or whatnot either. ^^;
There could also be another Arc hook that helped specify what to scrape in the first place... but in a limited way so that it couldn't do denial-of-service attacks and stuff. ^^; lol
Partly it's just a curiosity for me. I like the thought of letting Arc code be run in a sandbox for some purpose, even if it's only marginally useful. :-p
---
Meanwhile, I had another thought: Even if the server doesn't allow running arbitrary code, people could still develop special-purpose things for it by running their own static site generators and putting up the output somewhere where the server will crawl. I wonder how this could affect the server design.
But then while I'm pretty active on this forum, I'm not sure I have the energy to spare on keeping a server up.
I'd be happy to run the server, and set up some kind of simple continuous deployment system so that when someone makes a code push to the server repo the code goes live.
Depending on availability and motivation I may (or may not...) end up having time myself to get Ken's documentation into a form where it can be edited (he generously offered last year to let us do this).
A part that I don't have motivation to do myself is writing the code that would crawl Anarki and generate documentation from the docstrings.
I like the thought of letting Arc code be run in a sandbox for some purpose, even if it's only marginally useful.
I certainly won't prevent someone from adding a sandbox to the server. On the other hand... if you'd like to work on something where a sandbox would be useful ^_^, I'd encourage you join me in my API project :-)
"The main thing I'm afraid of is the documentation site becoming stagnant. Too often, someone finds the arclanguage.org website and asks "How do I get version 372 of MzScheme?" Too often, someone who's been reading arcfn.com/doc the whole time finally looks at the Arc source and starts a forum thread to say "Look at all these unappreciated functions!" ^_^
I don't blame pg or kens; I blame the fact that they don't have all the time in the world to do everything they want. I'm in the same position, and I bet it's pretty universal."
I think if contributing is open and flexible people will contribute to keep the site up todate. Complete and simple instructions must exist to help and encourage people to contribute. Some is social where people feel they need "permission" to contribute.
The interesting thing I am seeing among the experimentation and projects people are doing here is the fragmentation. I think experimentation with languages are great and very necessary but it's difficult to see there isn't a main champion for the community to rally behind.
PS stupid question how are you italicizing quoted text. I tried adding <i>some text</i> but that didn't work. I haven't had enough time to play with the comments to figure that out.
"The server would work on the text of the sources, such as docstrings found in the Anarki source code. That way even if someone pushed something malicious to Anarki then we wouldn't have a security problem (either on the server or in the reader's browser)."
If it ever got to the point where actually eval'ing the code were necessary/desirable, you could do so in a safe namespace in PyArc (hint hint).
Arc already supports docstrings, and has a built in function 'help that displays them, along with the signature of the function and the filename in which the function was defined. The help information can also be accessed from an op when the arc server is running, but I'm not sure how much of that functionality is Anarki specific. There is also 'sig that displays the signature of a given function, 'fns that searches for a given function name in the list of presently defined functions, and on Anarki there's also 'src that prints out the source of a given function or macro. Unfortunately, Anarki's ppr is currently broken because len no longer works for improper lists.
I've been interested for a long time in runtime accessible automatic documentation, and 'src and 'help go a long way towards providing that. One of the few things I think we still need in that regard for runtime documentation is a means of searching for fns by category, and that will probably involve either adding tags to the docstring, or searching the code for a given pattern. Having the source of a function stored in a table at runtime is incredibly useful, and could allow you to search for all functions that call a given function or macro, or that use a particular idiom.
>This makes `(single stack)` read nicely, but we already know stack is a linked list, so we could also just say
(~cdr stack) ; == (no:cdr stack) == (no (cdr stack))
I wouldn't want to go to this optimization until finding out that it would significantly increase performance, but that argument hinges on thinking it's slightly less readable than `(single stack)`.
Either of these are neater than using `and`, which for clarity is better only used as a predicate, in my opinion.
Thanks fallintothis, zck, and shader for your improvements. I'm trying to take everyone's suggestions into account to make a new version, which I'll put in Anarki when I'm satisfied with it.
Interesting, and not entirely wanted, I think. Is there a way to prompt for a new character? I don't see a way to clear out a port; peekc waits for a character to peek at; readall waits until you type nil.
Scheme's 'char-ready? is probably close to what you're looking for. It returns #f if the runtime can guarantee that the stream would have blocked if it were read from at that time, and otherwise it returns #t.
; This exploits an Arc 3.1 bug to drop to Racket (as seen at
; http://arclanguage.org/item?id=11838). It's unnecessary on Anarki.
(mac $ (racket-expr)
`(cdr `(nil . ,,racket-expr)))
(def discard-input ((o str (stdin)))
" Reads all the characters from the stream, giving up partway if it
can determine the stream would block. The return value is `nil'. "
(while:and $.char-ready?.str readc.str))
arc>
(do (pr "enter something> ")
(discard-input)
(prn "The first character was " (tostring:write:readc) ".")
(discard-input))
enter something> something
The first character was #\s.
nil
arc>
