Not sure if using an implicit variable for specifying the namespace is the right choice here... I find implicit variables most useful when there's a single value that needs to passed through multiple layers of function calls. For example, in the Arc web server, I'm only responding to a single request at a time, so I find it useful for the request to be an implicit value.
When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly.
It seems like namespaces may fall into this latter category, since I'll be working with my namespace and the other namespace, and perhaps more than one other namespace.
I could be wrong of course, and there's a good example of when passing the namespace implicitly is simpler than the alternative.
By the way, I've been calling the value holding the global variables and other attributes of a language instance a "runtime", which happens to be implemented with a Racket "namespace". 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. Thus I'd name things "new-runtime", "w/runtime" etc.
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".
"I find implicit variables most useful when there's a single value that needs to passed through multiple layers of function calls."
I'm finding a lot of uses for implicit variables. I've come to like them a lot. :P I'll note that there can only be one namespace active per executing code, so it made a lot of sense for me to use implicit variables.
---
"When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly."
Yes. And it'll be even more true when ar gets defcall. I mean, really, implementing dynamic variables, optional args/destructuring, ssyntax, objects, and namespaces/import as plain-old Arc code is impressive. Very impressive. In fact, I don't know of any other language that can do that, though I've heard Smalltalk is very flexible.
Since most of the Arc compiler is actually in the Arc namespace (combined with having access to Racket), I get the feeling that you could do almost anything with ar, which is most definitely not true of Arc/3.1.
I would personally treat a type like "table" to be an interface. So anything could be a table, as long as you could use it like a table.
Your example of something that claims to be an array but gives you trouble if you treat it like an array strikes me as more an issue with that particular bad implementation...
Interesting question though: what would treating types like interfaces look like from an Arc point of view? I'll have to think about that one :)
Update: I wrote this before I saw Pauan's comment :)
:) In that rails example scopes don't claim to be arrays. Hmm, perhaps it's just that printing them on the console is confusing. Perhaps other forms of overloading aren't so bad, and perhaps I can even handle the console with a slightly different mindset - not judging values by how they print.
As far as I know it's currently hard to use Arc code from Racket.
Ideally, you'd like to be able to put Arc inside a Racket module that you could import into your Racket program. My Arc runtime project will eventually be one way to do this, but it's still under development. I believe this would be technically feasible to do with Arc 3.1 as well, but I haven't heard of anyone implementing it yet.
What would probably be easier today is to write the Racket part of your program as a Racket module and import that into Arc, instead of going the other way around. You could have a "main" function in Racket that you'd call from Arc, passing in any functions from Arc that you needed in Racket (such as a way to hook into the web server, for example).
I thought about that but I've decided to leave arc behind, but take my favorite things about it with me. In particular, I really like the http server because it is great to do web dev on a repl-based server.
I'm not sure whether you mean by "leaving Arc behind but taking some things with you" you want to be able to write your own programs in Racket but use Arc libraries that are useful to you, or to have no Arc code running in your system at all?
If you mean you'd like to use Arc's http server from Racket, the answer is yes, you can write your programs in Racket and use Arc libraries if you want to. It's currently rather awkward, but we can help you with that if you want.
Or if you mean you don't want to be running any Arc code at all, I suppose you could translate the Arc library you want into Racket. I can't quite tell why you'd want to do that, because it would be a lot of work and you would end up with a library that did the same thing anyway as the Arc library you already can use anyway.
You also asked if there's an "automatic" way to translate Arc into Racket. The answer to that as rntz explained is yes, that's what the Arc compiler does. It takes Arc code and translates it into Racket. But that's really the same as option one.
Perhaps you're asking if there's an automatic way to translate Arc into readable Racket. No, the Arc compiler produces a giant blob of Racket code. The Arc compiler produces working Racket code, but not code that you can look at and see what it's doing (not without a lot of work, at any rate), or to be able to modify yourself at all easily. So the answer to the question "is there an automatic way to translate Arc code into Racket code readable by humans" the answer to that one is no.
Or, if using Arc libraries from your Racket program is more trouble than it's worth right now (and I imagine it could be), perhaps you'd like to implement a REPL with Racket's web server. Of course the Arc forum probably isn't the best place to ask about that, the Racket email lists would probably be more help, but I imagine it's probably possible since Racket does have eval.
"Or, if using Arc libraries from your Racket program is more trouble than it's worth right now (and I imagine it could be), perhaps you'd like to implement a REPL with Racket's web server. Of course the Arc forum probably isn't the best place to ask about that, the Racket email lists would probably be more help, but I imagine it's probably possible since Racket does have eval."
It's actually kind of an example in (the most advanced part of) the Racket getting started pages:
> Given the "many" example, it’s a small step to a web server that accepts arbitrary Racket code to execute on the server. In that case, there are many additional security issues besides limiting processor time and memory consumption. The racket/sandbox library provides support to managing all those other issues. (http://docs.racket-lang.org/more/index.html)
The racket/sandbox module reference has another example:
These examples complement each other. The first doesn't actually 'eval any client input, and the second uses a TCP socket directly rather than bothering with session handling or HTTP, but each of them picks up the other's slack. I'm a bit surprised there aren't many Racket Web REPLs for Racket the way there are for Arc.
A rationale (which people may dislike or disagree with) is that we might like to have the short, easy to type version of an operator perform the most common operation that we typically do on each type (even if it isn't logical).
If so, we'd also probably want a more specialized, longer named version of the operator that does the precise operation such as checking for object identity for all types (which we currently don't have in Arc without dropping into Racket).
Reminds me of the recursive let discussion (http://arclanguage.org/item?id=13748): when we're defining or setting a variable, and we have an expression which calculates the (new) value for the variable, which scope do we want the variables in the expression to come from?
Sometimes we'll want the variables to come from one scope and sometimes from another. But, I think you're right that a parallel = would be a useful default. It would be easy for me to write (= a x b y) as (= a x) (= b y) if I didn't want the variables to be set in parallel, but harder for me to get them to be evaluated in parallel when I wanted them to be without a facility to do it for me.
The definition is still a little 'lumpy' for my taste. But it'll smooth out with time. Besides, maybe it'll turn out to be a bad idea. No point prematurely optimizing for aesthetics.
Fascinating. This sounds perhaps similar in goals to http://awwx.ws/label0, though with a very different implementation.
Labels in implementation are just a hash table with weakly held references to the objects that being "labeled". The idea is that for example we could have "type" be a label that could be applied to an object and the type function would return that value when the label was present; and then (in a way somewhat similar to your idea) I could have my polymorphic functions decide to do something different with my value based on its labeled type, but the built-in Arc runtime functions continue to use it in the same way.
Where this breaks down of course is that labels can't be applied to objects such as numbers and characters that don't have a unique identity. Your approach of automatically unboxing boxed values means that we could box a number and give it a type when we wanted to.
What I like about labels is that we aren't limited to just one dimension for annotating an object like we are when using tag.
Of course, if the Arc runtime automatically unboxed values like you suggest then I could in fact store the labels with the objects themselves, and it would also work with numbers. This would make labels an extension of your idea, allowing a property list to be attached to the box instead of just a type value.
Oh, and by the way, for your interpreter: I suspect you're going to have an easier time of it if you make a meta-circular interpreter where (fn ...) evaluates to a function value. But that's just speculation, it might be better doing it your way :)
There was a previous discussion that if Arc documentation was in Anarki, some people might like to work on it. The documentation is now ready to be worked on, if people still want to do that.
If you'd like to work on the documentation, make changes to the template files (or rewrite the code which generates the documentation, etc., whatever you want), commit your changes to Anarki, and the resulting output will be published at http://arcdoc.eval.to/
(Currently this is a manual process for me to do the publish step so the output won't appear right away. I will most likely implement an automatic process at the point that someone does start working on the documentation in Anarki; as a) I won't need to write an automatic process if it turns out that no one does want to work on the documentation; and b) actually having to publish manually will motivate me to implement the automatic process really quick :-)
- I'm happy to publish the documentation in the subdomain of eval.to, but we don't have to; if you have a better domain all you'd need to do is add a CNAME to your DNS for us to publish under your domain.
- I didn't know how to run Anarki from the documentation directory so the "generate.sh" that I checked in uses the hackinator; to use Anarki instead to generate the documentation just fix generate.sh to use Anarki.
That's just an alias for the S3 bucket because I happened to have the eval.to domain handy, but it would be easy to put it under some other domain instead.
Some pages seem to be missing, for example I don't seem to have or have generated anaphoric.html.
Once I have things figured out I'll fix up some kind of auto deployment system; in the meantime I'll continue to republish after any commits made to anarki.
I've added some of the missing template files to github. Let me know if there is anything else missing - it's all kind of a mess of files on my end from when I tried to move to arc3.
Looking much better! The only thing I see missing now is that foundation-doc.tem wants to import docs/hdr1.txt; there's an docs/hdr1.html but not a docs/hdr1.txt.
