English Idiom in Unix: Directory Recursively

[Pascal J. Bourguignon]

Um, this is a recursive function. Inside PARENT, there is another call
to PARENT.

Feel free to derecursive it.

 

[Hans Georg Schaathun]

> Now Mac OS X has maintained the folder concept of older mac generations,
: > and Windows has cloned it. They do not want the user to understand
: > recursive data structures, and therefore, naturally, avoid the word.
:
: You imply they want to keep their users ignorant of these structures, as if
: to keep something valuable from them. Wouldn't it be more honest, more to
: the point and much simpler to state they don't NEED the user to understand
: recursive - or indeed any other - data structures? And that the user doesn't
: NEED to understand or know about them, just to use them?

Admittedly, my wording had unintended implictions. Mac OS X /targets/
users who do not need to understand the underlying structure. However,
the system also has users who do.

: After all they are users. They use their system for fun, learning or work.
: Even a very competent or advanced use of a tool (computer, car, mobile phone,
: fridge, TV, radio, toilet) in no way implies an understanding of it's inner
: workings. Nor the need, nor the desire.

For a general purpose computer, that is simply not true in general.

: PS: Isn't this thread much ado about nothing?

Most threads are.

: It starts with the misconception (or should I say confusion?) between
: performing a recursive job and using a recursive tool to do it. And then it
: blazes off in these huge discusions about semantics to define a definition
: of an abstraction of a alleady theoretical problem.

And explaining the source of the misconception and the varying use
would be irrelevant?

: And PPS: the P(P)S's don't specifically refer to your posting.

Thanks

 

[rusi]

You imply they want to keep their users ignorant of these structures, as if
to keep something valuable from them. Wouldn't it be more honest, more to
the point and much simpler to state they don't NEED the user to understand
recursive - or indeed any other - data structures? And that the user doesn't
NEED to understand or know about them, just to use them?

After all they are users. They use their system for fun, learning or work..
Even a very competent or advanced use of a tool (computer, car, mobile phone,
fridge, TV, radio, toilet) in no way implies an understanding of it's inner
workings. Nor the need, nor the desire.

PS: Isn't this thread much ado about nothing?  
It starts with the misconception (or should I say confusion?) between
performing a recursive job and using a recursive tool to do it. And then it
blazes off in these huge discusions about semantics to define a definition
of an abstraction of a alleady theoretical problem.

Glorious, just frelling glorious.    
We have an expression for that. But I'll avoid using it, since it has the
word 'masturbation' in it...

And PPS: the P(P)S's don't specifically refer to your posting.

Well...
I was rethinking my earlier argument with Ian Kelly about the
similarity/differences between recursion in theory and in CS.
On rethinking my position I come to the conclusion that I am arguing
like an chimp -- and therefore not making my real point which is that
that recursion is more widespread in computer science than is
recognised.
This is discussed separately here

http://groups.google.com/group/comp.lang.python/browse_thread/thread/212e6477262125e9#

[I agree with you Xah that recursion is a technical word that should
not be foisted onto lay users.]

 

[Roland Hutchinson]

Don't be sorry.



It's not tail recursion. If you had indented your code properly, you'd
see why it's not:

(defun dir-delete (directory)
(loop for entry in directory
do (if (is-a-directory entry)
(dir-delete entry))))

You are right, of course. Thanks for the correction.

(I put parentheses, so my editor knows what I mean and can do the
indentation for me).

My editor would have done that, too--if I had bothered to be thinking
clearly.

That's why walking a directory is done with a recursive procedure,
instead of an iterative one: it's much simplier. To implement an
iterative procedure, you would have to manage a stack yourself, instead
of using the implicit stack of the recursive procedure.

Got it! Thanks again.


--
Roland Hutchinson

