I use the server portion of Arc to write web-based applications, and would like to upload files.
Anarki hadn't worked very well or very fast when uploading. I might just bite the bullet and use web.py alongside Arc, and have Python calling Arc after a file has been saved. I might also resort to using Anarki, although breaking backward compatibility in a few ways can become a bit of a concern.
I wish there were a language that offered what I need.
All this redirecting still doesn't get me what I want.
I would like this second link to be what shows up on the top of the browser as the new url. -- but I would also like that page to be initialized with parameters I could express so far only with a closure.
I don't want to pass those parameters to the second link, because then they'll be visible.
So now I need to first save these initialization parameters somewhere (much like saving a closure) and modify the second link to check if there are any scheduled parameters to initialize itself with for a particular user. Some sort of defop-init.
(Am I missing something?)
Down the drain go closures when combined with redirection.
Why not just pass a session id/key to the second URL* and allow that new page to retrieve the data you don't want exposed?
*or use a hidden field on a form submit.
BTW the limitations you're hitting have nothing to do with Arc or Closures, but rather are just limitations of Browser/HTTP technology (which are by design).
arc> ([(prn "You entered " _)] 34)
You entered 34
Error: "...urces/arc/ac.scm:974:33: arity mismatch;\n the expected number of arguments does not match the given number\n expected: 1\n given: 0"
Do you see something different? I think your defop expression is also incorrect. It just happens to have the right side-effect before it runs into the error. You probably have errors at the server -- that aren't visible on the browser.
arc> ([(prn "You entered " _)] 34)
You entered 34
Error: "car: expects argument of type <pair>; given ()"
That's good investigation. Note the work described in this thread uses Arc 3.1, not Anarki.
Btw do you mean there's something wrong with defop, or that the example I wrote is incorrect? I had gotten that example from: http://arcfn.com/doc/srv.html
If its just a one off thing then you could just emit/print raw JavaScript outputting the document onload function to trigger the storing or updating of your cookie (you could also build arc wrapper functions too).
Yeah, sorry the names have been so useless in penetrating my meaning. I'm planning to write a followup without ever using the words 'abstraction', 'library' or 'service'. Libraries don't have to suck, if you know about how they work. My definition of abstraction was that you had to know something about how it was implemented. It's just that in the real world we don't know how 99% of our libraries work, and our entire eco-system encourages that, and library writers don't care to make their implementations easy to understand because, "Who does that, go read about how it works? Just a couple of guys who'd figure it out anyway, even if I gave them no documentation."
To answer your question, the first example that pops to mind is file uploads in arc. Let's consider a parallel universe where arc came with multi-part file upload support, and it worked for you out of the box, and you never came here with questions, and I never delved into how it worked. In that scenario the file-upload features in arc would be a service to me, not an abstraction. But in this universe all those things happened[1], and now file-upload is an abstraction for me. I know I can get into its guts if I find something wrong. I've become a lion when it comes to file upload (http://paulgraham.com/boss.html).
Notice that this would be true even if the code I wrote for it were identical to the code the authors of arc would have written (ha!). This isn't a technical argument but a social one: Programmers should learn about their dependencies. Or put another way: Ask not if something is an abstraction. Ask if it is an abstraction to you.
It's surprising that macros destroy functions rather than generate them.
Thanks for vau. It seems it's defun (and def) that are redundant. Compile-time can be modeled as run-time where t = 0, which means one could have macros at run-time. Some such macros could choose to not evaluate their results.
I don't understand what you mean by macros "destroying" functions. They are completely different concepts. They behave differently and they are used for very different purposes: they are orthogonal.
---
It is possible to design a Lisp that doesn't have a function/macro distinction. Such a Lisp would just use vau for everything. An example is the language Kernel:
So, to answer your original question: no, it is not necessary to have both mac and def, but that's how most Lisps (including Arc) do it. I think the primary reason is historical, since I think the speed argument is actually bogus for most programs.
Well, I'm not sure I'd say that... what vau does is remove the need for mac, but def is still there, to make it more convenient to define functions.
That does mean that functions can be implemented in user-land, which is very nice, but it doesn't really change functions very much.
---
Also, I prefer to not think of vau as being "the ultimate macro", I prefer to see it as a construct which is very different from macros, but happens to serve the same purpose in most cases, which is why vau can replace macros in most (but not all!) cases.
Then again, I also prefer to see functions as being separate from vaus, even if they're implemented using vau... So take what I say with a grain of salt.
It took me a while to realize that I shouldn't think of vau as a macro-like thing. Macros and functions are different kinds of evaluation policies; vau just lets you construct arbitrary evaluation policies. It's like discovering the quarks that all fundamental particles are made up of; quarks don't preferentially constitute an electron more than a neutron.
The challenge now is to build a runtime where vau can have performance comparable to existing lisp systems.
That's what vaus do... which I already covered in my second post. The word "function" in Scheme, Common Lisp, JavaScript, Python, Ruby, Lua, etc. all refer to something that always evaluates its arguments. Arc is no different.
