Re: [Haskell-cafe] Unifcation and matching in Abelian groups
> ... Haskell is old and has the optional offset rule:
>
> do { prob <- getLine
> ; test prob
> ; main}
It's interesting to see people put semicolons at the begining of a
line of code. In 1970s, people used to draw lines on printouts of Ada
and Pascal code to connect the begins with the ends. My first
publication
Ramsdell, J. D., "Prettyprinting Structured Programs with Connector
Lines," ACM SIGPLAN Notices, Vol. 14, No. 9, p. 74, September 1979
suggested prettyprinting Ada and Pascal programs with the semicolons
at the begining of the lines and use them as the connector lines.
Thus a prettyprinted Ada program looked like:
package Mine is
...
begin
; while i < Integer'Last loop
; ;Print (i)
; end loop;
end Mine;
It didn't work quite as well in Pascal, because semicolon was a
statement separator instead of a statement terminator.
In those day, procedures tended to large and deeply nested because
procedure invocation was expensive.
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Sat, Aug 22, 2009 at 8:30 PM, Lennart
Augustsson wrote:
> Even if you are only slightly irritated by offset syntax, why are you using
> it?
> {;} works fine.
I hadn't thought about that option. I'll give it a try on my next program.
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
Even if you are only slightly irritated by offset syntax, why are you using it?
{;} works fine.
On Sat, Aug 22, 2009 at 3:51 AM, John D. Ramsdell wrote:
> Let me put all my cards on the table. You see, I really am only
> slightly irrigated by offset syntax. In contrast, I am a strong
> proponent of functional programming for parallel programming. In my
> opinion, it has to be the "new way" for multiprocessor machines. Just
> think about it and if other paradym could possibly work. We've tried
> many on them. Many years ago, I wrote SISAl programs. There were
> many good ideas in SISAL, but it did not catch on. Perhaps Data
> Parallel Haskell will catch on. In my opinion, something like it is
> the ``answer.'' Even though the code I submitted is not parallel,
> I've thought about how to make it so. And isn't thinking parallelism
> iour future? I think so.
>
> John
>
> On Thu, Aug 20, 2009 at 10:04 AM, Jules Bean wrote:
>> John D. Ramsdell wrote:
>>>
>>> On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote:
>>>
I don't find layout a problem, with good editor support. I agree it's a
problem, with poor editor support. That's all I meant.
>>>
>>> Let's put this issue in perspective. For those few Haskell
>>> programmers that do find layout irritating, I'm sure we would all
>>> agree it's but a minor irritation. The real downside of layout is if
>>> non-Haskell programmers use it as an excuse to dismiss the language.
>>> I happen to think that Data Parallel Haskell has great potential for
>>> use in high performance computations. I'd hate to see a bunch of
>>> Fortraners not try DPH because of Haskell syntax.
>>
>> Well that's a reasonable point.
>>
>> They can still use the non-layout form if it bothers them that much?
>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
Let me put all my cards on the table. You see, I really am only slightly irrigated by offset syntax. In contrast, I am a strong proponent of functional programming for parallel programming. In my opinion, it has to be the "new way" for multiprocessor machines. Just think about it and if other paradym could possibly work. We've tried many on them. Many years ago, I wrote SISAl programs. There were many good ideas in SISAL, but it did not catch on. Perhaps Data Parallel Haskell will catch on. In my opinion, something like it is the ``answer.'' Even though the code I submitted is not parallel, I've thought about how to make it so. And isn't thinking parallelism iour future? I think so. John On Thu, Aug 20, 2009 at 10:04 AM, Jules Bean wrote: > John D. Ramsdell wrote: >> >> On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote: >> >>> I don't find layout a problem, with good editor support. I agree it's a >>> problem, with poor editor support. That's all I meant. >> >> Let's put this issue in perspective. For those few Haskell >> programmers that do find layout irritating, I'm sure we would all >> agree it's but a minor irritation. The real downside of layout is if >> non-Haskell programmers use it as an excuse to dismiss the language. >> I happen to think that Data Parallel Haskell has great potential for >> use in high performance computations. I'd hate to see a bunch of >> Fortraners not try DPH because of Haskell syntax. > > Well that's a reasonable point. > > They can still use the non-layout form if it bothers them that much? > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote: I don't find layout a problem, with good editor support. I agree it's a problem, with poor editor support. That's all I meant. Let's put this issue in perspective. For those few Haskell programmers that do find layout irritating, I'm sure we would all agree it's but a minor irritation. The real downside of layout is if non-Haskell programmers use it as an excuse to dismiss the language. I happen to think that Data Parallel Haskell has great potential for use in high performance computations. I'd hate to see a bunch of Fortraners not try DPH because of Haskell syntax. Well that's a reasonable point. They can still use the non-layout form if it bothers them that much? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote: > I don't find layout a problem, with good editor support. I agree it's a > problem, with poor editor support. That's all I meant. Let's put this issue in perspective. For those few Haskell programmers that do find layout irritating, I'm sure we would all agree it's but a minor irritation. The real downside of layout is if non-Haskell programmers use it as an excuse to dismiss the language. I happen to think that Data Parallel Haskell has great potential for use in high performance computations. I'd hate to see a bunch of Fortraners not try DPH because of Haskell syntax. In terms of irritating programmers, I think Wirth takes the cake. After advancing the art with Pascal, he correctly saw its lack of modules as a problem, and he solved the issue with the Modular-2 programming language. He made the improvement, but also required programmers to type keywords in all caps! I tried Modular-2 and quickly tired of using the caps lock key. Maude has this problem too. Very irritating. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote: > I don't find layout a problem, with good editor support. I agree it's a > problem, with poor editor support. That's all I meant. Let's put this issue in perspective. For those few Haskell programmers that do find layout irritating, I'm sure we would all agree it's but a minor irritation. The real downside of layout is if non-Haskell programmers use it as an excuse to dismiss the language. I happen to think that Data Parallel Haskell has great potential for use in high performance computations. I'd hate to see a bunch of Fortraners not try DPH because of Haskell syntax. In terms of irritating programmers, I think Wirth takes the cake. After advancing the art with Pascal, he correctly saw its lack of modules as a problem, and he solved the issue with the Modular-2 programming language. He made the improvement, but also required programmers to type keywords in all caps! I tried Modular-2 and quickly tired of using the caps lock key. Maude has this problem too. Very irritating. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Wed, Aug 19, 2009 at 8:32 AM, Jules Bean wrote: Do not blame haskell, blame emacs, if emacs is so stupid. How can you blame emacs? Do you expect emacs to read programmer's minds? No, I expect emacs to select a suitable first indentation guess and give the programmer a natural way to choose alternative ones. I don't think the initial haskell-mode implementation had that property. I don't find layout a problem, with good editor support. I agree it's a problem, with poor editor support. That's all I meant. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Wed, Aug 19, 2009 at 8:32 AM, Jules Bean wrote: > > Do not blame haskell, blame emacs, if emacs is so stupid. How can you blame emacs? Do you expect emacs to read programmer's minds? John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Wed, Aug 19, 2009 at 6:16 AM, Neil Mitchell wrote: Why not: if done then return () else do prob <- getLine test prob main I've given up on using if-then-else in do expressions. They confuse emacs. There is a proposal for Haskell' to fix the problem, but until then, I will not use them in do expressions. Do not blame haskell, blame emacs, if emacs is so stupid. Fortunately there is a better emacs mode which understands layout and if: http://kuribas.hcoop.net/haskell-indentation.el I'm so glad new languages do not use the offset rule. I get tired typing tab in emacs, especially since for most other languages, emacs does so well at picking a good indent. Requiring coders to spend so much time choosing indents reminds me of the days when I wrote C code with vi. I've been there, done that, and moved on to emacs. Do not blame haskell, blame emacs. The layout rule is simple to understand and I think it makes attractive code. It's not haskell's fault that the emacs mode chooses a bad indent so often. There is a better emacs mode which gets the indentation right more often, I find ;) http://kuribas.hcoop.net/haskell-indentation.el Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Wed, Aug 19, 2009 at 6:51 AM, Neil Mitchell wrote: > F# is new and has the offset rule. Haskell is old and has the optional > offset rule: I thought F# uses OCaml syntax. Emacs does well with OCaml syntax. Guy Steele told this story at a conference. As part of the Fortress design effort, he and other at Sun visited several sites that make use of high performance computing. They received a variety of suggestions on how to design a high productivity language for high performance computing, and uniformly were asked not to give programmers a language that uses the offset rule. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
Hi
> I've given up on using if-then-else in do expressions. They confuse
> emacs. There is a proposal for Haskell' to fix the problem, but until
> then, I will not use them in do expressions.
It's a shame, there are ways of indenting them that work, but they're
not as natural. It's a wart, but it will be fixed.
> I'm so glad new languages do not use the offset rule.
F# is new and has the offset rule. Haskell is old and has the optional
offset rule:
do { prob <- getLine
; test prob
; main}
Now your indentation is your own :-)
Some people prefer this style. Simon Peyton Jones uses it in the book
beautiful code. I much prefer indentation only.
Thanks
Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
On Wed, Aug 19, 2009 at 6:16 AM, Neil Mitchell wrote: > Why not: > if done then return () else > do prob <- getLine > test prob > main I've given up on using if-then-else in do expressions. They confuse emacs. There is a proposal for Haskell' to fix the problem, but until then, I will not use them in do expressions. I'm so glad new languages do not use the offset rule. I get tired typing tab in emacs, especially since for most other languages, emacs does so well at picking a good indent. Requiring coders to spend so much time choosing indents reminds me of the days when I wrote C code with vi. I've been there, done that, and moved on to emacs. > unless done $ > do prob <- getLine > test prob > main I do like this suggestion. Thanks. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
Hi, I ran your code thought HLint (http://community.haskell.org/~ndm/hlint), and it suggested a couple of things (mainly eta reduce). The most interesting suggestions are on your main function: > main :: IO () > main = > do > done <- isEOF > case done of > True -> return () > False -> > do > prob <- getLine > test prob > main It suggests: Example.lhs:432:3: Warning: Use if Found: case done of True -> return () False -> do prob <- getLine test prob main Why not: if done then return () else do prob <- getLine test prob main Changing that and rerunning says: Example.lhs:432:3: Error: Use unless Found: if done then return () else do prob <- getLine test prob main Why not: unless done $ do prob <- getLine test prob main So I (or rather HLint) recommends you do: > main :: IO () > main = > do > done <- isEOF > unless done $ do > prob <- getLine > test prob > main Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
