date:20151210

Re: arcanist-external-json-linter missing commits

2015-12-10 Thread Alan & Kim Zimmerman

I was advised to

git submodule update --init

and it did solve the problem

Alan

On Thu, Dec 10, 2015 at 11:48 PM, Edward Z. Yang  wrote:
> On a git submodule update on HEAD, I get:
>
> fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
> Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in 
> submodule path '.arc-linters/arcanist-external-json-linter'
>
> Edward
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: arcanist-external-json-linter missing commits

2015-12-10 Thread Edward Z. Yang

It does not, but I have discovered that the problem is related to
my git-new-workdir setup, so I think I'll just fix it myself.

(New submodule went into global .git but git-new-workdir can't deal
with that.)

Edward

Excerpts from Alan & Kim Zimmerman's message of 2015-12-10 13:50:25 -0800:
> I was advised to
> 
> git submodule update --init
> 
> and it did solve the problem
> 
> Alan
> 
> On Thu, Dec 10, 2015 at 11:48 PM, Edward Z. Yang  wrote:
> > On a git submodule update on HEAD, I get:
> >
> > fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
> > Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in 
> > submodule path '.arc-linters/arcanist-external-json-linter'
> >
> > Edward
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

arcanist-external-json-linter missing commits

2015-12-10 Thread Edward Z. Yang

On a git submodule update on HEAD, I get:

fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule 
path '.arc-linters/arcanist-external-json-linter'

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unused type variables with non-linear patterns

2015-12-10 Thread Michael Sloan

I definitely think this should be considered a usage.  Ideally, you should
always be able to resolve warnings, but there'd be no straightforward way
to do so if LHS-only usages cause warnings.  Also, It's quite useful to use
type variables only on the LHS.  Usage example:
https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar

-Michael

On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek 
wrote:

