Sorting of function definitions in namespaces

[jkrueger]

When writing a Clojure namespace very often I would like to sort my
functions according to level of abstraction, starting with the most
abstract functions, followed by helper functions to the more abstract
functions, and so on. This way of organizing code is promoted as good
style by the Clean Code guys. However, to do this in Clojure one would
have to declare almost every function in the namespace before actually
defining it, since namespaces are interpreted top-down. This strikes
me as very ugly. Since other functional languages like Haskell manage
to avoid this problem, I would like to suggest that Clojure should
provide a way to support this organizational scheme in the future.

[Laurent PETIT]

Hi,

Create & use dotopdown (or doreverse, name it as you like):

user=> (defmacro dotopdown [& body] `(do ~@(reverse body)))
#'user/dotopdown
user=> (dotopdown (defn abstract [a] (helper a)) (defn helper [a] (str a)))
#'user/abstract
user=> (abstract 30)
"30"

;)

2011/2/9 jkrueger <jan.k...@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[jkrueger]

Sure. I'm not saying that you can't write it yourself. My point was,
that

a) This is essential to writing understandable code, so it would be
nice if the language supported it out of the box
b) A namespace feels to me like a set of functions (ns-publics
actually returns a map). That Clojure enforces a particular ordering
(if we forget about the "declare" kludge) while writing a namespace
seems arbitrary from a programmers point of view.

Jan

On Feb 10, 9:43 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Hi,
>
> Create & use dotopdown (or doreverse, name it as you like):
>
> user=> (defmacro dotopdown [& body] `(do ~@(reverse body)))
> #'user/dotopdown
> user=> (dotopdown (defn abstract [a] (helper a)) (defn helper [a] (str a)))
> #'user/abstract
> user=> (abstract 30)
> "30"
>
> ;)
>

> 2011/2/9 jkrueger <jan.krue...@gmail.com>

[Meikel Brandmeyer]

Hi,

Am 10.02.2011 um 16:27 schrieb jkrueger:

> a) This is essential to writing understandable code, so it would be
> nice if the language supported it out of the box

Is that so? I'd rather say that this a personal opinion of yours. There are different ways to organise code and neither is superior to the other. Just different.

> b) A namespace feels to me like a set of functions (ns-publics
> actually returns a map). That Clojure enforces a particular ordering
> (if we forget about the "declare" kludge) while writing a namespace
> seems arbitrary from a programmers point of view.

But Clojure's model of evaluation of a namespace also has a simple elegance. Defining a function is treated equally to adding two numbers. Everything is consistent. It is easy to determine what happens when. There are no special cases. This should seem quite logic from a programmers point of view.

Sincerely
Meikel

[jkrueger]

On Feb 10, 9:33 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
> Hi,
>
> Am 10.02.2011 um 16:27 schrieb jkrueger:
>
> > a) This is essential to writing understandable code, so it would be
> > nice if the language supported it out of the box
>
> Is that so? I'd rather say that this a personal opinion of yours. There are different ways to organise code and neither is superior to the other. Just different.
>

Well... It is Robert C. Martin's opinion. I just happen to agree with
him. I don't mean to call on a higher authority as an argument
stopper. But people who have put a lot of thought into organizing
code, seem to have arrived at this opinion. I definitely phrased the
original sentence too strongly. I should have said that I _think_ that
it is essential to writing readable code.

> > b) A namespace feels to me like a set of functions (ns-publics
> > actually returns a map). That Clojure enforces a particular ordering
> > (if we forget about the "declare" kludge) while writing a namespace
> > seems arbitrary from a programmers point of view.
>
> But Clojure's model of evaluation of a namespace also has a simple elegance. Defining a function is treated equally to adding two numbers. Everything is consistent. It is easy to determine what happens when. There are no special cases. This should seem quite logic from a programmers point of view.
>

I'm perfectly willing to be convinced that I'm wrong if there are good
reasons not do this in Clojure. That's why i brought it up as a
discussion. Additional complexity in the core language is obviously a
concern. Still, I feel that the fixed ordering is a restriction that
is very bothersome when trying to clean up my code. I think I will
spent some more time thinking about how this would actually affect the
language.

> Sincerely
> Meikel

[Joost]