He calls himself "the Garden State's leading violist da gamba,"
.... comparable to being ruler of an exceptionally small duchy.
--Newark (NJ) Star Ledger ( http://tinyurl.com/RolandIsNJ )

 

[Roland Hutchinson]

If you tell a joke, you have to tell it right.

Recursion: (N). See recursion. See also tail recursion.

Very good!

--
Roland Hutchinson

He calls himself "the Garden State's leading violist da gamba,"
.... comparable to being ruler of an exceptionally small duchy.
--Newark (NJ) Star Ledger ( http://tinyurl.com/RolandIsNJ )

 

[Steven D'Aprano]

[I agree with you Xah that recursion is a technical word that should not
be foisted onto lay users.]

I think that is a patronizing remark that under-estimates the
intelligence of lay people and over-estimates the difficulty of
understanding recursion.

Any person who has ever been to a barber or hairdresser with mirrors on
two parallel walls will be familiar with recursion: a reflection of the
reflection of the reflection of the reflection, forever.

In 1970, an extremely low-brow comedy "Carry On Up The Jungle" was about
the search for an imaginary bird that flies in smaller and small circles
until it disappears up it's own rear end, a type of recursion:

http://en.wikipedia.org/wiki/Carry_On_Up_the_Jungle

The bird in question goes back in folklore since at least 1854:

http://en.wikipedia.org/wiki/Oozlum_bird


Trust me on this, if the audience of Carry On films could understand
recursion, anyone can!

 

[Jonathan de Boyne Pollard]

〈English Idiom in Unix: Directory Recursively〉

http://xahlee.org/comp/idiom_directory_recursively.html

------------------------------------------
English Idiom in Unix: Directory Recursively

Xah Lee, 2011-05-17

Today, let's discuss something in the category of lingustics.

You know how in unix tools, when you want to delete the whole
directory and all sub-directories and files in it, it's referred as
“recursive�

[...]

Though, if you think about it, it's not exactly a correct description.
“Recursiveâ€, or “recursionâ€, refers to a particular type of algorithm,
[...]

Indeed. And the algorithms that are employed to perform the operations
so described are recursive.

 

[Jonathan de Boyne Pollard]

AFAICS what emacs calls "recursive delete" is what the ordinary person

would simply call "delete". Presumably the non-recursive delete is
called simply "delete" but is actually something more complicated than
delete, and you're supposed to know what that is.

The "non-recursive delete" would be simply calling the rmdir() system
call, which of course fails if the directory is non-empty. One has to
empty the directory of its contents, if any, first. That, of course,
involves potentially recursively removing any subdirectories, in exactly
the same way.

 

[Jonathan de Boyne Pollard]

I think what happens is that the “recursive†has become a idiom associated with directory to such a degree that the unix people don't know what the **** they are talking about. They just simply use the word to go with directory whever they mean the whole directory.

In the emacs case: “Recursive delete of xx? (y or n) â€, what could it possibly mean by the word “recursive†there? Like, it might delete the
directory but not delete all files in it?

It might *try* to delete the directory but not any of its contents,
yes. If such functionality is not offered, then putting the word in
the user interface is redundant, and possibly not the best way to warn
the user of potentially a massive loss of files and directories. But
the algorithm employed is indeed recursive.

 

[Chris Angelico]

Recursion: (N). See recursion. See also tail recursion.

caching proxy (n): If you already know what recursion is, this is the
same. Otherwise, see recursion.

ChrisA

 

[Hans Georg Schaathun]

On 20 May 2011 06:55:35 GMT, Steven D'Aprano
: On Thu, 19 May 2011 22:13:14 -0700, rusi wrote:
:
: > [I agree with you Xah that recursion is a technical word that should not
: > be foisted onto lay users.]
:
: I think that is a patronizing remark that under-estimates the
: intelligence of lay people and over-estimates the difficulty of
: understanding recursion.

Could we then say that «recursion is a technical word that should
not /unnecessarily/ be foisted onto lay users»?

 

[Antti J Ylikoski]

Feel free to derecursive it.

In the general case, to derecursive a function necessitates programming
a stack, among other things.............

Antti "Andy" Ylikoski

 

[rusi]

:  On Thu, 19 May 2011 22:13:14 -0700, rusi wrote:
:
: > [I agree with you Xah that recursion is a technical word that should not
: > be foisted onto lay users.]
:
:  I think that is a patronizing remark that under-estimates the
:  intelligence of lay people and over-estimates the difficulty of
:  understanding recursion.

Could we then say that «recursion is a technical word that should
not /unnecessarily/ be foisted onto lay users»?

Yes.
Steven is talking about the fact that the intelligent lay user may be
intelligent.
I was referring to the fact that the intelligent lay user is a lay
user. [Not my main point except to say that dragging in
alt.usage.english into a discussion of recursion seemed a tad
unnecessary and unfair]

So the ILU may understand recursion
He may not know "recursion"

 

[Jonathan de Boyne Pollard]

The supposed inefficiency of recursive implementations is based

largely on the properties of hardware that is now obsolete. With
modern processors there's no great efficiency hit. In some of the
smaller microcontrollers, it's true, you do have to worry about stack
overflow; but the ARM processors, for example, provide plenty of stack
space.

In the microcontroller world, the big performance hits come from the
fact that the only available compilers are for C and sometimes C++.
(And nobody uses assembly language except for the very little jobs.)
The nature of the C language prevents compilers from doing
optimisations that are standard in compilers for high-level languages.
Most C compilers will, for example, always pass parameters on the
stack, despite the generous supply of registers available in newer
hardware.

However, some C compilers will *also* have one or more "go faster"
calling conventions that pass parameters in registers, which can be
employed. Over in the PC world, such "go faster" calling conventions
are even the default calling convention if no calling convention is
explicitly specified, for some C and C++ compilers.


http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall

 

[Lars Enderin]

2011-05-21 10:32, Jonathan de Boyne Pollard skrev:

However, some C compilers will *also* have one or more "go faster"
calling conventions that pass parameters in registers, which can be
employed. Over in the PC world, such "go faster" calling conventions
are even the default calling convention if no calling convention is
explicitly specified, for some C and C++ compilers.


http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler


http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink


http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall

Please include attributions, in this case for Peter Moylan and rusi!

 

[Lars Enderin]

2011-05-21 11:52, Lars Enderin skrev:

Please include attributions, in this case for Peter Moylan and rusi!

Just Peter Moylan, sorry!

 

[Lars Enderin]

2011-05-21 11:54, Lars Enderin skrev:

2011-05-21 11:52, Lars Enderin skrev:

Just Peter Moylan, sorry!

Ignore the above.

 

[Grant Edwards]

In the microcontroller world, the big performance hits come from the
fact that the only available compilers are for C and sometimes C++.
(And nobody uses assembly language except for the very little jobs.)
The nature of the C language prevents compilers from doing optimisations
that are standard in compilers for high-level languages. Most C
compilers will, for example, always pass parameters on the stack,
despite the generous supply of registers available in newer hardware.

I've been doing microcontroller stuff for 25+ years, almost all in C,
and I don't think I've never seen such a compiler. Even on the
register-starved 6800 architecture, the first parameter was passed in
a register. On architectures with more registers (H8, MSP430, ARM,
etc.) It's usually the first 3 or so parameters that are found in
registers.

 

[Xah Lee]

Xah wrote:
«In the emacs case: “Recursive delete of xx? (y or n) ”, what could it
possibly mean by the word “recursive” there? Like, it might delete the
directory but not delete all files in it?
»

It might *try* to delete the directory but not any of its contents,
yes.

you mean theoretically you see a possibility if the dir is implement
as stilted as unix, but never in your life you find yourself might
want to do it?

Xah

 

[Chris Angelico]

Xah wrote:
«In the emacs case: “Recursive delete of xx? (y or n) ”, what couldit
possibly mean by the word “recursive” there? Like, it might delete the
directory but not delete all files in it?
»


you mean theoretically you see a possibility if the dir is implement
as stilted as unix, but never in your life you find yourself might
want to do it?

There's a difference between working with a directory itself and
working with files inside it. Generally, if you copy or delete a
directory, you will want to recurse. But if you want to, for instance,
wipe out all files whose names end with a tilde, then you might want
to recurse and you might not. So it makes sense to offer the user a
choice, and if recursive action is the only one that makes sense, at
least acknowledge that the operation might take an arbitrarily long
time. (Ever done a recursive operation on / on a large file system?
Takes just a little bit longer than a non-recursive one under the same
circumstances...)

Chris Angelico