> An intersting thing came up when implementing warnings for unused type
> variables in type family
> patterns (#10982 / D1576):
>
> type family X a b where
>   X a a = Int
>
> Should we emit a warning that `a` is unused? It does not appear in the RHS
> but it is actually used
> because of non-linear pattern. We can fix this by prefixing both
> appearances of `a` with an
> underscore - this silences the warning and maintains semantics.
> Nevertheless, if a variable is
> unused it should be perfectly valid to replace it with an underscore -
> that is not the case in
> this example. Thoughts?
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -XStrict: Why some binders are not made strict?

2015-12-10 Thread Roman Cheplyaka

On 12/10/2015 04:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think about
> in the mean time: what do existing strict languages with pattern
> matching do?

Well, strict languages do not have lazy data to force to begin with, do they?

Personally, I find the simple intuition of "all patterns are strict by default" 
rather appealing.

E.g. I wouldn't expect the expressions

  let (v1,v2) = a in f v2

and

  let (v1,v2) = a; v3 = v2 in f v3

to have different semantics.

If we decide to adopt this semantics, we need to address the meaning of the 
pattern

  ~(v1, v2)

under -XStrict. Intuitively, ~ should propagate to the subpatterns. An 
alternative is to disallow this pattern under -XStrict and require writing all 
~s explicitly, which may get tedious:

  ~(~v1, ~v2)
  ~(~v1, ~(~v2, ~v3))
  etc.

We also need to ensure the consistency between this extension and the unlifted 
data types proposal [1], given their similarity. Interestingly, I don't see 
constructor patterns explained there either.

[1]: 
https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes

signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

type operators and colon in GHC

2015-12-10 Thread John Leo

I sent this to haskell-cafe a little while ago but didn't get a response,
so I thought I'd try here.  I'd guess this is a case of the GHC user guide
needing an update, but I'd like an expert opinion.

---

According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
you can define (7.4.3) an infix type constructor as long as it begins with
a colon, for example
data a :*: b = Foo a b

and furthermore (7.4.4) you can define an infix operator without having to
use a colon if you enable the TypeOperators extension:
data a * b = Foo a b

However if I try the former without using TypeOperators I get this compiler
error in 7.10.2:
Illegal declaration of a type or class operator ‘:*:’
  Use TypeOperators to declare operators in type and declarations

Using TypeOperators fixes this, but then * without colon also works so I
don't see the point of using colon anymore.

My guess is this was some some kind of historical distinction which is no
longer valid and the documentation needs to be updated.  Is this true, or
am I missing something?

John
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: type operators and colon in GHC

2015-12-10 Thread Alexey Vagarenko

This ticket might be relevant https://ghc.haskell.org/trac/ghc/ticket/11046

2015-12-10 20:51 GMT+05:00 John Leo :

> I sent this to haskell-cafe a little while ago but didn't get a response,
> so I thought I'd try here.  I'd guess this is a case of the GHC user guide
> needing an update, but I'd like an expert opinion.
>
> ---
>
> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
>
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
> you can define (7.4.3) an infix type constructor as long as it begins with
> a colon, for example
> data a :*: b = Foo a b
>
> and furthermore (7.4.4) you can define an infix operator without having to
> use a colon if you enable the TypeOperators extension:
> data a * b = Foo a b
>
> However if I try the former without using TypeOperators I get this
> compiler error in 7.10.2:
> Illegal declaration of a type or class operator ‘:*:’
>   Use TypeOperators to declare operators in type and declarations
>
> Using TypeOperators fixes this, but then * without colon also works so I
> don't see the point of using colon anymore.
>
> My guess is this was some some kind of historical distinction which is no
> longer valid and the documentation needs to be updated.  Is this true, or
> am I missing something?
>
> John
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: type operators and colon in GHC

2015-12-10 Thread John Leo

Thanks, that's helpful.  Sounds like the situation is even more complicated
than I realized.  It will be great if the documentation can be updated once
the behavior stabilizes.

John

On Thu, Dec 10, 2015 at 7:54 AM, Alexey Vagarenko 
wrote:

> This ticket might be relevant
> https://ghc.haskell.org/trac/ghc/ticket/11046
>
> 2015-12-10 20:51 GMT+05:00 John Leo :
>
>> I sent this to haskell-cafe a little while ago but didn't get a response,
>> so I thought I'd try here.  I'd guess this is a case of the GHC user guide
>> needing an update, but I'd like an expert opinion.
>>
>> ---
>>
>> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
>>
>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
>> you can define (7.4.3) an infix type constructor as long as it begins
>> with a colon, for example
>> data a :*: b = Foo a b
>>
>> and furthermore (7.4.4) you can define an infix operator without having
>> to use a colon if you enable the TypeOperators extension:
>> data a * b = Foo a b
>>
>> However if I try the former without using TypeOperators I get this
>> compiler error in 7.10.2:
>> Illegal declaration of a type or class operator ‘:*:’
>>   Use TypeOperators to declare operators in type and declarations
>>
>> Using TypeOperators fixes this, but then * without colon also works so I
>> don't see the point of using colon anymore.
>>
>> My guess is this was some some kind of historical distinction which is no
>> longer valid and the documentation needs to be updated.  Is this true, or
>> am I missing something?
>>
>> John
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Unused type variables with non-linear patterns

2015-12-10 Thread Jan Stolarek

An intersting thing came up when implementing warnings for unused type 
variables in type family 
patterns (#10982 / D1576):

type family X a b where
  X a a = Int 

Should we emit a warning that `a` is unused? It does not appear in the RHS but 
it is actually used 
because of non-linear pattern. We can fix this by prefixing both appearances of 
`a` with an 
underscore - this silences the warning and maintains semantics. Nevertheless, 
if a variable is 
unused it should be perfectly valid to replace it with an underscore - that is 
not the case in 
this example. Thoughts?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Does the Strict extension make monadic bindings strict?

2015-12-10 Thread Johan Tibell

I believe this is just a bug, since the desugaring ought to be strict in
the \x.

On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan 
wrote:

> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument will have a
> bang pattern. But then this code:
>
> do x <- ...
>return (x + 1)
>
> which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
> doesn't have the bang pattern in `x`.
>
> (See also a related email I sent to ghc-devs yesterday:
> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>
> 2015-12-08 12:27 GMT-05:00 David Kraeutmann :
> > While there's a fundamental difference between (>>=) and let-bindings, it
> > might be worth adding to the docs that -XStrict only makes let bindings
> > strict.
> >
> >
> > On 12/08/2015 06:22 PM, Rob Stewart wrote:
> >
> > Are the following two programs equivalent with respect to the strictness
> > of `readFile`?
> >
> > --8<---cut here---start->8---
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > main = do
> >   !contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > And:
> >
> > --8<---cut here---start->8---
> > {-# LANGAUGE Strict #-}
> >
> > module Main where
> >
> > main = do
> >   contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > The documentation on "Strict-by-default pattern bindings" gives
> > let/where binding as an example, but there is not a monadic bind example.
> >
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> >
> > Inspecting GHC Core for these two programs suggests that
> >
> > !contents <- readFile "foo.txt"
> >
> > is not equivalent to (with Strict enabled):
> >
> > contents <- readFile "foo.txt"
> >
> > Here's core using BangPatterns:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >case contents_asg of contents1_Xsk { __DEFAULT ->
> >print @ String $dShow_rYy contents1_Xsk
> >})
> >
> > Here's core using Strict:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >print @ String $dShow_rYv contents_asg)
> >
> > Does this core align with the design of the Strict extension?
> >
> > If it does, are users going to understand that using Strict is going to
> > make let/where bindings strict, but is not going to make <- or >>=
> > bindings strict?
> >
> > --
> > Rob Stewart
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Does the Strict extension make monadic bindings strict?

2015-12-10 Thread Adam Sandberg Eriksson

I agree that this seems to be a bug. I have a lot to do currently, but
might be able to look at it sometime during next week.

Adam Sandberg Eriksson


On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
> I believe this is just a bug, since the desugaring ought to be strict
> in the \x.
>
> On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan
>  wrote:
>> I think this is a problem/bug in the implementation. In the "function
>>
definitions" section of the wiki page it says the argument will have a
>>
bang pattern. But then this code:
>>
>>
do x <- ...
>>
return (x + 1)
>>
>>
which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
>>
doesn't have the bang pattern in `x`.
>>
>>
(See also a related email I sent to ghc-devs yesterday:
>> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>>
>>
2015-12-08 12:27 GMT-05:00 David Kraeutmann :
>>
> While there's a fundamental difference between (>>=) and let-
> bindings, it
>>
> might be worth adding to the docs that -XStrict only makes let
> bindings
>>
> strict.
>>
>
>>
>
>>
> On 12/08/2015 06:22 PM, Rob Stewart wrote:
>>
>
>>
> Are the following two programs equivalent with respect to the
> strictness
>>
> of `readFile`?
>>
>
>>
> --8<---cut here---start->8---
>>
> {-# LANGUAGE BangPatterns #-}
>>
>
>>
> module Main where
>>
>
>>
> main = do
>>
>!contents <- readFile "foo.txt"
>>
>print contents
>>
> --8<---cut here---end--->8---
>>
>
>>
> And:
>>
>
>>
> --8<---cut here---start->8---
>>
> {-# LANGAUGE Strict #-}
>>
>
>>
> module Main where
>>
>
>>
> main = do
>>
>contents <- readFile "foo.txt"
>>
>print contents
>>
> --8<---cut here---end--->8---
>>
>
>>
> The documentation on "Strict-by-default pattern bindings" gives
>>
> let/where binding as an example, but there is not a monadic bind
> example.
>>
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
>>
>
>>
> Inspecting GHC Core for these two programs suggests that
>>
>
>>
> !contents <- readFile "foo.txt"
>>
>
>>
> is not equivalent to (with Strict enabled):
>>
>
>>
> contents <- readFile "foo.txt"
>>
>
>>
> Here's core using BangPatterns:
>>
>
>>
> (readFile (unpackCString# "foo.txt"#))
>>
> (\ (contents_asg :: String) ->
>>
>case contents_asg of contents1_Xsk { __DEFAULT ->
>>
>print @ String $dShow_rYy contents1_Xsk
>>
>})
>>
>
>>
> Here's core using Strict:
>>
>
>>
> (readFile (unpackCString# "foo.txt"#))
>>
> (\ (contents_asg :: String) ->
>>
>print @ String $dShow_rYv contents_asg)
>>
>
>>
> Does this core align with the design of the Strict extension?
>>
>
>>
> If it does, are users going to understand that using Strict is
> going to
>>
> make let/where bindings strict, but is not going to make <- or >>=
>>
> bindings strict?
>>
>
>>
> --
>>
> Rob Stewart
>>
>
>>
>
>>
> ___
>>
> ghc-devs mailing list
>>
> ghc-devs@haskell.org
>>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>>
>
>>
>
>>
> ___
>>
> ghc-devs mailing list
>>
> ghc-devs@haskell.org
>>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>>
___
>>
ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _
> ghc-devs mailing list ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Does the Strict extension make monadic bindings strict?

2015-12-10 Thread Rob Stewart

In which case, I've created a ticket to record this bug and to track its
fix:

https://ghc.haskell.org/trac/ghc/ticket/11193

On 10 December 2015 at 15:26, Adam Sandberg Eriksson <
a...@sandbergericsson.se> wrote:

> I agree that this seems to be a bug. I have a lot to do currently, but
> might be able to look at it sometime during next week.
>
> Adam Sandberg Eriksson
>
>
> On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
>
> I believe this is just a bug, since the desugaring ought to be strict in
> the \x.
>
> On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan 
> wrote:
>
> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument will have a
> bang pattern. But then this code:
>
> do x <- ...
>return (x + 1)
>
> which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
> doesn't have the bang pattern in `x`.
>
> (See also a related email I sent to ghc-devs yesterday:
> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>
> 2015-12-08 12:27 GMT-05:00 David Kraeutmann :
> > While there's a fundamental difference between (>>=) and let-bindings, it
> > might be worth adding to the docs that -XStrict only makes let bindings
> > strict.
> >
> >
> > On 12/08/2015 06:22 PM, Rob Stewart wrote:
> >
> > Are the following two programs equivalent with respect to the strictness
> > of `readFile`?
> >
> > --8<---cut here---start->8---
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > main = do
> >   !contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > And:
> >
> > --8<---cut here---start->8---
> > {-# LANGAUGE Strict #-}
> >
> > module Main where
> >
> > main = do
> >   contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > The documentation on "Strict-by-default pattern bindings" gives
> > let/where binding as an example, but there is not a monadic bind example.
> >
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> >
> > Inspecting GHC Core for these two programs suggests that
> >
> > !contents <- readFile "foo.txt"
> >
> > is not equivalent to (with Strict enabled):
> >
> > contents <- readFile "foo.txt"
> >
> > Here's core using BangPatterns:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >case contents_asg of contents1_Xsk { __DEFAULT ->
> >print @ String $dShow_rYy contents1_Xsk
> >})
> >
> > Here's core using Strict:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >print @ String $dShow_rYv contents_asg)
> >
> > Does this core align with the design of the Strict extension?
> >
> > If it does, are users going to understand that using Strict is going to
> > make let/where bindings strict, but is not going to make <- or >>=
> > bindings strict?
> >
> > --
> > Rob Stewart
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> *___*
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -XStrict: Why some binders are not made strict?

2015-12-10 Thread Adam Sandberg Eriksson

When implementing I took this:

> Notice that we do not put bangs on nested patterns. For example  let
> (p,q) = if flob then (undefined, undefined) else (True, False)   in
> ... will behave like  let !(p,q) = if flob then (undefined, undefined)
> else (True, False)  in ...

(from the spec) and applied it to all bindings, but I don't know if this
is the best implementation.

Cheers, Adam


On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think
> about in the mean time: what do existing strict languages with pattern
> matching do?
>
> On Tue, Dec 8, 2015 at 3:42 PM, Simon Peyton Jones
>  wrote:
>> Adam, Johan,
>>
>>
Looking at the user manual
>> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell,
>>
and indeed the wiki page
>> https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>>
it's not really clear whether the sub-components of a pattern are
strict.  That is, is the second equation of zip strict in x, and xs?
(Supposing for now that the list data structure is lazy).  The manual
doesn't say one way or the other.
>>
>>
What's the answer?  And could the user manual please say?
>>
>>
Thanks
>>
>>
Simon
>>
>>
| -Original Message-
>>
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer
>>
| Sinan Agacan
>>
| Sent: 08 December 2015 01:41
>>
| To: ghc-devs 
>>
| Subject: -XStrict: Why some binders are not made strict?
>>
|
>>
| Let's say I have this code:
>>
|
>>
|zip :: [a] -> [b] -> [(a, b)]
>>
|zip [] [] = []
>>
|zip (x : xs) (y : ys) = (x, y) : zip xs ys
>>
|
>>
| With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm
| wondering
>>
| about
>>
| the motivation behind this, I found this interesting. I always
| thought -
>>
| XStrict
>>
| gives me this guarantee: If I'm using an already-defined
| variable(bound by
>>
| a
>>
| let or pattern matching) in an expression, I can be sure that the
| variable
>>
| won't be bottom in that expression, because it would be `seq`d
| before the
>>
| expression is evaluated.
>>
|
>>
| So if I have
>>
|
>>
|case ... of
>>
|D x y -> 
>>
|
>>
| or
>>
|
>>
|let x = ...
>>
|y = ...
>>
|in 
>>
|
>>
| In both cases I was thinking that in  'x' and 'y' can't be
>>
| bottom(with
>>
| -XStrict). This would make -XStrict programs evaluate like they
| would in a
>>
| call-by-value language(even though in the RTS level thunks will
| be built).
>>
| Variables can't range over computations; all binders evaluated
| strictly
>>
| etc.
>>
|
>>
| Can anyone tell me about the motivation behind this decision?
>>
|
>>
| I think the wiki page actually conflicts with itself. It says "...
>>
| bindings to be
>>
| strict by default" but then in "case expressions" sections says
>>
|
>>
|case x of (a,b) -> rhs
>>
|
>>
|is interpreted as
>>
|
>>
|case x of !(a,b) -> rhs
>>
|
>>
| Here bindings 'a' and 'b' are not made strict. I'd expect
| something like:
>>
|
>>
|case x of (!a,!b) -> rhs
>>
|
>>
| (Which seems to be invalid Haskell, but same effect could be
| achieved with
>>
| `seq
>>
| a (seq b rhs)`)
>>
|
>>
| Thanks..
>>
|
>>
| (I also realized that the wiki page doesn't mention bindings in
| do syntax,
>>
| is
>>
| it because this case is implied by "function definitions"? That
| is, bangs
>>
| are
>>
| added after do syntax is desugared and so they become strict?)
>>
| ___
>>
| ghc-devs mailing list
>>
| ghc-devs@haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
>>
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>
| devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbc68c0830f5-
| 74466efd
>>
| 308d2ff70aba9%7c72f988bf86f141af91ab2d7cd011db47%7c1=c2VBbt%-
| 2f%2fR2c
>>
| yFecGEuQotO%2bV71VSbpmWnZJyV9d8KRk%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: arcanist-external-json-linter missing commits

Re: arcanist-external-json-linter missing commits

arcanist-external-json-linter missing commits

Re: Unused type variables with non-linear patterns

Re: -XStrict: Why some binders are not made strict?

type operators and colon in GHC

Re: type operators and colon in GHC

Re: type operators and colon in GHC

Unused type variables with non-linear patterns

Re: Does the Strict extension make monadic bindings strict?

Re: Does the Strict extension make monadic bindings strict?

Re: Does the Strict extension make monadic bindings strict?

Re: -XStrict: Why some binders are not made strict?

13 matches

Site Navigation

Mail list logo

Footer information