Steve Schafer wrote:
[Apologies for the long delay in replying; I've been traveling, etc.]
[never mind]
The other extreme is the one I favor: the whole pipeline is expressible
as a chain of function compositions via (.). One should be able to write
process = rectangles2pages .
[Apologies for the long delay in replying; I've been traveling, etc.]
On Sun, 31 Dec 2006 20:11:47 +0100, you wrote:
The other extreme is the one I favor: the whole pipeline is expressible
as a chain of function compositions via (.). One should be able to write
process = rectangles2pages .
In summary, I think that the dependencies on the pagemaster are not
adequate, he mixes too many concerns that should be separated.
True, but then that's even more miscellaneous bits and pieces to carry
around. I guess what makes me uncomfortable is that when I'm writing
down a function like
Hello Steve,
Friday, December 29, 2006, 8:10:29 PM, you wrote:
it force you to give names to intermediate results which is considered as
good programing style - program becomes more documented.
But that would imply that function composition and in-line function
definition are also Bad Style.
Hello Steve,
Friday, December 29, 2006, 5:41:40 AM, you wrote:
then I can't avoid naming and using an intermediate variable. And that
annoys me. The u in process2 is of no more value to me (pardon the
pun) as the one in process1, but I am forced to use it simply because
the data flow is no
Steve Schafer wrote:
Here's the essence of the problem. If I have this:
process1 x y =
let u = foo x y;
v = bar u;
w = baz v
in w
I can easily rewrite it in point-free style:
process1 = baz . bar . foo
Not unless you have a much fancier version of
On Fri, 29 Dec 2006 09:01:37 -0800, you wrote:
Steve Schafer wrote:
I can easily rewrite it in point-free style:
process1 = baz . bar . foo
Not unless you have a much fancier version of function composition,
like...
http://okmij.org/ftp/Haskell/types.html#polyvar-comp
Sorry; I
On Fri, 29 Dec 2006 14:23:20 +0300, you wrote:
it force you to give names to intermediate results which is considered as
good programing style - program becomes more documented.
But that would imply that function composition and in-line function
definition are also Bad Style.
Steve Schafer
I assume that your proper goal is not to structure pipeline processes
in full generality, but to simplify the current one at hand.
No, I'm looking for full generality. ;)
I have dozens of these kinds of quasi-pipelines, all similar in
overall appearance, but different in detail.
Ah, the
Steve Schafer wrote:
Here's the essence of the problem. If I have this:
process1 x y =
let u = foo x y;
v = bar u;
w = baz v
in w
I can easily rewrite it in point-free style:
process1 = baz . bar . foo
That should have been
process1 = (.) (baz . bar) . foo
On Wed, 27 Dec 2006 17:06:24 +0100, you wrote:
But in general, it's futile trying to simplify things without knowing
their meaning: names are *important*. I assume that your proper goal is
not to structure pipeline processes in full generality, but to simplify
the current one at hand.
No, I'm
Steve Schafer wrote:
In my text/graphics formatting work, I find myself doing a lot of
pipeline processing, where a data structure will undergo a number of
step-by-step transformations from input to output. For example, I have a
function that looks like this (the names have been changed to
12 matches
Mail list logo
