Just FYI, 'infix is not a keyword. (Arc doesn't really have keywords in the same way as other languages, the closest it has are words like 'quote, 'fn, and 'if, which need to be dealt with explicitly in the compiler. Things like 'def and '= which look like keywords in other languages are actually macros, allowing them to be (re)defined by the user inside of arc.)
Also note that there is an infix syntax (besides the custom DSL solution mentioned above), which would probably do what you want. (See http://arclanguage.org/item?id=2610.) You can
Note that using infix.arc, you don't even need an 'infix keyword around infix math. (This works as long as the object in functional position is a number.) Also note that the syntax of function calls is still exactly the same, it is just infix notation that is implemented.
Because infix notation doesn't interfere with the rest of the language, it actually used to be loaded by default on Anarki, but it was removed because it incurs a fairly hefty runtime overhead, even when using normal (prefix) math.
After entering (asv), I don't have an arc prompt, and to get the prompt I have to quit (asv), which means that loading the '/hello' page gives an error. Can I get the arc prompt while (asv) is running?
In order to get to the arc prompt, you'll need to run the application server (asv) in a separate thread, you can do so with the following code:
(= app (thread (asv)))
and, you can stop the server with the this code:
(break-thread app)
Once Arc's app server is running in a separate thread you'll have full access to the Arc repl and you'll then be able to modify your application on the fly.
Taking inspiration from discreet math, we could use ∧ and ∨ as andf and orf, respectively. This would be in line with pg's current use of ~ as not. On the other hand, maybe we shouldn't make use of non-ascii characters... (or else you get APL et al)
I would say use ^ and v, but something tells me that disallowing a v in identifiers would be a bad idea (e.g.eval) ;)
My biggest problem with using Unicode is that it's often a pain to type. The Mac gets this the most right of any platform I know, but even so, it's (a) not a standard, and (b) mostly alphabetic. Which is a pity, really, since those do make the most sense.
> My biggest problem with using Unicode is that it's often a pain to type.
Agreed. We might be able to add a hook to arc-mode in emacs to make it more convenient, but reminds me even more of APL (which if I recall correctly required a custom keyboard to type).
> + might not be bad, but it's probably a little too common
I like +. While + does get used in symbols occasionally (most notably in arithmetic), I can't think of any cases where it gets used in the middle of a symbol.
EDIT: On second thought, when I use plus outside of a programming context, I usually mean and, so it might be confusing to use + as 'andf.
The problem with "adding a hook to arc-mode in emacs" is that then you alienate everyone not using Emacs. And that's a good point about + being used to mean &.
"maybe we shouldn't make use of non-ascii characters" : why not ? Characters like λ have their place in a Lisp, and I think ∧and ∨ have their place too. Anyway, such characters wouldn't be used very frequently (do you often use andf & orf ?) and could be ignored if typing them is too painful. That's better than consuming ASCII characters that sometimes fit well in symbol names, IMO.
I think it would be hilariously ironic to make non-ASCII Unicode characters part of Arc's syntax and functions.
A few proposals for giving functions new names: ☢ for atomic, ✄ for cut, ✔ for check, ⌚ for time, ⌛ for sleep, ☠ for kill-thread, ☇ for zap, ♭for flat.
But anyway, I still think they're not worth loosing an ASCII character, and using mathematical notation would be very useful. It would make code readable by people a little aware of mathematics. That is, most programers. It would be definitely better than arbitrary characters.
Why should we restrict to ASCII anyway ? I mean, a lot of symbols I use are not ASCII anymore (they are accentuated, I'm French so something like 'year is translated into 'année, not into 'annee). Sure, they're hard to type, but are they any longer than they symbol counterpart ? If you type them often, just make them a vi macro (or whatever in your favorite text editor) and you're done.
It might end up looking like APL, for sure, but I think Fortress, Sun's new language designed by Guy Steele, is going that way too. And Steele cannot be wrong :)
I don't mind non-ASCII, I mind weird non-ASCII. Even in English, we leave ASCII behind: “As I was going to the café—what fun—my naïve friend said…” It's just that I don't know of any keyboard layout that supports ∧ or ∨. I agree that they would look great, as would Fortress.
I wonder if anyone's given any though to using (La)TeX in a language? So that something like (number{\wedge}acons var) would be the same as (number∨acons var)? Or just as a nice way of typing things like Fortress? (Which I agree looks very interesting.)
I'd probably use them a lot more often if the syntax was a little easier, which is why I suggested using ssyntax for them. Currently the syntax is ((orf this that the-other) foo), and doubled starting parens feel rather strange to me.
Something like ->foo would be nice. Even if it didn't have that exact syntax, I use 'coerce enough that it would make a (noticeable albeit small) difference in my code. And I think it is more readable than looking at lots of nested type checks.
Are different ssyntaxes be combinable? Could you, for example,
(if (int?//num? n)
; its a number...
; not a number...
Do these ssyntaxes currently get optimized away at compile time (i.e. like 'compose does)? Or do they incur a run-time penalty of some sort?
With proper ordering of the ssyntaxes in 'def-all-ss, yes.
> Do these ssyntaxes currently get optimized away at compile time (i.e. like 'compose does)? Or do they incur a run-time penalty of some sort?
Not yet. The run time penalty should be as small as a function-composition overhead. The optimization away of 'compose is done by the Scheme-side 'ac, so if optimizations for 'orf and 'andf and similar are desired, munging them in the scheme-side is necessary.
Edit: As an aside, the above ssyntaxes are not yet implemented in the ssyntaxes.arc file. For the most popular ones - postfix ?, as well as 'andf && and 'orf //, you can modify:
Unfortunately I don't have any huge insights. I've been using it on and off since 2005. It was recommended by a friend who lives in emacs. It makes lisp approachable and it makes me way way more efficient when writing and debugging lisp. No swank backend (and thus no slime) makes arc a hard sell. For those wondering what's so great about it - slime supports every major debugging feature I've seen in Eclipse or Visual Studio.
This is what I would recommend for someone learning slime:
If you are a complete slime n00b watch the screencast over at the slime homepage. I just watched it recently and it is well done.
I think the best way to learn from there is through using it to implement a non-trivial yet small project. Make sure the project isn't too challenging, so you have a chance to learn the new environment. Anytime you think there must be an easier/better way to do this - spend time learning slime. Keep coding and you'll continue to put yourself into situations where you can use slime in new ways.
If you have specific questions or problems it is worth asking the community or searching blogs / mailing lists. The questions are either answered already or someone will give you an answer. This is much like all the lisp and smalltalk communities.
I will see if I can get an expert slime user to post some more specific information. Maybe someone else can chime in. I know I have some useful information on specific parts of slime but it wouldn't help someone that is a new user.
Actually, "the syntax of the command is incorrect" is due to Arc not using Windows style pathnames. (Also note that the -p option is not valid on Windows.)
C:\User\Programming\Arc>mkdir -p arc/logs/
The syntax of the command is incorrect.
