Unfortunately, that won't work because the form is being returned to a place outside the closure where olddef was defined; when eval is given the form containing olddef, it will not recognize it.
Please, lets not get into a "yes it is"/"no it isn't" argument here!
I am aware of some rather horrid languages that forced the use of meaningful indentation, but that doesn't make indentation evil in and of itself.
As for in Lisp, a number of people have tried to add it to Arc (including pg) without too much success. It seems that meaningful indentation lends itself much better to statement based languages than expression based ones.
I like the look of optional outer parens. It should be fairly easy to implement without too much complication with indentation.
I'm a little dubious about external symbols, though; they just don't look very Lispy to me. If these are to be integrated into the official Arc, I think we need to be sure of their worth. (The : function application operator, for example, doesn't look like it saves hardly any typing.) But if we got readmacro support in Arc, perhaps some or all of these could be implemented by users, inside Arc.
I don't particularly like the (4 * ...) because it interferes with implicit infix math (although others may not care about that as much as I do).
Piping just looks confusing to me; perhaps you could give an example of use?
The | as with looks like it could shorten code a bit, as it shortens the identifier name and removes one set of parens. But on the other hand, let could just be renamed to w/, and let could be made to not use an implicit do, in which case multiple variable assignments could be allowed. As an example of use:
(w/ a 'h b 'i
(pr a b))
I think this achieves the conciseness of the | form, and I don't think the transposition of places is very important in and of itself.
the nice thing about using multiple newlines as markers for new forms is we don't have to worry about indentation
those examples i gave for exterior symbols are just to show the sorts of things that could be possible. the 4 * notation for example would be completely out of place in Arc. (it's a notation that one of my LOGO languages uses.) the only example of those that i think is nifty is the | notation
though that piping could have some interesting uses. basically it lets you write functional statements in directed form rather than nested
(def a (x) (+ x 1))
(def b (x) (* x 2))
((a => b) 3) -> ((fn (x) (* (+ x 1) 2)) 3)
3 => + <= 2 -> 5 or [+ 5 _]
a b => + => [* _ 3] => [/ 1 _] => sqrt -> (fn (a b)
(sqrt (/ 1 (* (+ a b) 3))))
with the "implied underscore" form of [...]:
a b => + => [* 3] => [/ 1] => sqrt
sqrt <= [/ 1] <= [* 3] <= + <= a b
args within nodes:
a => [* 3] b => + -> (fn (a b)
(+ (* a 3) b))
so it's basically composition with some things to make it more general
i wonder what tomfoolery could be done by using the list as the format for the directed graph
anyways, i don't really know what i'm talking about wrt piping, and i don't find the notation very handsome. though it just occured to me that we can already just make a 'pipe' macro/function that would allow us to write things close enough to that notation. programmable programming language indubitably
and again, these are just heuristics for the most part. maybe with the small spark of these examples, other people can come up with some useful notations, or more useful sparks that may eventually lead to some :)
Oh, I didn't see your note about multiple newlines separating forms. That is an interesting approach, and removes the need for meaningful whitespace. But I have to wonder if it might get a little tiresome at the repl, since you would always have to add an extra newline to all your one line forms (unless you reverted to outer parens again).
And I now see what piping does, although I agree with you that the notation doesn't look very nice.
Perhaps external symbols could be used to do infix math? Although that might make it difficult to distinguish from when you want to do (for example):
yea for the REPL i'm not exactly sure. i think it would have to be limited to 1-liners. for multiple lines then you'd have to use outer parens. where it would get wack is, say, copy & pasting code into the REPL, and if that code isn't using outer parens, how would it be parsed? it wouldn't be a problem if it was pasted and read in a 'chunk', but i think in my console it's pasted line-by-line or parsed line-by-line as if manually input. i'm not sure. hmmm. we might have to say "use outer parens if you're going to paste the code into the REPL"
however, that's the behavior as it is now in the scheme REPL. a custom Arc REPL would be able to handle things like pastes appropriately (maybe. i'm not familiar with console mechanics, but even if it wasn't 'purely' possible, a timer could be used so that if the delta between the last and currently entered lines is less than X, then it would be safe to assume the sequence was pasted)
for infix math it might be best to have a marker that says "the following form is infix"
#( (3 + 2) / 8 ) -> (/ (+ 3 2) 8 )
some other thoughts are notations for pattern matching/RE's
I'm really uncomfortable about making the repl and file readers differ, especially to the point of being incompatible.
About a custom console, I am not sure there is any reliable way to detect when a user has pasted code into the console. (That sort of thing is probably very OS dependent.)
Even if you did set up a timer like you propose, what would it do if the user recalled some lines from a multiline entry in history? I think most consoles would only pull up one line of history at a time, so the user would have to go through each line and enter it individually. And the timing would be such as to be indistinguishable from direct input from the user.
As for infix math, if you created an infix marker like
Is w/inline hardcoded to look for .dll files on Windows? Because when I tried to use MSYS and MinGW the file produced was a .so file rather than a .dll, which caused an error when w/inline looked for a .dll file. Thanks.
Well, the library extension is added automatically to the generated file by mzscheme. A .so is added on Unix systems, a .dll on Windows. The solution would be to change the compilation command in ffi.arc : it's something like "gcc -O3 --shared -o foo.so foo.c". Just change it to foo.dll and it might be working. I don't know how to automate this however. If someone has an idea...
The funny thing is that I wrote FFI for one reason besides optimization : I wanted a POSIX interface, so as not to rely on the system function, which is as broken as any shell script.
Imagine you make a script to remove all files ending with a ~ as they are backup files : foo.tex~, bar.c~ and so on. Now imagine your stupid user named a file ~. Guess what happens if you call "rm -r $file" in your script. It also works with files starting with - and many other funny things.
Actually, if you are using Anarki, a lot of the slowness comes from infix.arc redefining math operators. Just removing infix.arc from libs.arc will increase the speed of math operations by about an order of magnitude. In fact, removing infix.arc actually produced more of a speedup for me than using your ffi.
With infix.arc:
arc> (def fib (n) (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
#<procedure: fib>
arc> (time (fib 30))
time: 34672 msec.
1346269
Without infix.arc:
arc> (def fib (n) (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
#<procedure: fib>
arc> (time (fib 30))
time: 4219 msec.
1346269
Yeah, sorry about that. I wasn't thinking about performance when I originally put infix.arc up on Anarki, and since I was doing a lot of testing at the time I found it convenient to add it to libs.arc. Perhaps it would be best to leave it out by default though.
Oh that's right... On my machine, the FFI version is still a little faster (about 20% faster), but not that much. It now deals more efficiently with boolean values however, that might explain it... Anyway, I don't know if it's worth using FFI this way now... Not until we can compile Arc code to efficient C code at least :)
