Arc Forumnew | comments | leaders | submitlogin
Implicit progn
9 points by aidenn0 6151 days ago | comments
Why is it that there is no implicit progn on cond, but there is on let. It seems inconsistent. Arc wouldn't even need a "with" if let had no implicit progn.

For example (with (x 3 y 4) (sqrt (+ (expt x 2) (expt y 2))))

could become:

  (let x 3
       y 4
        (sqrt (+ (expt x 2) (expt y 2))))
This seems much more in keeping with the feel of arc. I tried to do something like the above with let and had too re-read the tutorial to remember about with.


3 points by drcode 6151 days ago | link

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.

-----

3 points by cooldude127 6151 days ago | link

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.

-----

1 point by kennytilton 6151 days ago | link

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. :)

-----

3 points by bogomipz 6150 days ago | link

Just a follow up question on this. How do people feel about (fn ... ) not having implicit progn? That sounds extreme, I know, but it would open the door for pattern matching in the very core of Arc.

  (fn (x y)
        (prs "two args:" x y)
      ((x . xs))
        (prs "a cons cell:" x xs)
      args
        (prs "many, many args:" args))

-----

1 point by drcode 6150 days ago | link

that actually looks pretty nice...

-----

2 points by eds 6151 days ago | link

There was a post a while ago about a form of let that managed to mix both multiple assignments and implicit progn behavior, although if I recall correctly it had problems with destructuring binds.

  (let var1 expr1
       var2 expr2
       ...
       (form1 ...)
       (form2 ...)
  )
http://rondam.blogspot.com/2008/02/z-shrtr-bttr.html

The post in question was actually about conciseness as a metric, and the example used in his argument was exaggerated to make his point, but the form he created (the modified let) might actually be useful (although the last stage of his example was a little scary... maybe we shouldn't take it all the way).

-----

5 points by aidenn0 6151 days ago | link

I don't think mixing the two is good. I think the lack of implicit progn would be a Good Thing. The explicit progn makes non-functional code stand out, and it also makes the language a bit more uniform if no primitives have implicit progn. All other things being equal uniformity is good because it reduces surprises. Unless there are a lot of people who feel like the implicit progn is an important part of "let" I'd prefer to not have it.

-----

1 point by bOR_ 6067 days ago | link

nice link, and he makes some good points on keeping away from uberbrevity. Maybe we should let and with rest ;).

-----

3 points by cooldude127 6151 days ago | link

i agree, and pg has stated before that he likes explicit 'do's because they highlight code that isn't functional. this might be considered, i hope.

-----