apfelmus | 13 Jun 11:48 2007
Picon

inits is too strict

Hello,

  inits []     = [[]]
  inits (x:xs) = [[]] ++ map (x:) (inits xs)

as specified in Data.List has a "semantic bug", namely it's too strict:

  inits (1:_|_) = []:_|_

as opposed to the expected

  inits (1:_|_) = []:[1]:_|_

A correct version would be

  inits xs = []:case xs of
      []     -> []
      (x:xs) -> map (x:) (inits xs)

The Haskell report specifies how  inits  has to behave, so this is a
problem in the report, not in a concrete implementation. Where can I
report a bug report for the report? ;)

Regards,
apfelmus
Donald Bruce Stewart | 13 Jun 11:59 2007
Picon
Picon

Re: inits is too strict

apfelmus:
> Hello,
> 
>   inits []     = [[]]
>   inits (x:xs) = [[]] ++ map (x:) (inits xs)
> 
> as specified in Data.List has a "semantic bug", namely it's too strict:
> 
>   inits (1:_|_) = []:_|_
> 
> as opposed to the expected
> 
>   inits (1:_|_) = []:[1]:_|_
> 
> A correct version would be
> 
>   inits xs = []:case xs of
>       []     -> []
>       (x:xs) -> map (x:) (inits xs)
> 
> The Haskell report specifies how  inits  has to behave, so this is a
> problem in the report, not in a concrete implementation. Where can I
> report a bug report for the report? ;)
> 
> Regards,
> apfelmus

Well, right here. There are other strictness issues either differing
from the spec, or not clearly defined (foldl', for example). 

(Continue reading)

Stefan O'Rear | 13 Jun 15:54 2007
Picon
Picon

Re: inits is too strict

On Wed, Jun 13, 2007 at 11:48:18AM +0200, apfelmus wrote:
> Hello,
> 
>   inits []     = [[]]
>   inits (x:xs) = [[]] ++ map (x:) (inits xs)
> 
> as specified in Data.List has a "semantic bug", namely it's too strict:
> 
>   inits (1:_|_) = []:_|_
> 
> as opposed to the expected
> 
>   inits (1:_|_) = []:[1]:_|_
> 
> A correct version would be
> 
>   inits xs = []:case xs of
>       []     -> []
>       (x:xs) -> map (x:) (inits xs)
> 
> The Haskell report specifies how  inits  has to behave, so this is a
> problem in the report, not in a concrete implementation. Where can I
> report a bug report for the report? ;)

http://haskell.org/haskellwiki/Language_and_library_specification says:

The report still has minor bugs. There are tracked at the Haskell 98 bugs page. Report any new bugs to Malcolm Wallace.

Stefan
(Continue reading)

Isaac Dupree | 14 Jun 15:11 2007
Picon

What separates lines in Haskell code?


In the report, under the layout rule (section 9.3), "The characters
newline, return, linefeed, and formfeed, all start a new line."  (Which
four characters are those? from http://en.wikipedia.org/wiki/Linefeed ,
I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D",
"FF: Form Feed, U+000C", and what's the fourth one?  Newline usually
refers to '\n', which is LF, but linefeed has a direct name
correspondence to that also!)

The literate haskell section 9.4 just talks about lines without being
specific about how they're specified.  My proposed sample implementation
uses Prelude.lines ...

Prelude.lines presumes that lines are separated only by '\n'.

(Of course, for Prelude.unlines to be an inverse operation (which it's
not anyway) there has to be only one character that makes a line-separation)

Isaac
Antti-Juhani Kaijanaho | 14 Jun 15:21 2007
Picon

Re: What separates lines in Haskell code?

On Thu, Jun 14, 2007 at 09:11:12AM -0400, Isaac Dupree wrote:
> In the report, under the layout rule (section 9.3), "The characters
> newline, return, linefeed, and formfeed, all start a new line."  (Which
> four characters are those? from http://en.wikipedia.org/wiki/Linefeed ,
> I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D",
> "FF: Form Feed, U+000C", and what's the fourth one?  Newline usually
> refers to '\n', which is LF, but linefeed has a direct name
> correspondence to that also!)

The H98 lexical syntax defines newline as
  newline 	 -> 	 return linefeed | return | linefeed | formfeed

It could, I suppose, also refer to the Unicode character U+2028 LINE SEPARATOR,
but then probably U+2029 PARAGRAPH SEPARATOR ought to be included as well.

There are, BTW, Unicode guidelines for newline usage in section 5.8 of the
Unicode 5.0 online edition.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/
_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
apfelmus | 14 Jun 20:04 2007
Picon

Re: inits is too strict

> apfelmus:
>> Where can I report a bug report for the report? ;)

Stefan O'Rear wrote:
> http://haskell.org/haskellwiki/Language_and_library_specification
> says:
>
> The report still has minor bugs. There are tracked at the Haskell 98
> bugs page. Report any new bugs to Malcolm Wallace.

Donald Bruce Stewart wrote:
> Well, right here. There are other strictness issues either differing
> from the spec, or not clearly defined (foldl', for example). 

Ah. Actually, I thought that there's something like a bug-tracker for
the standardized libraries. I wouldn't change inits in the existing H98
standard, it's not really worth the hassle. But I'd change it to the
lazy version for Haskell'.

> A useful tool for checking these is the StrictCheck/ChasingBottoms
> library, QuickCheck for partial values, by the way.

Oh, really useful :)

