Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Fergus Henderson]

On 24-Jun-1998, Frank A. Christoph <[EMAIL PROTECTED]> wrote:
> >> > 4) Module headers can be omitted.
> >> >If the module leaves out the module header, the header
> >> >   module Main(main) where
> >> >is assumed.
> >> >[and that's a mistake]
> >>
> >> Fix the compilers.  If there's no module header, the compiler should
> >> not include the module name (Main) in the error messages.
> 
> What do you propose they should use in its stead?  "Type error in the module
> formerly known as Main"?  ;)

Just "Type error".  No need to point out which module it is in if there's
only one module.

It may be reasonable to require module headers, but I don't think poor
compiler diagnostics is a sufficiently good reason, since it really
isn't that hard to just fix the compiler diagnostics.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Einar Wolfgang Karlsen]

Frank A. Christoph wrote:

>If you want a functional scripting language with H-M type inference and
type
>classes and monads, that's great, but maybe it should be something separate
>from Haskell.

Haskell is, according to my experiences with tool integration, the
ultimate scripting language around, and for several reasons:

1) Can be compiled or interpreted (no reason to rewrite your glue
   to get a fast production system)

2) Computations as first class, strongly typed values with loads of
   combinators for scripting the world with less code.

3) Extensible with new computations and combinators (BYO computational
   model so to say, such as computations for constructing HTML docs
   using a combination of the IO monad and a state transformer monad,
   or an approach to concurrency like CML's implemented on top of
   Concurrent Haskell) 

4) Extensible through foreign language interfaces like Green Card

5) Excellent support for concurrency, e.g. in the style of CML, which
   makes the (multi-threaded) glue appear at a very high level of abstraction.

6) Excellent support for string manipulation (map,fold,filter,++ ..)

7) The parsing/unparsing plumbing can be hidden by instantiations of class Read and 
Show

8) Superb features for parsing messages and output generated
   by controlled tools (using Meurig Sages regexp library or Happy)

9) The type of local names do not need to be declared due to type inference.

10) Semicolons can be omitted by careful use of the layout rule

11) Parameters to a function call can be given without parenthesis.

(9) - (10) are typical "features" of a scripting language that we
get for free in Haskell. What is "missing" is things like unquoted strings
like in Tcl (they soon turn out to be a real pain in the neck) or functions
with variable number of arguments (i.e. default expressions as in Ada).
I remember to have seen type systems for ML providing the last feature.

Other features that can contribute according to my opinion: reflection
in the sense of e.g. APL, i.e. an

eval :: String -> a

operator which could be useful when embedding Haskell logic in other
programs, i.e. by letting Hugs run as an execution enginee controlled
by a foreign tool. Existential types and extendable record types would
be great as well in setting up abstractions such as generic event
brokers and local name servers. They would also come in useful in
constructing user interfaces for collections of heterogeneous objects
(drag&drop areas for example).

Having spend the last 3 years of my professional (and to some extent
private) life integrating tools using Haskell, I'm (almost) perfectly
happy.

Einar

BTW: Moreover, I strongly promote to incorporate fully orthogonal
persistence. Sic!

RE: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Frank A. Christoph]

[I'm replying to both Fergus and Alastair in this message.]

>This is a reply to Fergus Henderson's comments on my proposal.
>
>My answer to all his comments is that consistent languages are
>easier to learn than languages littered with exceptions, special cases
>and random default behaviour.

On the one hand, Haskell has so much syntactic sugar that I am skeptical as
to whether it is really possible to eliminate all of these kinds of
problems.  On the other hand, maybe we can keep the syntactical redundancies
while eliminating exceptional behavior.

>> > 1) Fixity declarations usually look like this:
>> >   infixl 6 +, -
>> >but you can omit the precedence digit and write this instead:
>> >   infixl +, -
>> >
>> >[which is bad...]
>>
>> I don't think it's harder.  Even if the number is specified explicitly,
>> I would *still* have to look up the precedence table in the report,
>> or at least grep the source for the standard prelude, because
>> I don't know what the precedence of the other operators is.

I was surprised to learn that this kind of declaration is possible.  It's a
safe bet that most other people would be too.  Standard Haskell is supposed
to be Haskell 1.4, but streamlined.  If you can eliminate a rarely used
feature, I think you should.  If you can reduce the size of the grammar, I
think you should.

