
Greetings. Is there a reason why partial application cannot be applied in arbitrary order? Was it a technical difficulty in the design of Haskell? Or is it just following beta reduction rigorously? Thanks

Is there a reason why partial application cannot be applied in arbitrary order? Was it a technical difficulty in the design of Haskell? Or is it just following beta reduction rigorously?
Haskell doesn't dictate any particular evaluation order. If you look at the name of the Haskell report, it calls Haskell a "non-strict" language not a "lazy" language. Implementations of Haskell lean towards implementing a particular evaluation order (usually a minor variant on lazy evaluation) because it has been thoroughly studied, it has some properties, and because it leads to more consistent behaviour. Lazy evaluation tends to be the behaviour of the underlying abstract machine used by the compiler. But implementations can and do go for a different evaluation order in order to get better performance or to exploit parallel hardware. Three particular optimizations to look for are full-laziness, deforestation, and strictness analysis. -- Alastair Reid Reid Consulting (UK) Ltd

Hi, Are there any programs to strip comments and blank lines from a Haskell source file, that work on normal and literate programs? Thanks. -- Nick Nethercote njn25@cam.ac.uk

Doing a real job is 'hard' (e.g. nested block comments, -- may actually start a lexeme ...) For a simple job that does well usually see fptools/ghc/compiler/count_lines in the ghc distribution. cheers k Nicholas Nethercote writes:
Hi,
Are there any programs to strip comments and blank lines from a Haskell source file, that work on normal and literate programs?
Thanks. -- Nick Nethercote njn25@cam.ac.uk
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Cagdas Ozgenc wondered: | Is there a reason why partial application cannot be | applied in arbitrary order? Was it a technical | difficulty in the design of Haskell? Or is it just | following beta reduction rigorously? Alastair David Reid answered: | Haskell doesn't dictate any particular evaluation | order. If you look at the name of the Haskell report, | it calls Haskell a "non-strict" language not a "lazy" | language. Somehow I do not think that Cagdas was talking about evaluation order at all. I think he referred to the following: Suppose I have a function f which is defined to have 3 arguments: f x y z = ... Now, when I want to partially apply f to two arguments, say 1 and 2, I can say this: ... (f 1 2) ... However, if I want to leave out the middle argument, I have to say: ... (\y -> f 1 y 3) ... And, similarly, for the first one: ... (\x -> f x 2 3) ... This seems rather ugly, since the order of arguments in a function plays a crucial role. For example, the map function takes the list as its second argument, since it is so much more common to partially apply map with the function rather than the list. For 2-argument functions, the sections notation might help: (1 `f`) -- === (f 1) === (\y -> f 1 y) (`f` 2) -- === (\x -> f x 2) In a distant past, Erik Meijer and I experimented with introducing the syntax: (f 1 2 _) (f 1 _ 3) (f _ 2 3) But it became all very clumsy. Regards, /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.

On Mon, 18 Mar 2002, Kevin Glynn wrote:
Are there any programs to strip comments and blank lines from a Haskell source file, that work on normal and literate programs?
Doing a real job is 'hard' (e.g. nested block comments, -- may actually start a lexeme ...)
For a simple job that does well usually see
fptools/ghc/compiler/count_lines
in the ghc distribution.
Unfortunately that doesn't even handle multi-line "{- ... -}" comments... So I hacked up this wretched slice of Perl to do the job. I'm surprised there aren't programs out there that do this properly. -- Nick Nethercote njn25@cam.ac.uk

Koen Claessen
... (\x -> f x 2 3) ...
This seems rather ugly, since the order of arguments in a function plays a crucial role. For example, the map function takes the list as its second argument, since it is so much more common to partially apply map with the function rather than the list.
For sure the order of arguments play a crucial role in MLs. I don't know many other syntax: - merd http://merd.net/choices_syntax.html#function_calls f(1, 2, ) is (f 1 2) f(, 2, 3) is (\x -> f x 2 3) - OCaml's labels http://caml.inria.fr/ocaml/htmlman/manual006.html f ~y:2 ~z:3 is (\x -> f x 2 3) - Pop-11 http://www.cs.bham.ac.uk/research/poplog/primer/node96.html f(% 2, 3 %) is (\x -> f x 2 3) I'm interested in other syntaxes...
For 2-argument functions, the sections notation might help:
(1 `f`) -- === (f 1) === (\y -> f 1 y) (`f` 2) -- === (\x -> f x 2)
I never thought of this :) Of course it also works with more than 2-argument functions when you want to partially apply only the 2 second argument: (`f` 2) 1 3
In a distant past, Erik Meijer and I experimented with introducing the syntax:
(f 1 2 _) (f 1 _ 3) (f _ 2 3)
But it became all very clumsy.
do you have more info on this?

Koen Claessen contributed:
Somehow I do not think that Cagdas was talking about evaluation order at all. I think he referred to the following: Suppose I have a function f which is defined to have 3 arguments:
That's right. I was thinking of the following syntax. I orginally had the idea for C++, where you can't do partial application at all. f x y z=... f # 3 4 omitting the first parameter, and f * 3 4 using the default value for the first argument. In C++ you can specify default values. One needs to distinguish whether you are doing partial application or counting on the default value. Of course this doesn't apply to Haskell. However, I still wonder whether there is a technical difficulty why it is not implemented! Thanks for your comments.

Cagdas Ozgenc:
That's right. I was thinking of the following syntax. I orginally had the idea for C++, where you can't do partial application at all.
f x y z=...
f # 3 4
omitting the first parameter, and ....
Array languages with true multidimensional arrays often have a this kind of syntax to extract subarrays, for instance A(*,J) or A(,J) to extract column J from the matrix A. Now, if you think about arrays as partial functions from indices to values, then row J of matrix A is precisely \I -> A(I,J). This syntax can be very convenient for array computations. Björn Lisper

Koen Claessen
Suppose I have a function f which is defined to have 3 arguments:
f x y z = ...
Now, when I want to partially apply f to two arguments, say 1 and 2, I can say this:
... (f 1 2) ...
However, if I want to leave out the middle argument, I have to say:
... (\y -> f 1 y 3) ...
And, similarly, for the first one:
... (\x -> f x 2 3) ...
This seems rather ugly, since the order of arguments in a function plays a crucial role. For example, the map function takes the list as its second argument, since it is so much more common to partially apply map with the function rather than the list.
Prelude> let f = flip map [1..] Prelude> take 10 $ f (+1) [2,3,4,5,6,7,8,9,10,11] You knew this, of course, and I suppose it doesn't scale well to three or more arguments. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

"Cagdas" == Cagdas Ozgenc
writes:
Cagdas> Koen Claessen contributed:
Somehow I do not think that Cagdas was talking about evaluation order at all. I think he referred to the following: Suppose I have a function f which is defined to have 3 arguments:
Cagdas> That's right. I was thinking of the following syntax. I orginally had the Cagdas> idea for C++, where you can't do partial application at all. Cagdas> f x y z=... Cagdas> f # 3 4 As another note on the subject, this is similar to SRFI 26 for Scheme which can be found at: http://srfi.schemers.org/srfi-26/ -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla
participants (9)
-
Alastair David Reid
-
Bjorn Lisper
-
Cagdas Ozgenc
-
ketil@ii.uib.no
-
Kevin Glynn
-
Koen Claessen
-
Nicholas Nethercote
-
Pixel
-
sperber@informatik.uni-tuebingen.de