Sorry for the omission :) I did a couple years of C# development back on 2002, but for some reason the whole .NET area slipped my mind. I added C#, but I'll wait to add Visual Basic until someone has the courage to suggest it :)
Ah, I remember that too. Those innocent days where most of the problems were like "should I use 'print' or 'input' there ? What's the difference between them ?"
In particular, the kind of commands you're looking for are:
w/infile (open a file for input, execute some code, and then close it)
w/outfile (same as w/infile but for output)
readc/readb (read a character/byte from an open file)
writec/writeb (write a character/byte to an open file)
Other useful operators are readfile, writefile, drain and w/stdout. Note that most of the Arc functions related to file manipulation assume that the file you're editing is Arc code (e.g. readfile) so watch out for that. I haven't yet found an easy way to read the contents of a file into a string, but the following function works:
In the future, everyone will use Lisp, but they won't know it's Lisp, because it will be called Microsoft Windows Dynamic Service-Oriented Parenthesis Construction Language for .NET.
Mr Dussud (a respected Lisper in a former life) said MS would be happy to host a Lisp if we would just add strong static typing and lose our silly little OO package, CLOS. A couple of other things, too.
Wow, yeah. I tuned him out when I saw he wanted us to declare our variable types. I did not listen to all of the audio, but in there somewhere you will hear some nutjob asking if, given that Lisp has finally started taking over the landscape and he now wants us to run up the white flag and adopt static typing, he also thinks it is time for mainland China surrender to Taiwan. That was me.
I went up later and shook his hand for being brave enough to come into the lion's den. Strong guy. <ouch>
One thing that's helped Rails adoption a lot is that you can get the whole thing up and running in 3 steps: install Ruby, install Gems, get Rails. All of this is available from one page on the Rails site, so it's really easy to try it out. You don't even need a web server; they provide one for you.
Lisp in a Box is the closest thing Lisp has to this, but can anyone seriously say that asking people to learn Lisp, Emacs and SLIME at the same time is the way to get people hooked on the language?
I think what Lisp actually needs is a nice, easy install package: Scheme/Lisp, a nice HTML help/tutorial system and a simple editor, like the one that comes with Ruby (basically Notepad with syntax highlighting and top-level integration <-- this is the key feature). Perhaps you could throw in some kind of web-app package that people can start playing with (just like the one in Arc) and a package system (one as easy to use as Gems would be nice). All of this should be wrapped up in a single installer.
This way, people have a nice, gentle introduction to the language through a simple but expedient system, and can graduate to Emacs/Vi/Eclipse at their leisure.
Oh, and big, colourful, idiot-proof websites with the instructions on them are a big draw too.
actually i don't understand any of that ^_^;; i'm a lisp noob. in other languages there aren't macros so i implement it as a function which stores the function-to-be-curried and its initial arguments in a closure
however i tested your macro with some arithmetic and it all seems to work fine. the only thing i found is that something like this will cause an error:
((fix + _ 2) 3 4)
because there isn't an underscore at the end. i don't understand lisp enough to see if that was your intention. i think for the sake of variadic functions it should adapt regardless of where the underscore is (or whether or not it's present, eg: (fix +)), either by detecting if a function is variadic (which i'm guessing isn't reasonably possible at the moment) or by always returning a variadic function [edit: actually i think i can decipher the meaning of (if (is '_ (last rest))]
if the generated expression is always variadic, it would seem to mess with the fact that the underlying system cares how many arguments there are. is that a big deal? i don't think so. a language i use this function in is Lua, whose functions are all variadic (in that the interpreter doesn't complain if you supply too few (unsupplied are niled) or too many (excess are discarded) arguments) and it simply is never a problem. to me the fixed-argument thing seems similar in spirit to static typing in that it tries to solve a problem that really isn't significant
Yes, I implemented it so it would only be variadic if there was an underscore at the end. It would actually be a simpler macro if they were always variadic, but that's such a radical change to the language that I'm a bit wary about it.
But maybe it's a good idea. I see your point about the 'spirit of static typing'. I'll have to check out Lua and see how it works out.
Edit: I mean it would be radical if fix were implicit, of course.
I've already come across multiple scenarios where automatic currying would have shortened my programs, and if the swap operator had been available, I'd have used it even more.
But I'm still not a fan of implicit currying. I think the behaviour would be too unpredicatable when mixing rest functions, optional arguments, apply and code generation together (for example, it's often useful to be able to pass 0 arguments to + when you are generating code, even if you'd never write that sort of thing manually).
My compromise: perhaps the [...] syntax could be adapted to do automatic currying. If you use _ then it has its normal behaviour, but if you don't then the function is curried automatically. Only required arguments can be passed to such a function, optional and rest arguments are ignored, so [+] simply evaluates to 0 (or a function that takes no arguments and returns 0).
I'd originally envisioned that the function returned would be more strongly typed (ie. it would expand to (fn (x y z) ...) if foo takes 4 arguments) and that the function would be truly curried, so ([foo bar] baz) would also be a curried function if foo requires more arguments.
Now I think about it, the solution you've given would be perfectly adequate. The function will still fail on the wrong number of arguments, and I almost never need the other feature at all. It would also play friendly with optional and rest arguments.