BTW, if I had seen this first in somebody else's source code rather than
here on the list, and it compiled, my first impulse would have been that
there must be a bug in the compiler that accepted it.  Then, after a few
seconds, I would maybe calm down, check the report... and send a message to
this list about it.

>> > 3) Empty contexts are not allowed.
>
>> Who would ever write them?
>>
>> Even for programs that generate Haskell code, it's trivial to handle
>> the empty context case differently.
>
>Probably not many people - but it's still a pointless exception
>and you have to remember to handle that empty case differently.

See below.

>> > 3) Contexts come in two flavours:
>> >  f :: Ord a => a -> a -> Bool
>> >and
>> >  f :: (Ord a, Bounded a) => a -> a -> Bool
>> >[and that's bad]
>>
>> I could live with that, but it might break a lot of existing code.

If I understand this correctly, you want to require the parentheses.  I
believe HBC's grammar needs (or needed---maybe it's fixed now) them, and I
remember when I was writing code for HBC that the extra two keystrokes were
not such a great burden.  If you are going to require this, I think you
should definitely allow #2 above also.

>> > 4) Module headers can be omitted.
>> >If the module leaves out the module header, the header
>> >   module Main(main) where
>> >is assumed.
>> >[and that's a mistake]
>>
>> Fix the compilers.  If there's no module header, the compiler should
>> not include the module name (Main) in the error messages.

What do you propose they should use in its stead?  "Type error in the module
formerly known as Main"?  ;)

>That's be nice AS WELL but why not simplify the report by removing
> pointless defaults.
>
>There's an argument going around that it must be possible teach Haskell
>without having to mention the word "module" in the first month.
>This argument is used to justify reexporting all kinds of rubbish
>from the Prelude (and is something I have argued against in the Standard
>Haskell discussion).

Larry Paulson has been lauded for introducing and using modules much earlier
in the second edition of his book "ML for the Working Programmer", and that
book is often used as an introduction to FP by beginners (despite the
title).  I agree that it is "cleaner" from the teacher's standpoint to avoid
mention of modules in the beginning, but so what?

Haskell is supposed to be a language suitable both for education and
programming in the large (PITL).  Fine.  But nobody said it had to be a
scripting language and, although I think functional languages are great for
that purpose, Haskell should not be both a scripting language and a language
for PITL at the same time.

Furthermore: a language suitable for scripting is not necessarily suitable
for education, nor vice versa.  Certainly no one would start off a bunch of
freshmen on Perl!  It seems to me that many of the syntactic oddities above
might be viewed as symptoms of conflating one with the other.  For example,
in a scripting language, it is desirable to have lots of defaults, etc. so
that there is as little time as possible between the time you start to write
a program and the time you get it running.  That's possible because
scripting languages are often targeted at one specific domain, and so you
can choose your defaults accordingly.  But Haskell is supposed to be a
general-purpose language, so default behavior is not much of a benefit.

If you want a functional scripting language with H-M type inference and type
classes and monads, that's great, but maybe it should be something separate
from Haskell.

--FC

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Simon Marlow]

Fergus Henderson <[EMAIL PROTECTED]> writes:

> On the Standard Haskell site,
> Alastair Reid wrote:
> > 
> > 1) Fixity declarations usually look like this:
> > 
> >   infixl 6 +, -
> > 
> >but you can omit the precedence digit and write this instead:
> > 
> >   infixl +, -
> > 
> >The programmer who uses this avoids having to type 2 characters.
> >The programmers who'sre reading this code has to learn that 
> >the precedence digit can be omitted (I didn't believe it when I
> >first saw it) and then look up the default precedence in the report.
> >I think it is harder to understand programs that use this shortcut
> >and that it should be removed.
> 
> I don't think it's harder.  Even if the number is specified explicitly,
> I would *still* have to look up the precedence table in the report,
> or at least grep the source for the standard prelude, because
> I don't know what the precedence of the other operators is.

I think you're missing the point.  Omitting the precedence digit is
important because it allows the programmer to avoid making a decision
about something he doesn't really care about.  Most of the time,
you're not interested in the relative precedence of `thenP` vs. (+),
since it doesn't make any sense to mix them.

If you really *want* a precedence of 9 (or whatever the default is),
one would never dream of leaving it out of the declaration.

ObStandardHaskellProposal: relax the restriction on precedences being
in the range 0-9.  Change the precedences of the Prelude operators
from n to n*100.

