There's a high risk I don't know enough to make an intelligent request, especially I have never heard of Racket or why Racket libraries would work over Python or Java libraries.
Would love to use Arc on Android, just cause thats what I currently need to do...
To me, a Scala-like JVM compatibility would be great, and being able to call java libraries...
Maybe the libraries aren't really possible without cludging up everything...
Mutable strings are indeed sort of "strange", especially given Lisp semantic for literals that is different for example from Python (in python the syntax "[1,2,3]" is a list literal, but is indeed equivalent to Lisp "(list 1 2 3)" and not to "'(1 2 3)", i.e. returns a new fresh list at each evaluation). Mutable literals is somewhat counterintuitive and in Python a similar problem happens with default values for parameters (i.e. "def foo(x=[1,2,3]):...") not because the literal is altered but because default value is evaluated only once at function definition time. This idea that what is in the program text is not in this case fixed is a trap in which newbies often fall...
"No. If someone else wants to travel to the other side of the world and I want to visit my local coffee shop, it's not politics for them to work on buying plane tickets and for me to work on buying a bicycle."
By reliable implementation I mean something that you would bet your project on. When you choose to use it in production software you have certain expectations from it (stability, performance, etc.)
If the reason to start arc was "a different goal of the scheme community", well, then I guess it's all about politics...
I agree that there is a different philosphy in arc, and also that there are a lot of small treats that make life easy and programming fun, that you (and I) whish you had in the language you are working in. But still, why a new lisp and not get involved in the evolution of scheme. I will take ages until we have a decent, reliable implementation of arc. Until then it will stay in the lab and people will experiment with it, and do little more. And then there are the libraries, which also have to be written or ported.
Conrad Barski has a very nice description of lisp and scheme in his book "Land of Lisp". He depicts lisp as a language where you have raw power, but is a bit ugly because of "pragmatic compromises", and scheme as clean, elegant but less practical because "schemers care more about mathematical purity of their code".
A successfull combination of those two is also what I would like, and arc may very well be that, but just I wonder: why starting to work on a new species instead of trying to evolve an existing one.
I think in R7RS there will also be a split in scheme, and we will have two schemes: a small and pure one, and a larger and practical one.
This project starts with the purpose of making an S-expression language which can be easily embedded into another project.
Since I really like arc's sugar-syntax, I would like to implement all language specification which arc has, and make it extensible and easy to embed.for above reasons, I would rather do not take any kernel-level threading techniques, but with some user mode thread and in-background dispatcher to support async socket io. Currently, it have tail recursion optimization, continuation, macro and a mark&sweep garbage collector.
Overall, you're right, it's primarily a project of learning how to make a language.
It's right since the header files are all created in Xcode 4 with the default template. I will make it under an open source license after reading both licenses. Thank you for the advices!
I'm not sure about this idea. I think I would need to actually play around with it for a while before I could know whether it was a net gain or not.
I do like #3 though, with unbound symbols evaluating to themselves. One problem: wouldn't that mean that now you must use "bound" if you want to know if a symbol is defined or not? How frequently do you want to do that?
Actually, I like that Arc overloads so many things. I suspect the primary reason I dislike using . for functions is because of my JavaScript background. After years of programming in JavaScript, it's become very ingrained into me that . means "property access"
I agree that for my code it's a simple matter of not using the syntax in the areas that I don't like it. In fact, I don't need to use any syntax at all: I could use pure S-expressions if I wanted.
I guess what it comes down to is, "I want to use . for property access in tables, or at least use something that's not !" and although it looks weird to me to use . for function calls, I'll concede that Arc is not JavaScript, so I think I can tolerate it.
Thus, combining . and ! might be the best way. Alternatively, I think these would be very nice as well:
While I was reading your post again, I realized that "," would also work, though I'm not sure we want to use such a nice character, or save it for something else. I also like the a'b syntax, so there's definitely plenty of options to consider. It's more a matter of deciding whether things should change, and if so, in what way.
P.S. to directly answer your question, yes I think that would be clearer, though more verbose. It's a bit hard for me to pick out the individual elements, because they're all squished together due to the infix syntax.
My current view of the various styles:
(foo rep/x.field-name) ; good
(foo rep|x.field-name) ; undecided; looks pretty weird
(foo rep'x.field-name) ; tied for favorite
(foo rep,x.field-name) ; tied for favorite
(foo rep.x.field-name) ; okay, but too hard to see the "."s
(foo rep.x!field-name) ; don't like the !
(foo (rep x).field-name) ; doesn't look lispy enough
(foo (rep.x 'field-name)) ; good: very lispy, but not too verbose
(foo ((rep x) 'field-name)) ; too verbose
I actually really like the foo,bar syntax for (foo bar). Especially when considering that the only difference between . and ! is that ! quotes the symbol, so it makes sense that the two would look very similar, right? Also consider this:
I think it depends on the semantics of the situation. I don't like seeing things like "car.a" or "car.cdr.car.a" because I know that car and cdr are functions, so it kinda screws with my brain.
I feel like function calls should look like function calls, but when adding syntax, they should look different from non-function calls. According to that rule:
(= foo (list 1 2 3))
foo.2 ; good
car.foo ; bad
(= foo (obj x 1 y 2))
foo.x ; good
keys.foo ; bad
(= foo "bar")
foo.0 ; good
downcase.foo ; bad
In other words, I'm okay with the . syntax when the first argument is a non-function. But I don't like seeing/using the . syntax when the first argument is a function.
For instance, the : syntax is used for functions only. I think the . syntax should be used for non-functions only. It just helps me to cognitively understand a program with the least amount of effort, but others may disagree.
I agree that Arc shouldn't especially try to be like other languages, but since the distinction between . and ! is mostly arbitrary, choosing a syntax that is more appealing to people coming from other languages is a nice bonus. Especially given that JavaScript is quite popular (for better or worse) and has some nice functional aspects to it (closures, lambdas, etc.) which make it conceptually similar to Scheme, even if the syntax is very different.
Note: if it were possible to combine the two without causing big problems (see evanrmurphy's post), then I might be okay with using the same syntax for both forms.
Note: I was referring to swapping the semantics of . and !
I don't care as much whether it's ! or / or | or whatever, but I feel like . is more natural for property accesses (keep in mind I'm coming from a JavaScript background, so I'm very used to using . in that way)
I really like the idea of combining the two. It seems like there's such a small distinction between them that they really serve a similar purpose. This would also solve all the problems with discussions about alternate syntaxes, since there would be a single syntax for both.
Crazy idea, having symbols bound to themselves by default. I wonder if that would cause any problems, though... sounds like an interesting idea to experiment with.
That sounds okay, but I'm not convinced we should even have a syntax for (x y). When reading other people's code that uses that syntax, I felt like it would be clearer and easier to read if they had used normal parentheses.
I do think that ":" and "!" are big wins, though (even more so if "!" is changed to ".")
The arc.sh script worked great for going straight to a REPL and running a script, but can it simply load a set of definitions and then enter a REPL? If I ran "arc.sh arc.arc" I get a bunch of "redefining..." then it dumps me back to the shell. I didn't see an option in the script itself. If it's not possible, no biggie, I can just call arc then (load script), it's nice to save some keystrokes.
1) afn is somewhat of an anomaly. When I see "fn" I know "this is a function" but when I see "afn" I have to pause for a split second to realize what it does.
2) Pattern recognition due to redundancy. When I glance at the first version, my eyes quickly notice that there are 3 references to "rec", and thus I immediately form a pattern in my mind. But in the second version, there are two references to the same function: self and rec. This adds an additional cognitive overhead for me.
In other words, the first one appears less cluttered to me because it has fewer unique elements, and because "fn" is more familiar to me than "afn".
It's not a huge deal, but I would like to reduce the cognitive overhead of reading and writing code as much as I can, which is one of the things I really like about Arc: it's clean, simple, and short, but allow tons of flexibility to change the language to suit the way you think.
Yes, that's what I'm saying. I understand now that sometimes it is useful to pull in a variable from an outer scope, but sometimes you want the behavior of letrec. I'm pretty sure letrec would be trivial to write as a macro, so this discussion is more about which should be the default. Do people usually want the outer scope, or the inner?
P.S. I whipped up a quick version of letr; it seems to work okay:
P.P.S. Adding more syntax would also solve it, but I actually would prefer to give them two different names. It just seems cleaner and less cluttered to me.
The function might have some internal state, like variables or helper functions. I don't want those to clutter up the namespace, nor do I want them to be mucked up by other code.
I think so. The Arc source for "rfn" just uses "let" to initialize the variable to nil, then assigns a function to the variable. I'll try and see if I can come up with a simple definition of "let" that works like letrec. I think it would be great if Arc could have a simple unified "let", rather than multiple similar-but-slightly-different forms.
About the corrolaries. Sorry, I meant to acknowledge the possibility of multiple, non-unifiable languages at the "top tier", but not focus on it. On second reading, I seem to have left the notion out altogether. Which was unintentional; Seibel explicitly makes your point about local maxima, and I didn't intend for it to seem like unification was the only possibility. I just happened to be interested in thinking about it because it's not the the first time I heard the idea of "Lisp + Haskell would rule the world".
>I may not want to have to think about the world as containing keyword arguments, either. They make the function a more complicated concept, so that it takes more edge-case consideration (and code) to get everything working intuitively.
This is a quibble, and the one point I potentially disagree with. If you're speaking as the language implementer, fair enough, I could see how it would be harder to provide optional/keyword/default/rest/body args, but how does having this option hurt you as a language user? I'm wondering because my experience with this particular feature has been that it's very useful in some cases, but doesn't get in the way at all otherwise (which is why I'd consider it a net win if it could somehow be made to co-exist with auto-currying).
First of all, thank you very much for your reply :)!
I have never touched Arc and news.arc, so maybe I shouldn't even try to incorporate the news.arc code into another language.
I have never received an advice like "Learning how Ruby developers think.", but I believe it is one of the best advice I have received (especially for a newbie like myself.)
Maybe I am trying do to everything when I should be focusing on one thing and learning slowly but surely.