Regards,
apfelmus
Isaac Dupree | 16 Jun 20:28 2007
Picon

"qvars"? pragma syntax generally?


For INLINE and NOINLINE the report uses "qvars"
http://haskell.org/onlinereport/pragmas.html
which is not defined in http://haskell.org/onlinereport/syntax-iso.html
(although its meaning is obvious since var, qvar and vars are all defined).

Is it permissible for compilers to die on pragma syntax they don't
personally like? For example GHC chokes on {-# INLINE Ma-in.ma-in #-} at
top level, but it would be worse with non-standardized pragmas. (the
compiler giving a warning that it understands a pragma of that name, but
not the syntax given, would be best.)  "the pragma should be ignored if
an implementation is not prepared to handle it."

WHAT IS pragma syntax?? The report doesn't say how whitespace is
handled.  syntax-iso doesn't mention pragmas; in its opinion everything
from {-# hi-} to {-#{-##-}#-} to {-# INLINE main #-} is a perfectly good
comment.  [1]  But the report recommends some specific syntaxes.  To all
appearances, it is expected that they follow (guessing from other
Haskell syntax) the form

pragma -> {-#    pragmaid    (some pragma-specific syntax that is
consistent with the whole thing being ncomment)    #-}
pragmaid -> (large|_) {large|_|'}

Still... whitespace? GHC understands as a pragma

{-#

LINE 3 "foo.hs" #-}

(Continue reading)

Isaac Dupree | 17 Jun 19:36 2007
Picon

Re: What separates lines in Haskell code?


Antti-Juhani Kaijanaho wrote:
> On Thu, Jun 14, 2007 at 09:11:12AM -0400, Isaac Dupree wrote:
>> In the report, under the layout rule (section 9.3), "The characters
>> newline, return, linefeed, and formfeed, all start a new line."  (Which
>> four characters are those? from http://en.wikipedia.org/wiki/Linefeed ,
>> I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D",
>> "FF: Form Feed, U+000C", and what's the fourth one?  Newline usually
>> refers to '\n', which is LF, but linefeed has a direct name
>> correspondence to that also!)
> 
> The H98 lexical syntax defines newline as
>   newline 	 -> 	 return linefeed | return | linefeed | formfeed
> 
> It could, I suppose, also refer to the Unicode character U+2028 LINE SEPARATOR,
> but then probably U+2029 PARAGRAPH SEPARATOR ought to be included as well.
> 
> There are, BTW, Unicode guidelines for newline usage in section 5.8 of the
> Unicode 5.0 online edition.

http://www.unicode.org/versions/Unicode5.0.0/ch05.pdf#G10213

Alright, I think the comment in the layout-rule section should not try
to enumerate newlines, but rather should refer back to the lexical
definition of 'newline'.

As per the above Unicode guideline, the existing set of characters that
Haskell98 accepts as newlines, and a section of the Unicode regex
guidelines <http://unicode.org/reports/tr18/>, I propose all should be
accepted as line separators:
(Continue reading)

Isaac Dupree | 18 Jun 13:17 2007
Picon

type signatures in export lists


They're not implemented, but they won't be until we decide exactly what
they mean - it's not simple.

(at least the syntax is obvious:
http://hackage.haskell.org/trac/haskell-prime/wiki/PermitSignaturesInExports
)

One big question: can their presence have any effect?
* on the module doing the exporting (conflict with the presence of
in-module type-signature for the same thing; type restriction in-module;
monomorphism-restriction-lifting or defaulting-removal of the named thing)
* on modules importing this one (can a module re-export something,
giving it a more restrictive type-signature?)

Case study 1:

module Foo1 (Foo(..), foo :: Foo) where

data Foo = CFoo

foo :: Foo
foo = CFoo

If we interpret it as an in-module type signature, it will be a problem
because there already is one for foo. (unless we should relax the rules
for uniqueness of type signatures anyway?)

Case study 2:

(Continue reading)

Arie Peterson | 18 Jun 16:00 2007
Picon
Picon

Re: type signatures in export lists

Isaac Dupree wrote:

> One big question: can their presence have any effect?
> * on the module doing the exporting (conflict with the presence of
> in-module type-signature for the same thing; type restriction in-module;
> monomorphism-restriction-lifting or defaulting-removal of the named thing)
> * on modules importing this one (can a module re-export something,
> giving it a more restrictive type-signature?)

Letting an export-list type signature be equivalent to a normal one has
the benefit of being simple (to explain and implement). Exporting a
function with a less polymorphic type than its in-module type seems a bit
awkward: you would have two different functions (one internal and one
exported) with the same name.

If export-list and normal type signatures would be equivalent, the only
benefit of allowing the former (compared to writing it in a comment) would
be that the compiler can check it for consistency. Right?

> The type doesn't need to be exported. (which is more likely if it's just
> a type synonym than a new type.)  So what scope are the names in the
> export-list-type-signature drawn from?  It would be odd if a type
> signature couldn't be given because some names weren't exported; but it
> would be odd if a module-user looking at the interface saw some types
> that weren't defined anywhere visible.

As a user of the module, I would argue that all types (including synonyms)
appearing in the signature of an exported function should be exported as
well. Not sure if this needs to be enforced, though.

(Continue reading)


Gmane