Cheers,
Simon

-- 
Simon Marlow [EMAIL PROTECTED]
University of Glasgow   http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Alastair Reid]

> I think you're missing the point.  Omitting the precedence digit is
> important because it allows the programmer to avoid making a decision
> about something he doesn't really care about.  Most of the time,
> you're not interested in the relative precedence of `thenP` vs. (+),
> since it doesn't make any sense to mix them.
> 
> If you really *want* a precedence of 9 (or whatever the default is),
> one would never dream of leaving it out of the declaration.
> 
> ObStandardHaskellProposal: relax the restriction on precedences being
> in the range 0-9.  Change the precedences of the Prelude operators
> from n to n*100.

A minor variation of which is to allow floating point numbers instead
so that you can always squeeze a new operator in between two existing
ones.

And a major variation (which gets to the root of your response) is
to replace the total order with a partial order.  I think Lennart
Augustsson suggested this a long time ago - are you there Lennart?


-- 
Alastair Reid  Yale Haskell Project Hacker
[EMAIL PROTECTED]  http://WWW.CS.Yale.EDU/homes/reid-alastair/

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Erik Meijer]

>If you want a functional scripting language with H-M type inference and
type
>classes and monads, that's great, but maybe it should be something separate
>from Haskell.


I have been promoting Haskell exactly for this purpose for some time now,
and I don't buy your points, e.g that

> in a scripting language, it is desirable to have lots of defaults, etc. so
> that there is as little time as possible between the time you start to
write
> a program and the time you get it running.

Scripting languages should optimize programmer's time,
by making the language small, simple, readable, type-safe, ..
I think that all of Alastair's points help reducing that.

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Fergus Henderson]

On the Standard Haskell site,
Alastair Reid wrote:
> One of the goals of Standard Haskell was to simplify the language
> - removing traps and making it easier to teach/learn.  We've seen
> very little work on this, so I'd like to make the following proposal:
> 
>   Let's remove all the little syntactic shortcuts which only save
>   a few characters but require you to understand something new
>   or to learn what the default is.
> 
> 1) Fixity declarations usually look like this:
> 
>   infixl 6 +, -
> 
>but you can omit the precedence digit and write this instead:
> 
>   infixl +, -
> 
>The programmer who uses this avoids having to type 2 characters.
>The programmers who'sre reading this code has to learn that 
>the precedence digit can be omitted (I didn't believe it when I
>first saw it) and then look up the default precedence in the report.
>I think it is harder to understand programs that use this shortcut
>and that it should be removed.

I don't think it's harder.  Even if the number is specified explicitly,
I would *still* have to look up the precedence table in the report,
or at least grep the source for the standard prelude, because
I don't know what the precedence of the other operators is.

> 2) Deriving lists come in two flavours:
> 
>  data ... deriving Eq
>  data ... deriving (Eq,Ord)
...
>I think we should eliminate the first style.

I could live with that.

> 3) Empty contexts are not allowed.
> 
>It's fine to write:
> 
>f :: (Ord a) => a -> a -> Bool
> 
>but you can't write:
> 
>f :: () => a -> a -> Bool
> 
>I think we should relax the syntax to allow empty contexts.

Who would ever write them?

Even for programs that generate Haskell code, it's trivial to handle
the empty context case differently.

> 3) Contexts come in two flavours:
> 
>  
>  f :: Ord a => a -> a -> Bool
> 
>and
> 
>  f :: (Ord a, Bounded a) => a -> a -> Bool
> 
>Again, we save 2 characters but then we have to explain both forms of
>syntax.  And, again, it's inconsistent to let you omit the parens in
>contexts but force you to put them in in import-export lists.
> 
>Change: delete one line from the grammar and half a sentence from 4.1.2.

I could live with that, but it might break a lot of existing code.

> 4) Module headers can be omitted.
> 
>If the module leaves out the module header, the header
> 
>   module Main(main) where
> 
>is assumed.
> 
>This saves 23 characters of typing (17 if you omit the export list, 14
>if you call the module A instead). When teaching Haskell, you still have
>to explain about modules because your Haskell compiler will refer to the
>module "Main" in error messages.

Fix the compilers.  If there's no module header, the compiler should
not include the module name (Main) in the error messages.

