> Having all parameters be keyword arguments as well might be interesting, but it wouldn't avoid optional/keyword confusion.
Why not?
Let's say you have a function with 3 standard args followed by 2 opt args. So you have 5 args, all keyable on the symbol you give them in the def.
Let's further say that in a call to this function, I key the middle standard arg (#2 in the def) plus the first opt arg (#4 in the def) and also, I omit the second opt arg (#5 in the def). So, I'm supplying two standard args apart from the two args I'm keying. Then the function call parser would know, after identifying the 2 keyed args and matching them to positions #2 and #4 in the def, that the first non-key arg supplied corresponds to position #1 in the def, the second non-key arg supplied corresponds to position #3 in the def, and that an arg for position #5 in the def is missing, leading to the usage of the default value for this opt arg.
This would even work when you want to raise an error for a non-supplied, non-opt arg.
Wouldn't this work quite intuitively (keying an arg when calling a function "lifts it out" of the normal "vanillas then optionals" argument sequence, shortening that sequence, put keeping a well-defined order for it)? (You would need special syntax for keys in this proposal. My suggestion is a colon appended to the arg symbol, rather than prepended, like in CL.)
Can someone give a counterexample if they think this somehow wouldn't work?
&rest args are left as an exercise for the reader :-)
I am curious about the people who claim to use Arc as their primary language. Do they not have jobs or classes that force them to use other programming languages?
Well, pg is probably one of them... and some folks likely really are in a position to use whatever language they like.
My day job is avionics software verification, so I don't program much for my job, per se, but what programming I do, I could likely do in Arc, and no one would care, as it's just for internal use.
I didn't vote up for Arc, but I actually used it at work most of the time for the last month. For what I'm working on, I am free to use whatever I want and Arc really rocks !
Yeah, same here. And what really scares me is that no one can see past the prison of Java, not even the professors.
I am trying to convert some of my friends over to the Lisp Way. Making a little progress, but most of my friends don't think they have time to learn Lisp on top of their other classes.
I have heard that even universities are held hostage by students who view college as merely job training, demanding courses in the languages business cannot see past.
Seems to me the unis should fight that fight, but there are a lot of unis in the US, they have to think about marketing, too.
Perhaps as the IT job market continues to shrink the masses will move on to something else and let the computer science departments go back to teaching algorithms.
I haven't met many students that are set on learning Java and only Java (or insert other popular language of choice), mostly its just that they don't know anything better is out there. I have, however, met professors who hold very strong, and wildly incorrect views on Lisp (many of which probably haven't been accurate for 20 years or more). But how is a college freshman supposed to tell a guy with a PhD he is completely incorrect?
I've heard claims that they'll let me program in whatever language I want in upper division, but I have to wonder if that is true or not.
IIRC, Brown has two introductory computer science tracks -- one that starts with Scheme and the other with Java, with the Scheme course recommended for majors. They've got one of the PLT Scheme implementors on faculty, too, so some of the advanced courses are Scheme-based, as well.
The error seems to be in ac-qq1, line 209, which uses map to look at nested structures in a quasiquote.
((pair? x)
(map (lambda (x) (ac-qq1 level x env)) x))
And apparently scheme's map can't handle dotted lists.
Unfortunately I don't scheme well enough to know if another primitive does what we want... Otherwise we'll have to write a new version of map for use by quasiquote. (Or rewrite quasiquote to not use map at all, but that might be more work.)
I could do this but happen to be a little busy right now. (I wouldn't mind if someone were to beat me to it.)
I normally use "{{{" and "<<<<" as delimiteres in a plaintext . But obviously it doesn't work very well here, so I'll keep in mind to use indentation instead.
It's supposed to be a predicate for a non-nil atom. I just realize that could better be written as (~acons current) instead, given that (acons nil) is also nil.
I was confused because (~no current) is just the same as current by itself, and I didn't realize you wanted to test for non-nil atoms. Obviously (~no current) isn't what you want, because it returns true for lists.
arc> (~no nil)
nil
arc> (~no 'a)
t
arc> (~no '(1 2 3))
t
But I don't think (~acons current) does what you want either. Because (acons nil) is nil, (~acons nil) is true.
arc> (~acons nil)
t
arc> (~acons 'a)
t
arc> (~acons '(1 2 3))
nil
I think (~alist current) returns true for non-nil atoms, because (alist nil) is true.
For some reason, auto-indentation doesn't work for me. And also, I can't use the REPL unless I start emacs in the directory where arc is. Any advice would be appreciated.
Perhaps you could give example pieces of a .emacs files?
(autoload 'run-arc "inferior-arc" "Run an inferior Arc process, input and output via buffer *arc*." t)
(autoload 'arc-mode "arc" "Major mode for editing Arc." t)
(add-to-list 'auto-mode-alist '("\\.arc$" . arc-mode))
I also have arc.el and inferior-arc.el in my loadpath.
As for starting the REPL, inferior-arc.el assumes that there's an "arc" program in your path. I did this by adding a symlink pointing to my arc.sh, but you could also customize the arc-program-name variable.
And I'm on Windows so I can't use arc.sh :( ... I tried to make up for it by using arc-exe instead, but arc-exe won't load if it isn't in the same directory as ac.scm. (I think this is because the require-namespace isn't done at compile time like normal requires are.)
You should be able to set up a simple CMD script to start Arc on Windows. I think. I don't actually know that much about Windows. At the very least, you can set arc-program-name to be a manual invocation of MzScheme.
Oh, thats what you mean by auto-indenting. I was expecting it to act like lisp mode where it indents when I press enter (which would be nice to have if someone could manage it).
My problem so far is that when I try to load arc, because the current working directory is not the arc directory, even if it loads as.scm correctly, it can't load ac.scm or any *.arc files. I could set it up to load something like "mzscheme -mf C:\...\arc\as.scm" but I don't know how to make mzscheme look for other arc files in that directory as well.
The standard Emacs indentation behavior is to indent on TAB rather than newline. This is also the default for Lisp-mode, as far as I know. You can rebind this by setting RET to comment-indent-new-line, though.
You need to add some argument to mzscheme to get it to cd into the arc directory. Check the args passed in arc.sh.
Ok, thanks. I hacked a batch file and put it in my PATH so I can start arc from emacs. (Setting arc-program-name failed because run-arc wouldn't respect the quotes around the executable name.)
It does work, but don't do that :) At least if you're generating, for example, very big lists : everything evaluated in your program will be displayed. If your code contains something like (= foo (range 1 1000000)), you'll somewhat regret it...
But, in many cases, that will work just fine, despite the noise generated by the repl. You can also do mzscheme -m -f as.scm < myprogram.arc >/dev/null to turn the whole output off (in case you don't need it at all).
It seems that you can vote for multiple items in polls. I don't know if this is a bug or a feature... it just seemed somewhat odd. (Maybe the poller should be allowed to choose whether users can vote for multiple items or not.)
