> 1. scaffold.arc / inst-entity1 uses global variables. Is this deliberate? Why?
The arc eval doesn't seem to support local environments or passing of environments, so this is the only way to pass in anaphoric variables I could find on my first pass. This function could probably be rewritten without eval and with proper scoped anaphoric variables, but given what is happening in the code this requires serious macro-fu. I do sort of know what I'm doing here- The evals and global vars don't make me feel good either... I will clean this up eventually, but won't complain if someone else figures out how to do it first :)
> 2. Personally I would recommend using the following interface to inst-entity1:
I think variadic functions tend to be library (general) functions, whereas actual applications are often full of fixed arity functions. For instance, I think you will find that news.arc is full of fixed arity functions.
I believe that looking at the arc libraries when judging the value of implicit currying may be misleading, since its greatest value is in code written for a single application...
This is certainly true, at least to an extent, but it makes currying inconsistent, which is irritating. I'm not convinced that [] and par create substantially longer code than implicit partial application, which (as noted) has issues. And the other problem, as was pointed out, is optional parameters; since they are similar to rest parameters, the objection is similar, but the problem is more insidious.
Since the arity information is lost for any complement ~f (for instance, but any general or composed function will do) of a function f:
(def complement (f) (fn args (no (apply f args))))
automatic currying turns all composed functions into second degree citizens, which adds programmer burden to the use of any function, in keeping track of whether it will invoke or return a new function.
Ooh... I hadn't seen withs before. That'll be useful.
But you're right, it still doesn't fix it. The closest thing is labels in Common Lisp, but that can only be used to create functions. Perhaps if even CL can't do it then it's not that useful after all.
I would suspect the answer is that it is more common to have a single variable but multiple statements, as opposed to the reverse... simply a matter of code brevity. I prefer the current behavior, but agree your version is better for FP code... but I don't really think arc is really optimized around the purely functional style, compared to other languages.
i would have to disagree about how common the single variable thing is. at least in my own code, i have many more withs than i have let's with multiple statements. but then, i try to do functional programming whenever i can.
and also, arc is at least a little geared toward functional style. in my other comment i brought up that one of the things pg liked about his if version is that the explicit 'do' makes non-functional code more obvious.
But the more functional the programmer the less likely they are to need temporary variables, so the count 1 should be more frequent! <g> In my CL experience it comes up often enough that I have a policy where the let will be at the toplevel in a function: I use &aux (to repeat, a CL hack):
(def my-fun (x y z &aux (temp (other-fun x y)))
...etc...)
Why? Yes I have a twenty-inch flat panel but I am still an almost obsessive indentation miser, and it just kills me to add a level of parens and indentation just to get one lousy temp variable. :)
What I'm arguing is that the _ would let you grab the original parameter without destructuring. Sometimes (like in my example) it's useful to have access to the original parameter. This is especially since, unlike CL, arc destructuring is lossy, since it allows (car nil) -> nil.
I agree with your sentiment. I also agree with pgs sentiment that modules are a cognitive barrier when dealing with code... that doesn't mean it can do without one, but I think it needs to be thought through carefully...
I think it's in the ansi common lisp book- unfortunately, my copy became too dog eared (the paperback is unfortunately a bit flimsy) and I threw it out, otherwise I'd let you know for sure. I think he was complaining about the CL module system being to hard to understand...
"The kind of modularity provided by packages is actually a bit odd. We have modules not of objects, but of names. Every package that uses 'common-lisp' has access to the name 'cons', because 'common-lisp' includes a function with that name. But in consequence a variable called 'cons' would also be visible in every package that used 'common-lisp'. If packages are confusing, this is the main reason why; they're not based on objects, but on their names".
I like the interesting footnote, very relevant to this discussion:
> So perhaps packages will turn out to be a reasonable way of providing modularity. It is prima facie evidence on their side that they resemble the techniques that programmers naturally use in the absence of a formal module system.
The problem is that instead of learning Lisp/Arc people are spinning their wheels trying to design it. I see very little sign here of people actually programming in Arc. If pg had just laid down the law folks would be using Arc instead of trying to fix a language whose excellent heritage is unknown to them. But I think some good ideas came out of the first wave of suggestions so I am undecided on the merits of the dictator's three-microphone town meeting.
"won't have anything worth releasing for months..."
Er, um, dude... it's Lisp, you are supposed to be able to release it every day. Please don't tell us you are still running the system specification document past the user acceptance committees.
Well, I do not totally agree with you there. I have programmed in Arc both for fun and work, and have also coded in Scheme a little, and I really find the . and ! syntax is really a good thing for structure access, mainly when you have nested structures. You know, when you have 3 or 4 opening parentheses at the same time. Too sad you can't fully use it in these situations.
But it's not a problem of fear of parentheses ; actually I couldn't find other cases where . and ! could be used without feeling a bit ugly (i.e. in calling functions or macros). Yes, parentheses & s-exprs are great, but I don't believe they should be the only syntax for accessing structures.
Don't worry anyway, I don't think Paul would integrate suggestions he considers weak, even if many of us asked it.
you can't for this specific problem, where functions are being called from an expanded macro and are shadowed by a local variable- look at the examples in the post.