On Feb 10, 4:27 pm, jkrueger <jan.krue...@gmail.com> wrote:
> Sure. I'm not saying that you can't write it yourself. My point was,
> that
>
> a) This is essential to writing understandable code, so it would be
> nice if the language supported it out of the box

I don't agree it's essential. I think if you use namespaces, you can
easily structure code in a way that's "top down":

(ns high-level
(:use lower-level))

(defn high [a b]
(low1 a (low2 b)))

The order within a file is not that important, because a single file
shouldn't contain enough code to be confusing.

> b) A namespace feels to me like a set of functions (ns-publics
> actually returns a map). That Clojure enforces a particular ordering
> (if we forget about the "declare" kludge) while writing a namespace
> seems arbitrary from a programmers point of view.

Yes it's arbitrary, but the other way around would be arbitrary too,
and IME

1) it's fairly rare that you actually *need* a declare "kludge".
2) full free ordering generally makes stuff harder to find than
"enforced order".

In conclusion, I see the current behavior as slightly more a feature
than an issue.

Joost.

[Joost]

On Feb 11, 12:02 am, Joost <jo...@zeekat.nl> wrote:
> Yes it's arbitrary, but the other way around would be arbitrary too,
> and IME
>
> 1) it's fairly rare that you actually *need* a declare "kludge".
> 2) full free ordering generally makes stuff harder to find than
> "enforced order".

I forgot to add that I've used Perl a lot, which does *try* to do free-
style ordering, and it ended up with a system that works most of the
time, but is really not easy to figure out when it doesn't work, and
even adding "declare" style statements don't always work like you want
to. I really prefer an enforced order with *reliable* declarations.

[Benjamin Teuber]

As a user coming from Haskell, I've always been disturbed by Clojure's
C-like behavior at this point, so I'd agree with the OP. And of course
the solution is not just reverse, as any order should be possible.

The question is how one could implement this without raising more
problems. Maybe a strategy could be like the following:
- Start the old compiler
- For each "symbol undefined" exception:
- add a declare on top of the namespace
- add a (when-not (bound? sym) (error "symbol undefined")) on the
bottom of the namespace.

So all undefined symbols will get declared first, but after compiling
the namespace, make sure they really have been bound somewhere.
Are there any edge cases where this strategy wouldn't work out?

Just my 2 cents,
Benjamin

[Laurent PETIT]

2011/2/11 Benjamin Teuber <bste...@googlemail.com>

As a user coming from Haskell, I've always been disturbed by Clojure's
C-like behavior at this point, so I'd agree with the OP. And of course
the solution is not just reverse, as any order should be possible.

of  course :-)

The question is how one could implement this without raising more
problems. Maybe a strategy could be like the following:
- Start the old compiler
- For each "symbol undefined" exception:
 - add a declare on top of the namespace
 - add a (when-not (bound? sym) (error "symbol undefined")) on the
bottom of the namespace.

this is not how the Clojure compiler works. The clojure compiler sequentially evaluates forms,
There's no such thing as "the bottom of a namespace".
 
Maybe some kind of "lazy compilation", some day ...

So all undefined symbols will get declared first, but after compiling
the namespace, make sure they really have been bound somewhere.
Are there any edge cases where this strategy wouldn't work out?

Just my 2 cents,
Benjamin

[semperos]

To throw another opinion in the mix...

Lisp programming encourages a "bottom-up" style of development. I feel this fits very naturally with Clojure's function-order requirements, as you build the "vocabulary" of your program starting with small units. Combined with logical separation of files and namespaces, there are no surprises while writing or reading Clojure.

When reading Clojure source code, I just skip to the bottom of the file and can be fairly sure I'll find higher-level functions that I can understand, then jump back up when needed.

[Fogus]

> Well... It is Robert C. Martin's opinion.

Who?

> I should have said that I _think_ that it is essential to
> writing readable code.

I definitely agree with this.

Another thing that I happen to agree with is that Clojure's model fits
my way of programming in Clojure.

[gaz jones]

>> Well... It is Robert C. Martin's opinion.

>Who?

'uncle' bob martin:
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Also, it's pretty easy to just reverse the level of abstraction
ordering from bottom-to-top is it not? I usually jump to the bottom of
the file to start with when editing Clojure code...