That isn't actually too hard. You'll want to write your own defop__ dealie, but essentially you can just pull the vars you want out of the req variable. before calling the rest of the body.
No, it is. Because the problem is that there's a whole bunch of defop_ dealies. defopr, defop-raw. Sure, you can make a macro-making macro, but I think it's better if we start from the top and define it in defop-raw, so that everything that builds on top of it uses (arg1 arg2) syntax.
Of course, there might be subtleties involved here anyway.
Technically no. I read up on the spec a while back. GET parameters are probably better referred to as URL args, and they're always retrievable via the URL in the first line of the HTTP request. In the case of a POST, the content of the request may (also) have arguments.
It's not super common to use both, but it's definitely not disallowed by the spec.
I'd be interested in seeing any references about this. From what I've read, it seems the intent is to not combine them, but I haven't seen anything explicitly forbidding it. Do you have a source that indicates combining URL parameters in a POST is encouraged, or at least permitted?
"I noticed that in the case of POST handle-request-thread (srv.arc) throws away the GET args."
Which seems to be criticizing what I would consider perfectly valid behavior. I'm not sure why you would want to split your parameters for a POST between the POST parameters and pieces of the URL.
If a change to the source is being suggested, it seems reasonable to determine if it's warranted by the protocol.
complement only works with functions. behind the scenes, it uses apply to call the original function. at first glance, i don't really see a reason that it couldn't just do the same as (compose no _)
I know compose works on macros... but I'm not sure you are straight on, because compose uses apply as well. And the macro expansions look exactly the same.
arc> (macex '(compose no litmatch))
(fn gs1639 (no (apply litmatch gs1639)))
arc> (macex '(complement litmatch))
(fn gs1641 (no (apply litmatch gs1641)))
arc> ((compose no litmatch) "a" "aston")
nil
arc> ((complement litmatch) "a" "aston")
Error: "vector-ref: expects type <non-negative exact integer> as 2nd argument,
given: \"a\"; other arguments were: #3(tagged mac #<procedure>)"
except calls to compose are optimized away in the interpreter. they are treated specially. look in the `ac' function in ac.scm. i'm guessing this is the reason.
Now, what to do about the other case... there's still no reason it should bug out, it seems to me. Or rather, it should be implementable in such a way that it shouldn't.
Yes, we do. But if I recall (and I can't test, because the git "wiki" broke for later mzschemes again), apply does work for macros, except it evaluates all the arguments first, which breaks things like and. Someone should test that, though; as I noted, I can't.
I saw, that's how I was able to test. Thank you for setting it up, by the way! And if you fixed it, thank you for that; if someone else did, thank them for that.
Hmm. Allowing keyword args is pretty un-Arc-ish (is there a term for this yet?) in my eyes. Lots of extra tokens to specify keywords when you could've just used positional arguments with some optional args at the end.
Keyword arguments definitely have their place. They fix a problem with having too many optional args. Example:
(def foo (a b c (o d) (o e) (o f) (o g))
If you want to call foo with g but not the other optional args, you'd have to write
(foo 1 2 3 nil nil nil 42)
It's easy to loose track of positional args when there are more than say 5 of them (depends on the person), and it gets a lot worse when some are just nils. The above call with keyword args instead of optionals would be something like;
(foo 1 2 3 'g 42)
Or, depending on the implementation, there might be a special syntax;
I think there are two distinct cases here. The first is when a procedure is taking a number of options/switches. The second is when the function has a long list of optional arguments.
I actually think the second is pretty rare, especially if the argument list is ordered by practical use. The first is handled pretty nicely by passing in association lists or hash tables. Of course, the current syntax for creating hash tables doesn't make using them as arguments super-easy, but they're the equivalent of passing a dictionary in python for kwargs, and they don't require any new syntax.
edit:
In my imagined world, your last example would look something like
I don't see the distinction between taking a number of options and having a number of optional arguments. To me, this is exactly the same. A switch is an argument that is only checked for true/false, which means that in ordinary function calls you only really want to bother with it when passing 't.
It's true that passing a data structure can do most of the job of keyword arguments. Any searchable structure will do, really. Perhaps the simplest form from the call site's point of view is a property list. If Scheme's plist-get was implemented in Arc (trivial, but pg would probably pick a shorter name):
(def foo (a b c . rest)
(plist-get rest 'g))
arc> (foo 1 2 3 'g 42)
42
So, what do keyword arguments give you that tables/alists/plists do not?
1) better self documentation - the function signature tells what keys it understands
2) less code in the function body - you access the value like any other argument
3) a default form which is only evaluated if no value was given - without adding code to the function body
noprocrast mode is supposed to keep you from procrastinating by using the forum. It's probably not so useful here, but it's a carryover from news.yc.
If you turn it on, maxvisit is the maximum session length here. minaway is the minimum time away from the site before you can start a new session. The site'll catch you breaking the rules, but you can continue despite its warning not to.
