as a lisp noob i'm curious what specific sorts of things you could do with first-class macros. perhaps swapping out macros for a given macro call? say in one pass of a program (function) a particular macro call is expanded by macro1, and in the second pass the macro call is expanded by macro2
I'm not exactly an expert on this, but I think it would allow you to put a macro literal in functional position. Right now:
arc> and
#3(tagged mac #<procedure>)
arc> (eval (list and 1 nil 2))
Error: "Bad object in expression #3(tagged mac #<procedure>)"
So if you had theoretical first-class macros, you could do stuff like use backquote to protect a macro you use from being overridden. (This wouldn't be necessary if we had a module system, but that might require first-class macros itself.) So in the (contrived) example below, foo works fine because prs is a function, but bar fails because foo is a macro.
EDIT: Actually, function literals in functional position only works on Anarki. It might be nice to have that fix in the official version.
arc> (mac foo args `(,prs ,@args))
#3(tagged mac #<procedure>)
arc> (mac bar args `(,foo ,@(keep [isa _ 'sym] args)))
#3(tagged mac #<procedure>)
I think first-class macros might be useful in making infix math expansion occur at compile time rather than run time... but I'm not completely sure on that one.
Yes, please. First class macros and the ability to use macros and functions (rather than just their names or definitions) in functional position would be great, and macro names would not have to shadow variable names gobally anymore. In my opinion that is one of the biggest problems with Arc.
Looks like part of the mzlib standard library wasn't installed correctly. You might want to check if the file "/usr/lib/plt/collects/mzlib/port.ss" is actually there or not. If not, perhaps reinstalling might fix the problem.
Ok, I've been working, and I've copied the atomic invoke, which-os, make-directory and make-directory* , and datetbl fixes from ac.scm.
That resolves the most recent issues, but I've been looking through the code in ac.scm and arc-exe.scm and there are still major differences. For example, while looking at the change from * call* to call*, I found that arc-exe.scm never got the defcall change in the first place. So keeping arc-exe.scm compatible with ac.scm is not just an issue of changes from now on, because the two files are already somewhat divergent.
On the other hand, if we got arc-exe.scm to just load ac.scm somehow, we wouldn't have to worry about all this. Unfornately this may not be easy; I threw myself at the problem for a couple of hours and didn't really come up with anything, except for a severe dislike for scheme's module system.
I should also point out that in the definition of mkdir, the line including (null? ,parents) probably doesn't do what you want it to since t isn't true and nil isn't null in scheme:
arc> (= parents t)
t
arc> ($ (null? ,parents))
Error: "reference to undefined identifier: t"
the fix should be to use ar-false? and quote the value of parents
There are two "comments" links, one at the top of the page for all new comments, and one at the bottom of your profile page for all comments you posted.
I find the personal "comments" page very useful for finding all responses to comments I posted.
There is still seval, right? You could use seval rather than $ in the stable branch, since it won't have to be updated except for arcn releases and bug fixes, so maintenance won't be too much of a problem. And it doesn't require writing entirely new library functions to implement.