> 5) Lists of constructors can be empty in export lists but can't
>be empty in import lists.
...
>I think this is a simple typo.
> 
>Change: replace n>=1 with n>=0 in the grammar rule for import.

This one I support.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)

[Alastair Reid]

This is a reply to Fergus Henderson's comments on my proposal.

My answer to all his comments is that consistent languages are
easier to learn than languages littered with exceptions, special cases
and random default behaviour.

> > 1) Fixity declarations usually look like this:
> >   infixl 6 +, -
> >but you can omit the precedence digit and write this instead:
> >   infixl +, -
> > 
> >[which is bad...]
> 
> I don't think it's harder.  Even if the number is specified explicitly,
> I would *still* have to look up the precedence table in the report,
> or at least grep the source for the standard prelude, because
> I don't know what the precedence of the other operators is.

Grepping the Prelude won't tell you what the default precedence is
- so already the naive user is getting frustrated.  Then they remember
that their professor generously provided copies of tables 1 and 2 from the 
report (which summarise the precedence of various bits of syntax and
functions) along with a few other useful bits of info about Haskell.

But it's not there either - their professor didn't even know the precedence
digit was optional because they'd never seen it being used in any programs.
And besides, they don't want to list all the special cases in the Haskell
syntax - life is too short.

Then they grab a copy of their class textbook.  Not there either -
I guess the textbook writer didn't want to distract their readers with
that sort of unimportant nonsense.

So finally, they reach for the report and they find it.

Of course, I'd have reached for my copy of the report right away.
The naive user is very likely to try the easiest/shortest document first
and leave the Haskell report till last.

> > 3) Empty contexts are not allowed.

> Who would ever write them?
> 
> Even for programs that generate Haskell code, it's trivial to handle
> the empty context case differently.

Probably not many people - but it's still a pointless exception
and you have to remember to handle that empty case differently.

If I was writing a program that generated Haskell code, I might
well assume that empty contexts are allowed.  I might try my
system with one compiler and find that that particular compiler
relaxed this restriction.  I release it to the public, I get
a bug report saying that it doesn't work with compiler X,
I send a bug report to X-bugs@somewhere, they tell me it's the
correct behaviour, I ask them to fix it anyway, they say it's the
correct behaviour and they won't "break" their compiler just for me,
I fix my program and release a new version.

You can repeat this story with almost any exceptional case in the
syntax or the semantics.

> > 3) Contexts come in two flavours:
> >  f :: Ord a => a -> a -> Bool
> >and
> >  f :: (Ord a, Bounded a) => a -> a -> Bool
> >[and that's bad]
> 
> I could live with that, but it might break a lot of existing code.

Yes, my proposals will break a lot of code - but in a benign way:
the program will refuse to compile until you fix it.  The fix is
very obvious.  Once you've fixed it, it means the same as before.

For that matter, I doubt that implementers of existing compilers
would rush to remove clauses from their grammars (it's nigh-on
impossible to match the yacc/happy source with what the report
says so it's a brave man who deletes a syntax rule).

> > 4) Module headers can be omitted.
> >If the module leaves out the module header, the header
> >   module Main(main) where
> >is assumed.
> >[and that's a mistake]
> 
> Fix the compilers.  If there's no module header, the compiler should
> not include the module name (Main) in the error messages.

That's be nice AS WELL but why not simplify the report by removing
 pointless defaults.

There's an argument going around that it must be possible teach Haskell
without having to mention the word "module" in the first month.
This argument is used to justify reexporting all kinds of rubbish
from the Prelude (and is something I have argued against in the Standard 
Haskell discussion).

[I know Fergus didn't make this argument - but it is related and it
irritates me enough that I'll answer it anyway.]

I think this argument is complete nonsense.  When I was taught 
{C,Ada,Modula2,Modula3,AssemblyLanguage,etc}, the first complete
program I ever saw contained some variant of #include 
and I had absolutely no problem with it and I have never heard of
anyone having a problem with it.

I just picked up my copy of K&R to see how they deal with it.
K&R spends just 4 lines explaining the #include and is, IMHO,
completely clear.  In fact, they even take the opportunity to
point you towards the appendix which describes stdio.h.  
If I pick up a Haskell textbook, how many pages will I have to
read before I'm told that the Prelude is a collection of 
declarations just like the ones I've been typing myself
and that it's possible to get a complete list of what's in
the Prelude.


In summary: 

  I've caught a few exceptions