RE: A question about run-time errors when class members are undefined

[Simon Peyton Jones via Haskell-prime]

Anthony

You may be interested in Carlos Camarao’s interesting work.  For a long time 
now he has advocated (in effect) making each function into its own type class, 
rather that grouping them into classes.   Perhaps that is in line with your 
thinking.
https://homepages.dcc.ufmg.br/~camarao/

Simon

From: Haskell-prime  On Behalf Of Anthony 
Clayden
Sent: 06 October 2018 04:19
To: Petr Pudlák 
Cc: haskell-prime@haskell.org
Subject: Re: A question about run-time errors when class members are undefined


On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák 
mailto:redir...@vodafone.co.nz>> wrote:

IIRC one of the arguments against having many separate classes is that a class 
is not a just set of methods, it's also the relations between them,

Hi Petr, I was talking about splitting out Haskell's current class hierarchy as 
a step towards doing away with classes altogether. If your language insists on 
methods being held in classes, that's just tedious bureacracy to invent class 
names.

The relations between classes (including between single-method classes) can be 
captured through superclass constraints. For example, in the Haskell 2010 report

class (Eq a, Show a) => Num a where ...

such as the important laws between `return` and `>>=`. And then for example a 
class with just `return` doesn't give any information what `return x` means or 
what should be its properties.

Then make Bind a superclass constraint on `return` (or vice versa, or both 
ways).

Just as the laws for Num's methods are defined in terms of equality

x + negate x == fromInteger 0  -- for example

Talking about laws is a red herring: you can't declare the laws/the compiler 
doesn't enforce them or rely on them in any way. Indeed the Lensaholics seem to 
take pleasure in building lenses that break the (van Laarhoven) laws.



That said, one of really painful points of Haskell is that refactoring a 
hierarchy of type-classes means breaking all the code that implements them. 
This was also one of the main reasons why reason making Applicative a 
superclass of Monad took so long. It'd be much nicer to design type-classes in 
such a way that an implementation doesn't have to really care about the exact 
hierarchy.

Yes that's what I was saying. Unfortunately for Haskell's Num class, I think 
it's just too hard. So a new language has an opportunity to avoid that. If OTOH 
Helium wants to slavishly follow Haskell, I'm wondering what is the point of 
Helium.

With Applicative, IIRC, refactoring had to wait until we got Constraint kinds 
and type families that could produce them. Would Helium want to put all that 
into a language aimed at beginners?


 For example, in Haskell we could have

class (Return m, Bind m) => Monad m where

without any methods specified. But instances of `Monad` should be only such 
types for which `return` and `>>=` satisfy the monad laws.

First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's 
Prelude documentation state a bunch of laws; and it's a good discipline to 
write down laws if you're creating a class; but it's only documentation. 
Arguably IO, the most commonly used Monad, breaks the Monad laws in rather 
serious ways because it imposes sequence of execution; and it would be unfit 
for purpose if it were pure/lazy function application.

Then: what do you think a language could do to detect if some instance 
satisfies the laws? (Even supposing you could declare them.)


And this would distinguish them from types that have both `Return` and `Bind` 
instances, but don't satisfy the laws.

You could have distinct classes/distinct operators. Oh, but then `do` dotation 
would break.


Unfortunately I'm not sure if there is a good solution for achieving both these 
directions.

I don't think there's any solution for achieving "satisfy the xxx laws".


AntC


čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden 
mailto:anthony_clay...@clear.net.nz>> napsal:
> We are adding classes and instances to Helium.

> We wondered about the aspect that it is allowed to have a class instance

> of which not all fields have a piece of code/value associated with them, ...



I have a suggestion for that. But first let me understand where you're going 
with Helium. Are you aiming to slavishly reproduce Haskell's classes/instances, 
or is this a chance for a rethink?



Will you want to include associated types and associated datatypes in the 
classes? Note those are just syntactic sugar for top-level type families and 
data families. It does aid readability to put them within the class.



I would certainly rethink the current grouping of methods into classes. Number 
purists have long wanted to split class Num into Additive vs Multiplicative. 
(Additive would be a superclass of Multiplicative.) For the Naturals perhaps we 
want Presburger arithmetic then Additive just contains (+), with `negate` 
certainly in a different class, perhaps (-) subtract als

Re: A question about run-time errors when class members are undefined

[Ben Franksen]

Am 08.10.2018 um 11:21 schrieb Anthony Clayden:
> I wonder how different would have been the history of Haskell if Wadler had
> not borrowed the terminology "class" and "method". Since Helium has a focus
> on Haskell learners/beginners: I wonder how much confusion we might have
> saved those coming from OOP where the terms mean something really quite
> different. We might have avoided "class" altogether; and talked of
> "overloaded function".

Similar to C++, perhaps?

Cheers
Ben

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[Ben Franksen]

Am 06.10.2018 um 05:18 schrieb Anthony Clayden:
> On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák  wrote:
> such as the important laws between `return` and `>>=`. And then for example
>> a class with just `return` doesn't give any information what `return x`
>> means or what should be its properties.
>>
> 
> Then make Bind a superclass constraint on `return` (or vice versa, or both
> ways).
> 
> Just as the laws for Num's methods are defined in terms of equality
> 
> x + negate x == fromInteger 0  -- for example
> 
> Talking about laws is a red herring: you can't declare the laws/the
> compiler doesn't enforce them or rely on them in any way. Indeed the
> Lensaholics seem to take pleasure in building lenses that break the (van
> Laarhoven) laws.

I strongly disagree with this. Class laws are absolutely essential. They
are the main distinguishing feature of Haskell classes versus the usual
ad-hoc overloading found in most mainstream (e.g. OO) languages. Using
'+' for string concatenation? That's just a poor work-around for
languages that only support a fixed set of traditional operators. And if
you have a Monoid or Semigroup class that doesn't require or even
suggest commutativity of the operator, but clearly states that
associativity is required, then I see absolutely no reason to use '+'
for that.

That the compiler can't enforce the laws is irrelevant. Laws are a
contract and violating it is a bug. Non law-abiding lenses like
'filtered' are clearly documented with severe warnings attached. To cite
them as proof that people take pleasure in violating class laws is
ridiculous.

Granted, classes that combine multiple methods are not /required/ to
state laws. But they offer a convenient place where to put them.

>  For example, in Haskell we could have
>>
>> class (Return m, Bind m) => Monad m where
>>
>> without any methods specified. But instances of `Monad` should be only
>> such types for which `return` and `>>=` satisfy the monad laws.
>>
> 
> First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's
> Prelude documentation state a bunch of laws; and it's a good discipline to
> write down laws if you're creating a class; but it's only documentation.

Why you say "only"? Documentation is essential and documentation in the
form of laws (properties) is the most useful sort of documentation. And
many class laws (though not all) /can/ be formally expressed as Haskell
code and thus tested with e.g. quickcheck.

> Arguably IO, the most commonly used Monad, breaks the Monad laws in rather
> serious ways because it imposes sequence of execution;

I think such a bold statement should be accompanied by an example that
demonstrates it.

Cheers
Ben

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

Thank you Carlos, but oh dear

this is fast becoming as exasperating as the github rounds.

We've been talking about modular/scoped instances.
All of a sudden you've introduced MPTCs, which nobody even mentioned.
And you have a definition of "reachable" which is not GHC's definition:
'"reachable" is a conservative approximation to "functionally dependent".'
https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/other-type-extensions.html
(That's from an old version of the User's Guide. It works as an
approximation because it assumes a) Functional Dependencies are declared;
b) all methods observe the FunDeps declared for their class; c) all
instances are consistence with the FunDeps. These days GHC has a
better-structured approach, which SPJ explained in his comment on github
last year.)

Are your 1. and 2. below orthogonal? [Good] Then discuss them orthogonally.
Does one build on the other? [Good] Then discuss the logically first one
first.
Does each have independent motivations, and then it's the combination of
them that gives a quantum leap in expressivity? [Maybe good] Then discuss
them independently at first. (Maybe two distinct proposals?)
Are they all tangled together in a mess? [Not good] Then please try to
untangle them before presenting a proposal.

Carter is right, and I take the point.
Haskell-prime is for considering changes to the language standard.
It expects any proposal to be already well-established and stable in at
least one version of Haskell. [**]
The place to discuss 'speculative' proposals is nowadays github.
Even on github, it would strengthen a proposal's appeal if there's an
already-developed prototype, possibly not in Haskell but some related
language. Proofs of useful properties (like Principal typing) add to the
appeal, but are not strongly persuasive without lots of use cases.

> Comments, corrections etc. are welcome. If the ideas are welcome or lead
to a related welcome proposal, ...

Possibly the place to try to clarify the ideas is the cafe. Or maybe if
it's leading towards a proposal, a github 'Issue' rather than 'Pull
request'. (That has the advantage of a more permanent record, and more
markup/formatting than email without being as awkward to format as rst.)

[**] You'd expect by the 'well-established' criterion, MPTCs would be a
strong candidate for considering in Haskell-prime: already anticipated in
1988; two implementations, each from nearly 20 years ago, stable since
about 2006. But there's a whole swirl of difficulties around them, which I
tried to summarise here
https://mail.haskell.org/pipermail/haskell-prime/2018-October/004367.html
It's not exactly MPTCs, but how they interact with other typeclass/instance
features.

In none of the discussion on those github rounds did Carlos/Rodrigo seem to
be aware of those difficulties -- which are well-known and well-documented.

Then to come back to the issue of modular/scoped instances -- i.e. the
infamous 'orphan instances'. For the record [***] let's explain Carter's

>> local scoping for type classes is flat out not gonna happen in the haskell
language standard any time soon.

A. local scoping breaks referential transparency.
   I can't replace a function by its definition, and get the same behaviour.
B. local scoping breaks parametricity.
   The behaviour of a function depends not only on its arguments (value and
type)
   but also on some invisible typing baked into the function from what was
in scope at its definition site.

Referential transparency and Parametricity are powerful, simple principles
for reasoning about programs.
Anything that breaks them is immediately not "simple" IMO.

C. local scoping also breaks something related; I'm not sure if there's a
technical term: 'transparency of type improvement'?
   What gets baked in is an instance selection that includes type
improvement.
   So even if I replace a function by its definition, **and** give it
exactly the type signature from its definition site,
   I still get different behaviour -- specifically different type
improvement.

With C. we threaten type soundness: the compiler would be entitled to use
either of the definition site's type improvement or the usage site's or
both. And then infer different types for the same expression. And then get
a segfault in the executable. If Carlos/team haven't experienced that yet
in their prototypes, that's down to pure luck and GHC being so
well-structured. (I'd guess GHC would catch it at the core lint typecheck,
as a last resort.) The threat to soundness is Edward K's concern here
https://mail.haskell.org/pipermail/haskell-prime/2018-April/004358.html



[***] I say "for the record", partly to give a heads up to Juriaan, who
started this thread, for educational/learning purposes;
and partly because it's surprising how often 'local instances' come up on
Haskell-prime. Where too often = more than never.


AntC


On Sat, 13 Oct 2018 at 4:04 AM,  wrote:

> Hi.
>
> A concise proposal for the introduction of MPTCs 

Re: A question about run-time errors when class members are undefined

[camarao]

Hi.

A concise proposal for the introduction of MPTCs in Haskell follows.
A similar ghc-proposal has been written before, but without success
(certainly it would be better if some experimentation in ghc was done
first, as Carter suggested). The proposal is based essentially on the
following (1. crucial, 2. desirable):

   1. Change the ambiguty rule.

  Consider for example:

  class F a b where f:: a → b
  class X a   where x:: a
  fx = f x

  The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in
  distinct contexts, fx can have distinct types (if ambiguity, and
  'improvement', are as defined below). Note: agreeing with this
  view can lead to far-reaching consequences, e.g. support of
  overloaded record fields [1,Section 7], polymonads [2] etc.

  Further examples can be discussed but this example conveys the
  main idea that ambiguity should be changed; unlike the example
  of (show . read), no type annotation can avoid ambiguity of
  polymorphic fx in current Haskell.

  Ambiguity should be a property of an expression, defined as
  follows: if a constraint set C on the constrained type C∪D⇒t of
  an expression has unreachable variables, then satisfiability is
  tested for C (a definition of reachable and unreachable type
  variables is at the end of this message), and:

   - if there is a single unifying substitution of C with the set
 of instances in the current context (module), then C can be
 removed (overloading is resolved) and C∪D⇒t 'improved' to
 D⇒t;

   - otherwise there is a type error: ambiguity if there are two
 or more unifying substitutions of C with the set of instances
 in the current context (module), and unsatisfiability
 otherwise.

  2. Allow instances to be imported (all instances are assumed to be
 exported):

   import M (instance A τ₁ ⋯ τₙ , … )

  specifies that the instance of τ₁ ⋯ τₙ for class A is
  imported from M, in the module where the import clause
  occurs.

  In case of no explicit importation, all instances remain
  imported, as currently in Haskell (in order that well-typed
  programs remain well-typed).

Comments, corrections etc. are welcome. If the ideas are welcome or
lead to a related welcome proposal, then a detailed one, with changes
to the Haskell report, can be worked out.

(Definition: [Reachable and unreachable type variables in constraints]
Consider a constrainted type C∪D⇒τ. A variable a ∈ tv(C) is reachable
from V = tv(τ) if a ∈ V or if a ∈ tv(π) for some π ∈ C such that there
exists b ∈ tv(π) such that b is reachable from V; otherwise it is
unreachable.
For example, in (F a b, X a) ⇒ b, type variable 'a' is reachable from
{ b }, because 'a' occurs in constraint F a b, and b is reachable.
Similarly, if C = (F a b, G b c, X c), then c is reachable from {a}.)

Kind regards,

Carlos

[1]  Optional Type Classes for Haskell,
 Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano 
Vasconcellos,

 SBLP'2016 (20th Brazilian Symposium on Programming Languages),
 Marília, SP, September 19-23, 2016.

[2]  
https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0724bb76164b418866b/expression-ambiguity.rst


===
Em 2018-10-10 22:16, Anthony Clayden escreveu:

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones  wrote


You may be interested in Carlos Camarao’s interesting work.  For a
long time now he has advocated (in effect) making each function into
its own type class, rather that grouping them into classes.
Perhaps that is in line with your thinking.






Could I ask Simon direct, since it was he who introduced the topic.
When you say "interesting work", what is that evaluation based on? Is
there a paper or summary you've seen that expresses the ideas?
(Because despite the exhaustive and exhausting rounds on github last
year, and further comment on this thread, I just can't see anything
workable. And the papers that Carlos references ring alarm bells for
me, just looking at the Abstracts, let alone delving into the
impenetrable type theory.)

And could I ask Carlos: are we allowed to know who peer-reviewed your
papers? Specifically, was it someone who's up with the state of the
art in GHC?

Carlos/his team are making bold claims: to provide the functionality
of FunDeps/Type functions, Overlapping Instances/Closed Type Families,
to avoid the infamous `read . show` ambiguity, to avoid the equally
infamous 'orphan instances' incoherence, to preserve principal typing,
and to keep it "simple".

Then I have to say that if there's evidence for those claims, it's not
appearing in the papers. Really the only example presented is `read .
show` (plus record field disambiguation). Yes I'd hope the approach
for a simple example is "simple". It doesn't seem any more simple than
putting an explicit type signature (or we could use type 

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones  wrote

You may be interested in Carlos Camarao’s interesting work.  For a long
> time now he has advocated (in effect) making each function into its own
> type class, rather that grouping them into classes.   Perhaps that is in
> line with your thinking.
>

Could I ask Simon direct, since it was he who introduced the topic. When
you say "interesting work", what is that evaluation based on? Is there a
paper or summary you've seen that expresses the ideas? (Because despite the
exhaustive and exhausting rounds on github last year, and further comment
on this thread, I just can't see anything workable. And the papers that
Carlos references ring alarm bells for me, just looking at the Abstracts,
let alone delving into the impenetrable type theory.)

And could I ask Carlos: are we allowed to know who peer-reviewed your
papers? Specifically, was it someone who's up with the state of the art in
GHC?

Carlos/his team are making bold claims: to provide the functionality of
FunDeps/Type functions, Overlapping Instances/Closed Type Families, to
avoid the infamous `read . show` ambiguity, to avoid the equally infamous
'orphan instances' incoherence, to preserve principal typing, and to keep
it "simple".

Then I have to say that if there's evidence for those claims, it's not
appearing in the papers. Really the only example presented is `read . show`
(plus record field disambiguation). Yes I'd hope the approach for a simple
example is "simple". It doesn't seem any more simple than putting an
explicit type signature (or we could use type application `@` these days).
But I don't expect that would be the place to show off the
power/expressivity.


Thank you
AntC
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[Carter Schonwald]

ok, cool! I'm not sure what modular scoping would look like, but it'd be
fun what that looks like!

I do think that the prime list isn't the best list though for figuring that
out / experimentations thereof :)

On Wed, Oct 10, 2018 at 1:36 PM  wrote:

> Hi Carter,
>
> I am not proposing "local scoping". I think local scoping
> does not have substantial gains and at least introduces
> some difficulties and complexity (I have tried it in system CT).
>
> Even modular scope for instances is not mandatory, as I said.
> A general defaulting rule is a remedy, if instance modular scope is not
> supported, for changing the ambiguity rule
> (I prefer modular instance scoping though).
>
> I don't want to fight for anything. I'd like to contribute
> if the Haskell community friendly wishes me to do so in order to
> introduce MPTCs in a relatively simple way, without the need of extra
> mechanisms, based essentially on changing the ambiguity rule:
> I think a type like, say, (F a b, X a) => b is not ambiguous
> (F and X being classes with members f:: a->b and x::a, say),
> since then overloading of (f x) can be resolved, with a new
> ambiguity rule, depending on the context (or type) where (f x) is used.
>
> Kind regards,
>
> Carlos
>
> Em 2018-10-10 12:52, Carter Schonwald escreveu:
> > Carlos, local scoping for type classes is flat out not gonna happen in
> > the haskell language standard any time soon.
> >
> > if you want to make a case for it, demonstrate its utility, this
> > mailing list isn't for that. Especially for something that
> > fundamentally changes the programming model of the language in
> > question in a way that isn't compatible
> >
> > merry adventures!
> > -Carter
> >
> > On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao
> >  wrote:
> >
> >> Hi.
> >>
> >>> Thanks Carlos. I wish I could say thank you for clarifying, but
> >> I'm
> >>> afraid this is as muddled as all the comments on the two
> >> proposals.
> >>>
> >>> I don't want to go over it again. I just want to say that my
> >>> suggestion earlier in the thread is fundamentally different.
> >>>
> >>>> Global instance scope is not ok either: instances should be
> >> modular.
> >>> I just plain disagree. Fundamentally.
> >>
> >> Global instance scope is not required for principal typing: a
> >> principal type is (just) a type of an expression in a given typing
> >> context that has all other types of this expression in that typing
> >> context as instances.
> >>
> >> (Also: instance modularity is not the central issue.)
> >>
> >>>>> Wadler & Blott's 1988 paper last paragraph had already
> >> explained: "But
> >>>>> there is no principal type! "
> >>
> >>>> There is always a principal type, for every expression.
> >>>> Of course the type depends on the context where the
> >> expression occurs.
> >>
> >>> Then it's not a _principal_ type for the expression, it's just a
> >> local type.
> >>> http://foldoc.org/principal
> >>
> >> A type system has the principal type property if, given a
> >> term and a typing context, there exists a type for this term in this
> >> typing context such that all other types for this term in this
> >> typing
> >> context are an instance of this type.
> >>
> >>> We arrive at the principal type by unifying the principal types of
> >>> the sub-expressions, down to the principal types of each atom. W
> >>> are pointing out that without global scope for instances, typing
> >>> cannot assign a principal type to each method. (They left that as
> >> an
> >>> open problem at the end of the paper. Haskell has resolved that
> >>> problem by making all instances global. Changing Haskell to
> >> modular
> >>> instances would be a breakage. Fundamentally.)
> >>>
> >>> Under my suggestion, we can assign a (global) principal type to
> >> each
> >>> method -- indeed you must, by giving a signature very similar to a
> >>> class declaration; and that distinguishes overloaded functions
> >> from
> >>> parametric polymorphic functions.
> >>
> >> A principal type theorem has been proved: see, for example, Theorem
> >> 1 in [1].
> >>
> >> Kind regards,
> >>
> >> Carlos
> >>
> >> [1]

Re: A question about run-time errors when class members are undefined

[camarao]

Hi Carter,

I am not proposing "local scoping". I think local scoping
does not have substantial gains and at least introduces
some difficulties and complexity (I have tried it in system CT).

Even modular scope for instances is not mandatory, as I said.
A general defaulting rule is a remedy, if instance modular scope is not 
supported, for changing the ambiguity rule

(I prefer modular instance scoping though).

I don't want to fight for anything. I'd like to contribute
if the Haskell community friendly wishes me to do so in order to 
introduce MPTCs in a relatively simple way, without the need of extra 
mechanisms, based essentially on changing the ambiguity rule:

I think a type like, say, (F a b, X a) => b is not ambiguous
(F and X being classes with members f:: a->b and x::a, say),
since then overloading of (f x) can be resolved, with a new
ambiguity rule, depending on the context (or type) where (f x) is used.

Kind regards,

Carlos

Em 2018-10-10 12:52, Carter Schonwald escreveu:

Carlos, local scoping for type classes is flat out not gonna happen in
the haskell language standard any time soon.

if you want to make a case for it, demonstrate its utility, this
mailing list isn't for that. Especially for something that
fundamentally changes the programming model of the language in
question in a way that isn't compatible

merry adventures!
-Carter

On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao
 wrote:


Hi.


Thanks Carlos. I wish I could say thank you for clarifying, but

I'm

afraid this is as muddled as all the comments on the two

proposals.


I don't want to go over it again. I just want to say that my
suggestion earlier in the thread is fundamentally different.


Global instance scope is not ok either: instances should be

modular.

I just plain disagree. Fundamentally.


Global instance scope is not required for principal typing: a
principal type is (just) a type of an expression in a given typing
context that has all other types of this expression in that typing
context as instances.

(Also: instance modularity is not the central issue.)


Wadler & Blott's 1988 paper last paragraph had already

explained: "But

there is no principal type! "



There is always a principal type, for every expression.
Of course the type depends on the context where the

expression occurs.


Then it's not a _principal_ type for the expression, it's just a

local type.

http://foldoc.org/principal


A type system has the principal type property if, given a
term and a typing context, there exists a type for this term in this
typing context such that all other types for this term in this
typing
context are an instance of this type.


We arrive at the principal type by unifying the principal types of
the sub-expressions, down to the principal types of each atom. W
are pointing out that without global scope for instances, typing
cannot assign a principal type to each method. (They left that as

an

open problem at the end of the paper. Haskell has resolved that
problem by making all instances global. Changing Haskell to

modular

instances would be a breakage. Fundamentally.)

Under my suggestion, we can assign a (global) principal type to

each

method -- indeed you must, by giving a signature very similar to a
class declaration; and that distinguishes overloaded functions

from

parametric polymorphic functions.


A principal type theorem has been proved: see, for example, Theorem
1 in [1].

Kind regards,

Carlos

[1] Ambiguity and Constrained Polymorphism,
Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro,
Science of Computer Programming 124(1), 1--19, August 2016.

On Mon, 8 Oct 2018 at 20:03, Anthony Clayden
 wrote:

On Tue, 9 Oct 2018 at 7:30 AM,  wrote:

Thanks Carlos. I wish I could say thank you for clarifying, but I'm
afraid this is as muddled as all the comments on the two proposals.

I don't want to go over it again. I just want to say that my
suggestion earlier in the thread is fundamentally different.

Em 2018-10-08 06:21, Anthony Clayden escreveu:

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:



Strange: Simon's message has not appeared on the forum (he did send
to it). I've quoted it in full in my reply, but did break it into
separate pieces.

Global instance scope is not ok either: instances should be modular.

I just plain disagree. Fundamentally.



Wadler & Blott's 1988 paper last paragraph had already explained:

"But

there is no principal type! "


There is always a principal type, for every expression.
Of course the type depends on the context where the expression
occurs.

Then it's not a _principal_ type for the expression, it's just a
local type.

http://foldoc.org/principal

We arrive at the principal type by unifying the principal types of
the sub-expressions, down to the principal types of each atom. W
are pointing out that without global scope for instances, typing
cannot assign a principal type to each method. (They left tha

Re: A question about run-time errors when class members are undefined

[Carter Schonwald]

Carlos, local scoping for type classes is flat out not gonna happen in the
haskell language standard any time soon.

if you want to make a case for it, demonstrate its utility, this mailing
list isn't for that. Especially for something that fundamentally changes
the programming model of the language in question in a way that isn't
compatible

merry adventures!
-Carter

On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao 
wrote:

> Hi.
>
> > Thanks Carlos. I wish I could say thank you for clarifying, but I'm
> > afraid this is as muddled as all the comments on the two proposals.
> >
> > I don't want to go over it again. I just want to say that my
> > suggestion earlier in the thread is fundamentally different.
> >
> >>Global instance scope is not ok either: instances should be modular.
> > I just plain disagree. Fundamentally.
>
> Global instance scope is not required for principal typing: a
> principal type is (just) a type of an expression in a given typing
> context that has all other types of this expression in that typing
> context as instances.
>
> (Also: instance modularity is not the central issue.)
>
> >>> Wadler & Blott's 1988 paper last paragraph had already explained:
> "But
> >>> there is no principal type! "
>
> >> There is always a principal type, for every expression.
> >> Of course the type depends on the context where the expression
> occurs.
>
> > Then it's not a _principal_ type for the expression, it's just a local
> type.
> > http://foldoc.org/principal
>
> A type system has the principal type property if, given a
> term and a typing context, there exists a type for this term in this
> typing context such that all other types for this term in this typing
> context are an instance of this type.
>
> > We arrive at the principal type by unifying the principal types of
> > the sub-expressions, down to the principal types of each atom. W
> > are pointing out that without global scope for instances, typing
> > cannot assign a principal type to each method. (They left that as an
> > open problem at the end of the paper. Haskell has resolved that
> > problem by making all instances global. Changing Haskell to modular
> > instances would be a breakage. Fundamentally.)
> >
> > Under my suggestion, we can assign a (global) principal type to each
> > method -- indeed you must, by giving a signature very similar to a
> > class declaration; and that distinguishes overloaded functions from
> > parametric polymorphic functions.
>
> A principal type theorem has been proved: see, for example, Theorem 1 in
> [1].
>
> Kind regards,
>
> Carlos
>
> [1] Ambiguity and Constrained Polymorphism,
> Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro,
> Science of Computer Programming 124(1), 1--19, August 2016.
>
>
> On Mon, 8 Oct 2018 at 20:03, Anthony Clayden 
> wrote:
>
>> On Tue, 9 Oct 2018 at 7:30 AM,  wrote:
>>
>> Thanks Carlos. I wish I could say thank you for clarifying, but I'm
>> afraid this is as muddled as all the comments on the two proposals.
>>
>> I don't want to go over it again. I just want to say that my suggestion
>> earlier in the thread is fundamentally different.
>>
>> Em 2018-10-08 06:21, Anthony Clayden escreveu:
>>> > On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
>>> >
>>
>>
>> Strange: Simon's message has not appeared on the forum (he did send to
>> it). I've quoted it in full in my reply, but did break it into separate
>> pieces.
>>
>>
>>>
>>> Global instance scope is not ok either: instances should be modular.
>>
>>
>> I just plain disagree. Fundamentally.
>>
>>
>>> >
>>> > Wadler & Blott's 1988 paper last paragraph had already explained: "But
>>> > there is no principal type! "
>>>
>>> There is always a principal type, for every expression.
>>> Of course the type depends on the context where the expression occurs.
>>
>>
>> Then it's not a _principal_ type for the expression, it's just a local
>> type.
>> http://foldoc.org/principal
>>
>> We arrive at the principal type by unifying the principal types of the
>> sub-expressions, down to the principal types of each atom. W are pointing
>> out that without global scope for instances, typing cannot assign a
>> principal type to each method. (They left that as an open problem at the
>> end of the paper. Haskell has resolved that problem by making all instances
>> global. Changing Haskell t

Re: A question about run-time errors when class members are undefined

[Carlos Camarao]

Hi.

> Thanks Carlos. I wish I could say thank you for clarifying, but I'm
> afraid this is as muddled as all the comments on the two proposals.
>
> I don't want to go over it again. I just want to say that my
> suggestion earlier in the thread is fundamentally different.
>
>>Global instance scope is not ok either: instances should be modular.
> I just plain disagree. Fundamentally.

Global instance scope is not required for principal typing: a
principal type is (just) a type of an expression in a given typing
context that has all other types of this expression in that typing
context as instances.

(Also: instance modularity is not the central issue.)

>>> Wadler & Blott's 1988 paper last paragraph had already explained:
"But
>>> there is no principal type! "

>> There is always a principal type, for every expression.
>> Of course the type depends on the context where the expression
occurs.

> Then it's not a _principal_ type for the expression, it's just a local
type.
> http://foldoc.org/principal

A type system has the principal type property if, given a
term and a typing context, there exists a type for this term in this
typing context such that all other types for this term in this typing
context are an instance of this type.

> We arrive at the principal type by unifying the principal types of
> the sub-expressions, down to the principal types of each atom. W
> are pointing out that without global scope for instances, typing
> cannot assign a principal type to each method. (They left that as an
> open problem at the end of the paper. Haskell has resolved that
> problem by making all instances global. Changing Haskell to modular
> instances would be a breakage. Fundamentally.)
>
> Under my suggestion, we can assign a (global) principal type to each
> method -- indeed you must, by giving a signature very similar to a
> class declaration; and that distinguishes overloaded functions from
> parametric polymorphic functions.

A principal type theorem has been proved: see, for example, Theorem 1 in
[1].

Kind regards,

Carlos

[1] Ambiguity and Constrained Polymorphism,
Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro,
Science of Computer Programming 124(1), 1--19, August 2016.


On Mon, 8 Oct 2018 at 20:03, Anthony Clayden 
wrote:

> On Tue, 9 Oct 2018 at 7:30 AM,  wrote:
>
> Thanks Carlos. I wish I could say thank you for clarifying, but I'm afraid
> this is as muddled as all the comments on the two proposals.
>
> I don't want to go over it again. I just want to say that my suggestion
> earlier in the thread is fundamentally different.
>
> Em 2018-10-08 06:21, Anthony Clayden escreveu:
>> > On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
>> >
>
>
> Strange: Simon's message has not appeared on the forum (he did send to
> it). I've quoted it in full in my reply, but did break it into separate
> pieces.
>
>
>>
>> Global instance scope is not ok either: instances should be modular.
>
>
> I just plain disagree. Fundamentally.
>
>
>> >
>> > Wadler & Blott's 1988 paper last paragraph had already explained: "But
>> > there is no principal type! "
>>
>> There is always a principal type, for every expression.
>> Of course the type depends on the context where the expression occurs.
>
>
> Then it's not a _principal_ type for the expression, it's just a local
> type.
> http://foldoc.org/principal
>
> We arrive at the principal type by unifying the principal types of the
> sub-expressions, down to the principal types of each atom. W are pointing
> out that without global scope for instances, typing cannot assign a
> principal type to each method. (They left that as an open problem at the
> end of the paper. Haskell has resolved that problem by making all instances
> global. Changing Haskell to modular instances would be a
> breakage. Fundamentally.)
>
> Under my suggestion, we can assign a (global) principal type to each
> method -- indeed you must, by giving a signature very similar to a class
> declaration; and that distinguishes overloaded functions from parametric
> polymorphic functions.
>
>
> AntC
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[camarao]

Em 2018-10-08 06:21, Anthony Clayden escreveu:

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:


You may be interested in Carlos Camarao’s interesting work.  For a
long time now he has advocated (in effect) making each function into
its own type class, rather that grouping them into classes.


No I think you're mis-apprehending. From the abstract to the group's
SBLP2016 paper: "This depends on a modularization of instance
visibility, as well as on a redefinition of Haskell’s ambiguity
rule."


Hi. I wrote this to mean: "This depends *only* on modularization of
instances and a redefinition of Haskell's ambiguity rule" (i.e. no
extra mechanism is necessary and all well-typed Haskell programs
remain well-typed).

Haskell's ambiguity rule is not ok: a type is not ambiguous, it is an
expression that is ambiguous, depending on the context where it is
used.

Global instance scope is not ok either: instances should be modular.


You might remember early last year Carlos submitted a proposal (in two
rounds). Your comments were very relevant

https://github.com/ghc-proposals/ghc-proposals/pull/48#issuecomment-287124007

Relevant because not just was it difficult to understand the proposal,
the proposal had no answer to how instance resolution was to behave.
"expression ambiguity" turned out to mean: use module scope to resolve
overloading.


It is difficut until understanding how simple it really is.

The crucial notion of "expression ambiguity" is "overloading
resolution" (or: the decision of "overloading is resolved"), based on
the existence of "unreachable variables": if and only if there are
unreachable variables, satisfiability must be tested for the
constraints with unreachable variables.

Instance modular scope is secondary.


In the second round of the proposal and in an extended email exchange
off-forum with (I think it was) Rodrigo Ribeiro in Carlos' group I
tried to tease out how module-scoped instances were going to work for
a method exported to a module where there was a different instance in
scope. Of course 'orphan instances' are the familiar symptom in GHC.

Wadler & Blott's 1988 paper last paragraph had already explained: "But
there is no principal type! "


There is always a principal type, for every expression.
Of course the type depends on the context where the expression occurs.


Perhaps that is in line with your thinking.


Not at all. My thinking is coming directly from Wadler's early 1988
memo that I referenced (note *not* the W paper) + using some of
GHC's more recent features like explicit type application in terms;
and its counterpart: explicit method application in types.


Again: the proposal does not need any extra mechanism, just a change
to the ambiguity rule and instance modular scope. It would be possible
even to maintain instances as global, but in my view this
should not be done (it is better to have modular instances).


I wonder how different would have been the history of Haskell if
Wadler had not borrowed the terminology "class" and "method". Since
Helium has a focus on Haskell learners/beginners: I wonder how much
confusion we might have saved those coming from OOP where the terms
mean something really quite different. We might have avoided "class"
altogether; and talked of "overloaded function".


This is another matter, that does not need to be discussed now: we can
avoid type classes, or we can have type classes as optional, but this
discussion can be done later.

Kind regards,

Carlos
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:

You may be interested in Carlos Camarao’s interesting work.  For a long
> time now he has advocated (in effect) making each function into its own
> type class, rather that grouping them into classes.
>

No I think you're mis-apprehending. From the abstract to the group's
SBLP2016 paper: "This depends on a modularization of instance visibility,
as well as on a redefinition of Haskell’s ambiguity rule."

You might remember early last year Carlos submitted a proposal (in two
rounds). Your comments were very relevant
https://github.com/ghc-proposals/ghc-proposals/pull/48#issuecomment-287124007

Relevant because not just was it difficult to understand the proposal, the
proposal had no answer to how instance resolution was to behave.
"expression ambiguity" turned out to mean: use module scope to resolve
overloading.

In the second round of the proposal and in an extended email exchange
off-forum with (I think it was) Rodrigo Ribeiro in Carlos' group I tried to
tease out how module-scoped instances were going to work for a method
exported to a module where there was a different instance in scope. Of
course 'orphan instances' are the familiar symptom in GHC.

Wadler & Blott's 1988 paper last paragraph had already explained: "But
there is no principal type! "


   Perhaps that is in line with your thinking.
>

Not at all. My thinking is coming directly from Wadler's early 1988 memo
that I referenced (note *not* the W paper) + using some of GHC's more
recent features like explicit type application in terms; and its
counterpart: explicit method application in types.

I wonder how different would have been the history of Haskell if Wadler had
not borrowed the terminology "class" and "method". Since Helium has a focus
on Haskell learners/beginners: I wonder how much confusion we might have
saved those coming from OOP where the terms mean something really quite
different. We might have avoided "class" altogether; and talked of
"overloaded function".


AntC


*From:* Haskell-prime  *On Behalf
Of *Anthony
> Clayden
> *Sent:* 06 October 2018 04:19
> *To:* Petr Pudlák 
> *Cc:* haskell-prime@haskell.org
> *Subject:* Re: A question about run-time errors when class members are
> undefined
>
>
>
>
>
> On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák 
> wrote:
>
>
>
> IIRC one of the arguments against having many separate classes is that a
> class is not a just set of methods, it's also the relations between them,
>
>
>
> Hi Petr, I was talking about splitting out Haskell's current class
> hierarchy as a step towards doing away with classes altogether. If your
> language insists on methods being held in classes, that's just tedious
> bureacracy to invent class names.
>
>
>
> The relations between classes (including between single-method classes)
> can be captured through superclass constraints. For example, in the Haskell
> 2010 report
>
>
>
> class (Eq a, Show a) => Num a where ...
>
>
>
> such as the important laws between `return` and `>>=`. And then for
> example a class with just `return` doesn't give any information what
> `return x` means or what should be its properties.
>
>
>
> Then make Bind a superclass constraint on `return` (or vice versa, or both
> ways).
>
>
>
> Just as the laws for Num's methods are defined in terms of equality
>
>
>
> x + negate x == fromInteger 0  -- for example
>
>
>
> Talking about laws is a red herring: you can't declare the laws/the
> compiler doesn't enforce them or rely on them in any way. Indeed the
> Lensaholics seem to take pleasure in building lenses that break the (van
> Laarhoven) laws.
>
>
>
>
>
>
>
> That said, one of really painful points of Haskell is that refactoring a
> hierarchy of type-classes means breaking all the code that implements them.
> This was also one of the main reasons why reason making Applicative a
> superclass of Monad took so long. It'd be much nicer to design type-classes
> in such a way that an implementation doesn't have to really care about the
> exact hierarchy.
>
>
>
> Yes that's what I was saying. Unfortunately for Haskell's Num class, I
> think it's just too hard. So a new language has an opportunity to avoid
> that. If OTOH Helium wants to slavishly follow Haskell, I'm wondering what
> is the point of Helium.
>
>
>
> With Applicative, IIRC, refactoring had to wait until we got Constraint
> kinds and type families that could produce them. Would Helium want to put
> all that into a language aimed at beginners?
>
>
>
>
>
>  For example, in Haskell we could have
>
>
>
> class (Return m, Bind m) => Mon

Re: A question about run-time errors when class members are undefined

[Philippa Cowderoy]

You're implicitly arguing that no language should have support for 
declaring informal intentions. That's rather more controversial than you 
might think and it's worth separating out as a subject.


The fact you cheerfully talk about making return and bind inherently 
related via superclass constraints is pretty suggestive. Away from 
monads, there are a lot of other uses for return-like behaviour that 
have a different (if often-related) set of laws. Which is exactly why 
many people want them to be completely separate superclasses of Monad. 
It's only when they're used to form a monad that those extra laws show 
up. Which no, Haskell can't enforce, but there's a big difference 
between "this breaks because seq in a partial language weirds things" 
and "this would be broken in a total setting too". What happens when I 
legitimately want both operations but a different set of laws, and don't 
want my stuff being passed to things that reasonably expect the monad 
laws to hold?


Asking a researcher who's producing actual results "what's the point?" 
is more than a little inflammatory, too. Helium is not accountable to us.



On 06/10/2018 04:18, Anthony Clayden wrote:


On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák > wrote:



IIRC one of the arguments against having many separate classes is
that a class is not a just set of methods, it's also the relations
between them,


Hi Petr, I was talking about splitting out Haskell's current class 
hierarchy as a step towards doing away with classes altogether. If 
your language insists on methods being held in classes, that's just 
tedious bureacracy to invent class names.


The relations between classes (including between single-method 
classes) can be captured through superclass constraints. For example, 
in the Haskell 2010 report


class (Eq a, Show a) => Num a where ...

such as the important laws between `return` and `>>=`. And then
for example a class with just `return` doesn't give any
information what `return x` means or what should be its properties.


Then make Bind a superclass constraint on `return` (or vice versa, or 
both ways).


Just as the laws for Num's methods are defined in terms of equality

x + negate x == fromInteger 0          -- for example

Talking about laws is a red herring: you can't declare the laws/the 
compiler doesn't enforce them or rely on them in any way. Indeed the 
Lensaholics seem to take pleasure in building lenses that break the 
(van Laarhoven) laws.




That said, one of really painful points of Haskell is that
refactoring a hierarchy of type-classes means breaking all the
code that implements them. This was also one of the main reasons
why reason making Applicative a superclass of Monad took so long.
It'd be much nicer to design type-classes in such a way that an
implementation doesn't have to really care about the exact hierarchy.


Yes that's what I was saying. Unfortunately for Haskell's Num class, I 
think it's just too hard. So a new language has an opportunity to 
avoid that. If OTOH Helium wants to slavishly follow Haskell, I'm 
wondering what is the point of Helium.


With Applicative, IIRC, refactoring had to wait until we got 
Constraint kinds and type families that could produce them. Would 
Helium want to put all that into a language aimed at beginners?



 For example, in Haskell we could have

class (Return m, Bind m) => Monad m where

without any methods specified. But instances of `Monad` should be
only such types for which `return` and `>>=` satisfy the monad laws.


First: what does "satisfy the xxx laws" mean? The Haskell report and 
GHC's Prelude documentation state a bunch of laws; and it's a good 
discipline to write down laws if you're creating a class; but it's 
only documentation. Arguably IO, the most commonly used Monad, breaks 
the Monad laws in rather serious ways because it imposes sequence of 
execution; and it would be unfit for purpose if it were pure/lazy 
function application.


Then: what do you think a language could do to detect if some instance 
satisfies the laws? (Even supposing you could declare them.)



And this would distinguish them from types that have both `Return`
and `Bind` instances, but don't satisfy the laws.


You could have distinct classes/distinct operators. Oh, but then `do` 
dotation would break.



Unfortunately I'm not sure if there is a good solution for
achieving both these directions.


I don't think there's any solution for achieving "satisfy the xxx laws".


AntC


čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden
mailto:anthony_clay...@clear.net.nz>> napsal:

> We are adding classes and instances to Helium.

> We wondered about the aspect that it is allowed to have a class 
instance

> of which not all fields have a piece of code/value associated with 
them, ...

I have a suggestion for that. But first let 

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák  wrote:

>
> IIRC one of the arguments against having many separate classes is that a
> class is not a just set of methods, it's also the relations between them,
>

Hi Petr, I was talking about splitting out Haskell's current class
hierarchy as a step towards doing away with classes altogether. If your
language insists on methods being held in classes, that's just tedious
bureacracy to invent class names.

The relations between classes (including between single-method classes) can
be captured through superclass constraints. For example, in the Haskell
2010 report

class (Eq a, Show a) => Num a where ...

such as the important laws between `return` and `>>=`. And then for example
> a class with just `return` doesn't give any information what `return x`
> means or what should be its properties.
>

Then make Bind a superclass constraint on `return` (or vice versa, or both
ways).

Just as the laws for Num's methods are defined in terms of equality

x + negate x == fromInteger 0  -- for example

Talking about laws is a red herring: you can't declare the laws/the
compiler doesn't enforce them or rely on them in any way. Indeed the
Lensaholics seem to take pleasure in building lenses that break the (van
Laarhoven) laws.



> That said, one of really painful points of Haskell is that refactoring a
> hierarchy of type-classes means breaking all the code that implements them.
> This was also one of the main reasons why reason making Applicative a
> superclass of Monad took so long. It'd be much nicer to design type-classes
> in such a way that an implementation doesn't have to really care about the
> exact hierarchy.
>

Yes that's what I was saying. Unfortunately for Haskell's Num class, I
think it's just too hard. So a new language has an opportunity to avoid
that. If OTOH Helium wants to slavishly follow Haskell, I'm wondering what
is the point of Helium.

With Applicative, IIRC, refactoring had to wait until we got Constraint
kinds and type families that could produce them. Would Helium want to put
all that into a language aimed at beginners?


 For example, in Haskell we could have
>
> class (Return m, Bind m) => Monad m where
>
> without any methods specified. But instances of `Monad` should be only
> such types for which `return` and `>>=` satisfy the monad laws.
>

First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's
Prelude documentation state a bunch of laws; and it's a good discipline to
write down laws if you're creating a class; but it's only documentation.
Arguably IO, the most commonly used Monad, breaks the Monad laws in rather
serious ways because it imposes sequence of execution; and it would be
unfit for purpose if it were pure/lazy function application.

Then: what do you think a language could do to detect if some instance
satisfies the laws? (Even supposing you could declare them.)


And this would distinguish them from types that have both `Return` and
> `Bind` instances, but don't satisfy the laws.
>

You could have distinct classes/distinct operators. Oh, but then `do`
dotation would break.


> Unfortunately I'm not sure if there is a good solution for achieving both
> these directions.
>

I don't think there's any solution for achieving "satisfy the xxx laws".


AntC


> čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden <
> anthony_clay...@clear.net.nz> napsal:
>
>> > We are adding classes and instances to Helium.
>>
>> > We wondered about the aspect that it is allowed to have a class instance
>>
>> > of which not all fields have a piece of code/value associated with them, 
>> > ...
>>
>>
>> I have a suggestion for that. But first let me understand where you're going 
>> with Helium. Are you aiming to slavishly reproduce Haskell's 
>> classes/instances, or is this a chance for a rethink?
>>
>>
>> Will you want to include associated types and associated datatypes in the 
>> classes? Note those are just syntactic sugar for top-level type families and 
>> data families. It does aid readability to put them within the class.
>>
>>
>> I would certainly rethink the current grouping of methods into classes. 
>> Number purists have long wanted to split class Num into Additive vs 
>> Multiplicative. (Additive would be a superclass of Multiplicative.) For the 
>> Naturals perhaps we want Presburger arithmetic then Additive just contains 
>> (+), with `negate` certainly in a different class, perhaps (-) subtract also 
>> in a dedicated class. Also there's people wanting Monads with just `bind` 
>> not `return`. But restructuring the Prelude classes/methods is just too hard 
>> with all that legacy code. Even though you should be able to do:
>>
>>
>> class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive a) 
>> => Num a
>>
>>
>> Note there's a lot of classes with a single method, and that seems to be an 
>> increasing trend. Historically it wasn't so easy in Haskell to do that 
>> superclass constraints business; 

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

On Fri, 5 Oct 2018 at 9:00 PM, Jurriaan Hage  wrote:

>
> We first go the slavish route, to provide a basis for changing things
> later.


Ah. That comment seemed strange, but I've just read up on Helium: you're
aiming to provide a beginners' environment for Haskell.

Then without type classes, I'm wondering what Helium is doing now for
arithmetic or equality-testing or show or read? Do you mean you've somehow
'faked' the Prelude classes, but don't yet allow programmers to declare
their own classes/instances?

Being able to declare your own datatypes without writing instances for them
seems particularly awkward.

If Helium essentially supports less than H98, I'm wondering why you didn't
start with Hugs, and work on it giving better error messages? I'm finding
Hugs very easy to hack; the messages are particularly easy to work with.
(OK it's written in C++, but the 'interesting' parts are just function
calls, so the host language seems irrelevant.)


AntC
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: A question about run-time errors when class members are undefined

[Petr Pudlák]

Hi everyone,

IIRC one of the arguments against having many separate classes is that a
class is not a just set of methods, it's also the relations between them,
such as the important laws between `return` and `>>=`. And then for example
a class with just `return` doesn't give any information what `return x`
means or what should be its properties.

That said, one of really painful points of Haskell is that refactoring a
hierarchy of type-classes means breaking all the code that implements them.
This was also one of the main reasons why reason making Applicative a
superclass of Monad took so long. It'd be much nicer to design type-classes
in such a way that an implementation doesn't have to really care about the
exact hierarchy.

The Go language takes a very simple view on this: A type implements an
interface if all the methods are implemented, without having to explicitly
specify this intent [1]. This looks very nice and clean indeed. But the
drawback is that this further decouples type-classes (interfaces) from
their laws (like monad laws, monoid laws etc.). For example, in Haskell we
could have

class (Return m, Bind m) => Monad m where

without any methods specified. But instances of `Monad` should be only such
types for which `return` and `>>=` satisfy the monad laws. And this would
distinguish them from types that have both `Return` and `Bind` instances,
but don't satisfy the laws.

Unfortunately I'm not sure if there is a good solution for achieving both
these directions.

[1] https://tour.golang.org/methods/10

Cheers,
Petr

čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden <
anthony_clay...@clear.net.nz> napsal:

> > We are adding classes and instances to Helium.
>
> > We wondered about the aspect that it is allowed to have a class instance
>
> > of which not all fields have a piece of code/value associated with them, ...
>
>
> I have a suggestion for that. But first let me understand where you're going 
> with Helium. Are you aiming to slavishly reproduce Haskell's 
> classes/instances, or is this a chance for a rethink?
>
>
> Will you want to include associated types and associated datatypes in the 
> classes? Note those are just syntactic sugar for top-level type families and 
> data families. It does aid readability to put them within the class.
>
>
> I would certainly rethink the current grouping of methods into classes. 
> Number purists have long wanted to split class Num into Additive vs 
> Multiplicative. (Additive would be a superclass of Multiplicative.) For the 
> Naturals perhaps we want Presburger arithmetic then Additive just contains 
> (+), with `negate` certainly in a different class, perhaps (-) subtract also 
> in a dedicated class. Also there's people wanting Monads with just `bind` not 
> `return`. But restructuring the Prelude classes/methods is just too hard with 
> all that legacy code. Even though you should be able to do:
>
>
> class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive a) 
> => Num a
>
>
> Note there's a lot of classes with a single method, and that seems to be an 
> increasing trend. Historically it wasn't so easy in Haskell to do that 
> superclass constraints business; if it had been perhaps there would be more 
> classes with a single method. Then there's some disadvantages to classes 
> holding multiple methods:
>
> * the need to provide an overloading for every method, even though it may not 
> make sense
>
>   (or suffer a run-time error, as you say)
>
> * the inability to 'fine tune' methods for a specific datatype [**]
>
> * an internal compiler/object code cost of passing a group of methods in a 
> dictionary as tuple
>
>   (as apposed to directly selecting a single method)
>
>
> [**] Nats vs Integrals vs Fractionals for `Num`; and (this will be 
> controversial, but ...) Some people want to/some languages do use (+) for 
> concatenating Strings/lists. But the other methods in `Num` don't make any 
> sense.
>
>
> If all your classes have a single method, the class name would seem to be 
> superfluous, and the class/instance decl syntax seems too verbose.
>
>
> So here's a suggestion. I'll need to illustrate with some definite syntax, 
> but there's nothing necessary about it. (I'll borrow the Explicit Type 
> Application `@`.) To give an instance overloading for method `show` or (==)
>
>
> show @Int = primShowInt -- in effect pattern matching on 
> the type
>
> (==) @Int = primEqInt   -- so see showList below
>
> That is: I'm giving an overloading for those methods on type `Int`. How do I 
> declare those methods are overloadable? In their signature:
>
>
> show @a :: a -> String  -- compare show :: Show a => a -> 
> String
>
> (==) @a :: a -> a -> Bool
>
> Non-overladable functions don't have `@a` to the left of `::`.
>
> How do I show that a class has a superclass constraint? That is: a method has 
> a supermethod constraint, we'll still use `=>`:
>
>
> show @a :: 

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

On Fri, 5 Oct 2018 at 9:00 PM, Jurriaan Hage  wrote:

>
> We first go the slavish route, to provide a basis for changing things
> later.
>
> So I am not looking for alternative ways of doing this, I am just
> wondering whether there is a rationale for doing things this way.
> The document does not give one.
>

The only explanation I can think of is that there might be default
implementations of the methods -- very likely defined in terms of other
methods in the class. (Such as (/=) defaulting to `not (==)`, and (==)
defaulting to `not (/=)`.) Then it's a nuisance to have to say 'just use
the default'. But I agree GHC should cope better than a run-time exception.


> And now I hear that records suffer from the same issue (thanks Cale).


I'm not perturbed or surprised by that. Consider the assignments to the
`zn` have the same effect here:

data D = MkD {x :: Int, y :: Bool}

z1 = MkD{ x = 5 }  -- y not mentioned, so
set undefined
z2 = MkD{ x = 5, y = undefined }
z3 = MkD 5 undefined

We had not run into this yet, because right now Helium does not have ‘em.


Haskell records were embarrassingly bad in 1998. No change or improvement
in Haskell 2010. Some minor easing in recent years with GHC extensions --
I'd call that lipstick on a pig.

If you've not implemented 'em yet, I just plain wouldn't. Ever. Support
Lenses or any of the 50 gazillion proposals. Even Hugs' TRex is better
(throws a type error at compile time if you omit a field).

Both sound fishy to me and if nobody can make a case for having things this
> way
> in the first place, I wonder why it’s like that.
>

There's a huge volume of minor inconsistencies and annoyances in GHC. I
guess we hardly notice because we get used to them (or we each use a subset
of features). A lot can be explained by the shackle of backwards
compatibility: every new extension must use distinct syntax, so that people
who don't want it/aren't aware of it don't run into surprises. For example,
there's now annoyingly similar-but-different semantics for H98 data,
existential fields, constrained fields, GADTs, data families/instances,
view patterns, pattern synonyms. I can't help but feel they should all get
unified into a single semantics; then those differing syntactic forms be
treated as shorthands/variations on a theme.



> The only one I might consider at this time is GADTs,


I do find the (~) type equality constraints from GADTs/Type Families very
pleasing and intuitive. You might be able to implement that without all the
other paraphernalia.

AntC


> > On 4Oct, 2018, at 03:55, Anthony Clayden 
> wrote:
> >
> > > We are adding classes and instances to Helium.
> > > We wondered about the aspect that it is allowed to have a class
> instance
> > > of which not all fields have a piece of code/value associated with
> them, ...
> >
> > I have a suggestion for that. But first let me understand where you're
> going with Helium. Are you aiming to slavishly reproduce Haskell's
> classes/instances, or is this a chance for a rethink?
> >
> > Will you want to include associated types and associated datatypes in
> the classes? Note those are just syntactic sugar for top-level type
> families and data families. It does aid readability to put them within the
> class.
> >
> > I would certainly rethink the current grouping of methods into classes.
> Number purists have long wanted to split class Num into Additive vs
> Multiplicative. (Additive would be a superclass of Multiplicative.) For the
> Naturals perhaps we want Presburger arithmetic then Additive just contains
> (+), with `negate` certainly in a different class, perhaps (-) subtract
> also in a dedicated class. Also there's people wanting Monads with just
> `bind` not `return`. But restructuring the Prelude classes/methods is just
> too hard with all that legacy code. Even though you should be able to do:
> >
> > class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive
> a) => Num a
> >
> > Note there's a lot of classes with a single method, and that seems to be
> an increasing trend. Historically it wasn't so easy in Haskell to do that
> superclass constraints business; if it had been perhaps there would be more
> classes with a single method. Then there's some disadvantages to classes
> holding multiple methods:
> > * the need to provide an overloading for every method, even though it
> may not make sense
> >   (or suffer a run-time error, as you say)
> > * the inability to 'fine tune' methods for a specific datatype [**]
> > * an internal compiler/object code cost of passing a group of methods in
> a dictionary as tuple
> >   (as apposed to directly selecting a single method)
> >
> > [**] Nats vs Integrals vs Fractionals for `Num`; and (this will be
> controversial, but ...) Some people want to/some languages do use (+) for
> concatenating Strings/lists. But the other methods in `Num` don't make any
> sense.
> >
> > If all your classes have a single method, the class name 

Re: A question about run-time errors when class members are undefined

[Jurriaan Hage]

Hi Anthony,

We first go the slavish route, to provide a basis for changing things later. 

So I am not looking for alternative ways of doing this, I am just wondering 
whether there is a rationale for doing things this way.
The document does not give one. 

And now I hear that records suffer from the same issue (thanks Cale). We had 
not run into this yet, because right now
Helium does not have ‘em. Both sound fishy to me and if nobody can make a case 
for having things this way
in the first place, I wonder why it’s like that.

Adding associated types is a long way off, or any such language extensions is 
at this point. 
The only one I might consider at this time is GADTs, but only if I find a 
master student to investigate type error diagnosis
in that setting. 

Jur

> On 4Oct, 2018, at 03:55, Anthony Clayden  wrote:
> 
> > We are adding classes and instances to Helium.
> > We wondered about the aspect that it is allowed to have a class instance
> > of which not all fields have a piece of code/value associated with them, ...
> 
> I have a suggestion for that. But first let me understand where you're going 
> with Helium. Are you aiming to slavishly reproduce Haskell's 
> classes/instances, or is this a chance for a rethink?
> 
> Will you want to include associated types and associated datatypes in the 
> classes? Note those are just syntactic sugar for top-level type families and 
> data families. It does aid readability to put them within the class.
> 
> I would certainly rethink the current grouping of methods into classes. 
> Number purists have long wanted to split class Num into Additive vs 
> Multiplicative. (Additive would be a superclass of Multiplicative.) For the 
> Naturals perhaps we want Presburger arithmetic then Additive just contains 
> (+), with `negate` certainly in a different class, perhaps (-) subtract also 
> in a dedicated class. Also there's people wanting Monads with just `bind` not 
> `return`. But restructuring the Prelude classes/methods is just too hard with 
> all that legacy code. Even though you should be able to do:
> 
> class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive a) 
> => Num a
> 
> Note there's a lot of classes with a single method, and that seems to be an 
> increasing trend. Historically it wasn't so easy in Haskell to do that 
> superclass constraints business; if it had been perhaps there would be more 
> classes with a single method. Then there's some disadvantages to classes 
> holding multiple methods:
> * the need to provide an overloading for every method, even though it may not 
> make sense
>   (or suffer a run-time error, as you say)
> * the inability to 'fine tune' methods for a specific datatype [**]
> * an internal compiler/object code cost of passing a group of methods in a 
> dictionary as tuple
>   (as apposed to directly selecting a single method)
> 
> [**] Nats vs Integrals vs Fractionals for `Num`; and (this will be 
> controversial, but ...) Some people want to/some languages do use (+) for 
> concatenating Strings/lists. But the other methods in `Num` don't make any 
> sense.
> 
> If all your classes have a single method, the class name would seem to be 
> superfluous, and the class/instance decl syntax seems too verbose.
> 
> So here's a suggestion. I'll need to illustrate with some definite syntax, 
> but there's nothing necessary about it. (I'll borrow the Explicit Type 
> Application `@`.) To give an instance overloading for method `show` or (==)
> 
> show @Int = primShowInt -- in effect pattern matching on 
> the type
> (==) @Int = primEqInt   -- so see showList below
> That is: I'm giving an overloading for those methods on type `Int`. How do I 
> declare those methods are overloadable? In their signature:
> 
> show @a :: a -> String  -- compare show :: Show a => a -> 
> String
> (==) @a :: a -> a -> Bool
> Non-overladable functions don't have `@a` to the left of `::`.
> How do I show that a class has a superclass constraint? That is: a method has 
> a supermethod constraint, we'll still use `=>`:
> 
> show @a :: showsPrec @a => a -> String  -- supermethod constraint
> show @[a] :: show a => [a] -> String-- instance decl, because not 
> bare a, with constraint =>
> show @[a] xss = showList xss
> (*) @a :: (+) @a => a -> a -> a
> 
> Is this idea completely off the wall? Take a look at Wadler's original 1988 
> memo introducing what became type classes. 
> http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt
> 
> It reviews several possible designs, but not all those possibilities made it 
> into his paper (with Stephen Blott) later in 1988/January 1989. In particular 
> look at Section 1's 'Simple overloading'. It's what I'm suggesting above 
> (modulo a bit of syntax). At the end of Section 1, Wadler rejects this design 
> because of "potential blow-ups". But he should have pushed the idea a bit 
> further. Perhaps he 

Re: A question about run-time errors when class members are undefined

[Anthony Clayden]

> We are adding classes and instances to Helium.

> We wondered about the aspect that it is allowed to have a class instance

> of which not all fields have a piece of code/value associated with them, ...


I have a suggestion for that. But first let me understand where you're
going with Helium. Are you aiming to slavishly reproduce Haskell's
classes/instances, or is this a chance for a rethink?


Will you want to include associated types and associated datatypes in
the classes? Note those are just syntactic sugar for top-level type
families and data families. It does aid readability to put them within
the class.


I would certainly rethink the current grouping of methods into
classes. Number purists have long wanted to split class Num into
Additive vs Multiplicative. (Additive would be a superclass of
Multiplicative.) For the Naturals perhaps we want Presburger
arithmetic then Additive just contains (+), with `negate` certainly in
a different class, perhaps (-) subtract also in a dedicated class.
Also there's people wanting Monads with just `bind` not `return`. But
restructuring the Prelude classes/methods is just too hard with all
that legacy code. Even though you should be able to do:


class (Additive a, Subtractive a, Negative a, Multiplicative a,
Divisive a) => Num a


Note there's a lot of classes with a single method, and that seems to
be an increasing trend. Historically it wasn't so easy in Haskell to
do that superclass constraints business; if it had been perhaps there
would be more classes with a single method. Then there's some
disadvantages to classes holding multiple methods:

* the need to provide an overloading for every method, even though it
may not make sense

  (or suffer a run-time error, as you say)

* the inability to 'fine tune' methods for a specific datatype [**]

* an internal compiler/object code cost of passing a group of methods
in a dictionary as tuple

  (as apposed to directly selecting a single method)


[**] Nats vs Integrals vs Fractionals for `Num`; and (this will be
controversial, but ...) Some people want to/some languages do use (+)
for concatenating Strings/lists. But the other methods in `Num` don't
make any sense.


If all your classes have a single method, the class name would seem to
be superfluous, and the class/instance decl syntax seems too verbose.


So here's a suggestion. I'll need to illustrate with some definite
syntax, but there's nothing necessary about it. (I'll borrow the
Explicit Type Application `@`.) To give an instance overloading for
method `show` or (==)


show @Int = primShowInt -- in effect pattern
matching on the type

(==) @Int = primEqInt   -- so see showList below

That is: I'm giving an overloading for those methods on type `Int`.
How do I declare those methods are overloadable? In their signature:


show @a :: a -> String  -- compare show :: Show a
=> a -> String

(==) @a :: a -> a -> Bool

Non-overladable functions don't have `@a` to the left of `::`.

How do I show that a class has a superclass constraint? That is: a
method has a supermethod constraint, we'll still use `=>`:


show @a :: showsPrec @a => a -> String  -- supermethod constraint

show @[a] :: show a => [a] -> String-- instance decl, because
not bare a, with constraint =>

show @[a] xss = showList xss

(*) @a :: (+) @a => a -> a -> a


Is this idea completely off the wall? Take a look at Wadler's original
1988 memo introducing what became type classes.
http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt


It reviews several possible designs, but not all those possibilities
made it into his paper (with Stephen Blott) later in 1988/January
1989. In particular look at Section 1's 'Simple overloading'. It's
what I'm suggesting above (modulo a bit of syntax). At the end of
Section 1, Wadler rejects this design because of "potential blow-ups".
But he should have pushed the idea a bit further. Perhaps he was
scared to allow function/method names into type signatures? (I've
already sneaked that in above with constraints.) These days Haskell is
getting more relaxed about namespaces: the type `@`pplication exactly
allows type names appearing in terms. So to counter his example, the
programmer writes:


square x = x * x -- no explicit signature given

square :: (*) @a => a -> a   -- signature inferred,
because (*) is overloaded

rms = sqrt . square  -- no explicit signature

rms :: sqrt @a => a -> a -- signature inferred


Note the inferred signature for `rms` doesn't need `(*) @a` even
though it's inferred from `square`. Because (*) is a supermethod of
`sqrt`. `sqrt` might also have other supermethods, that amount to
`Floating`.


> ... a run-time error results.
>
> Does anyone know of a rationale for this choice, since it seems rather 
> unhaskell-like.


If you allow default method implementations 

Re: A question about run-time errors when class members are undefined

[Cale Gibbard]

This and the fact that you may leave record fields unspecified when
initially constructing a record are two things I'd probably change if I
could. In the rare case of a class with a method that will usually be an
error, you could still define that as the default method implementation in
the class.

On Mon, Oct 1, 2018, 04:36 Jurriaan Hage,  wrote:

> Hello,
>
> We are adding classes and instances to Helium.
>
> We wondered about the aspect that it is allowed to have a class instance
> of which not all fields have a piece of code/value associated with them,
> and
> that as a result when you happen to call these, a run-time error results.
>  (see Sec. 4.3.2 of the Haskell 2010 report).
>
> Does anyone know of a rationale for this choice, since it seems rather
> unhaskell-like.
>
> best,
> Jur
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

A question about run-time errors when class members are undefined

[Jurriaan Hage]

Hello,

We are adding classes and instances to Helium.

We wondered about the aspect that it is allowed to have a class instance
of which not all fields have a piece of code/value associated with them, and 
that as a result when you happen to call these, a run-time error results.
(see Sec. 4.3.2 of the Haskell 2010 report).

Does anyone know of a rationale for this choice, since it seems rather 
unhaskell-like.

best,
Jur

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Process question

[David Luposchainsky via Haskell-prime]

On 04.10.2016 19:09, Iavor Diatchki wrote:
> Now that we've started with a few proposal, I am realizing that I have no idea
> how to proceed from here.

> 1. How would I request I proposal to be rejected

I think we should be discussing things, rather than inventing too many 
processes.
The number of people participating is still rather small, so verbally stating
that you’re strongly opposed to a feature (in principle or just in its current
form) is fairly visible.

> 2. How would I request that a proposal be accepted

Make yourself the shepherd of the proposal (assign yourself to it), make sure 
all
questions and concerns have been discussed, then send a “last call” style email
to the mailing lists or other public places you think should give it a final
thought? I think that sounds sensible.

David


-- 
My GPG keys: https://keybase.io/quchen
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Process question

[Richard Eisenberg]

Does this GitHub feature help: https://github.com/haskell/rfcs/projects/1

After a proposal is accepted, then an individual (or small group) needs to 
write up the changes to the Report, which should then also go back through the 
larger committee.

And I’ll amplify some of Mario’s questions:

> 
> 2. How do we prepare the actual Haskell 2020 language report? The report is 
> more than a collection of disparate proposals. The Haskell 2010 report also 
> contains errors whose fixing shouldn't require writing up a whole language 
> proposal.
> 
> 2a. Would the current text of the Haskell' language report be stored in the 
> same GitHub repository with the RFCs? If not, where else?
> 
> 2b. Would we merge each proposal into the language report as soon as it's 
> accepted? Whose responsibility would this (largely mechanical) process be?

I think we should put the Report text in this separate repo. An accepted 
proposal is merged into the rfcs repo -- that is, the PR is accepted. Then a 
new PR can eventually be made to amend the text in the report repo.

Richard

> On Oct 5, 2016, at 10:50 AM, Mario Blažević  wrote:
> 
> On 2016-10-04 01:09 PM, Iavor Diatchki wrote:
>> Hello,
>> 
>> Now that we've started with a few proposal, I am realizing that I have
>> no idea how to proceed from here.  In particular:
>> 
>> 1. How would I request I proposal to be rejected
>> 2. How would I request that a proposal be accepted
> 
>   I don't know if we need to fix the acceptance/rejection process so 
> early on. Once a new proposal is merged in, it need not be immediately 
> accepted or rejected. It could just collect comments and adjustments. I see 
> no point in voting for acceptance or rejection until the time comes to 
> prepare Haskell 2020.
> 
>   If my understanding of the process is correct, this raises two more 
> groups of questions.
> 
> 1. I assume we'd use GitHub issues to discuss and/or point flaws in a 
> particular proposal?
> 
> 1a. If so, it would be nice to group together all issues related to a 
> paricular proposal, but GitHub issues don't come with much metadata. Do we 
> prescribe some keyword that has to be specified in the subject of each 
> proposal-related issue?
> 
> 1b. There could be a special "Accept me" issue for each proposal used for 
> tracking its status. GitHub issues can be assigned to milestones, such as 
> "Accepted for Haskell2020", "Last Call for Votes", "Awaiting Comments", or 
> "Work In Progress".
> 
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Process question

[Mario Blažević]

On 2016-10-04 01:09 PM, Iavor Diatchki wrote:

Hello,

Now that we've started with a few proposal, I am realizing that I have
no idea how to proceed from here.  In particular:

1. How would I request I proposal to be rejected
2. How would I request that a proposal be accepted


	I don't know if we need to fix the acceptance/rejection process so 
early on. Once a new proposal is merged in, it need not be immediately 
accepted or rejected. It could just collect comments and adjustments. I 
see no point in voting for acceptance or rejection until the time comes 
to prepare Haskell 2020.


	If my understanding of the process is correct, this raises two more 
groups of questions.


1. I assume we'd use GitHub issues to discuss and/or point flaws in a 
particular proposal?


1a. If so, it would be nice to group together all issues related to a 
paricular proposal, but GitHub issues don't come with much metadata. Do 
we prescribe some keyword that has to be specified in the subject of 
each proposal-related issue?


1b. There could be a special "Accept me" issue for each proposal used 
for tracking its status. GitHub issues can be assigned to milestones, 
such as "Accepted for Haskell2020", "Last Call for Votes", "Awaiting 
Comments", or "Work In Progress".


2. How do we prepare the actual Haskell 2020 language report? The report 
is more than a collection of disparate proposals. The Haskell 2010 
report also contains errors whose fixing shouldn't require writing up a 
whole language proposal.


2a. Would the current text of the Haskell' language report be stored in 
the same GitHub repository with the RFCs? If not, where else?


2b. Would we merge each proposal into the language report as soon as 
it's accepted? Whose responsibility would this (largely mechanical) 
process be?


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Process question

[Iavor Diatchki]

Hello,

Now that we've started with a few proposal, I am realizing that I have no
idea how to proceed from here.  In particular:

1. How would I request I proposal to be rejected
2. How would I request that a proposal be accepted

Ideas?

-Iavor
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: [Haskell] I repeat my Question becaue I not really sure to do it right

[Ivan Lazar Miljenovic]

On 28 August 2016 at 22:40,  <cc...@web.de> wrote:
> This is Leksah http://leksah.org/
> Please excuse my false name for it
> And the Question is why can I install it.

What error messages do you have when you try?

From here, this is what you need to do:
https://github.com/leksah/leksah/wiki/download

> cabal install gtk2hs-buildtools

> cabal install leksah



>
> excuse me.
> Mungo1981
>
> Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr
> Von: "Ivan Lazar Miljenovic" <ivan.miljeno...@gmail.com>
> An: cc...@web.de
> Cc: "Haskell List" <haskell@haskell.org>
> Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to do
> it right
> On 28 August 2016 at 20:43, <cc...@web.de> wrote:
>> Ok Haskell is good.
>> Ok Laska is great.
>> And my Ubuntu Studio ist rubish
>> So I try to install Laska on Ubuntu Studio
>> But when I do this, i will get a long list of dependecies
>> which could not reallise
>> So I not know what should I do
>
> Which question?
>
> What is Laska that you're having trouble installing it?
>
>>
>> Mungo1981
>>
>> ___
>> Haskell mailing list
>> Haskell@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
>
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> http://IvanMiljenovic.wordpress.com
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] I repeat my Question becaue I not really sure to do it right

[CCUTM]

This is Leksah http://leksah.org/

Please excuse my false name for it

And the Question is why can I install it.

 

excuse me.

Mungo1981

 

Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr
Von: "Ivan Lazar Miljenovic" <ivan.miljeno...@gmail.com>
An: cc...@web.de
Cc: "Haskell List" <haskell@haskell.org>
Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to do it right

On 28 August 2016 at 20:43, <cc...@web.de> wrote:
> Ok Haskell is good.
> Ok Laska is great.
> And my Ubuntu Studio ist rubish
> So I try to install Laska on Ubuntu Studio
> But when I do this, i will get a long list of dependecies
> which could not reallise
> So I not know what should I do

Which question?

What is Laska that you're having trouble installing it?

>
> Mungo1981
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>



--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com



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

Re: [Haskell] I repeat my Question becaue I not really sure to do it right

[Ivan Lazar Miljenovic]

On 28 August 2016 at 20:43,  <cc...@web.de> wrote:
> Ok Haskell is good.
> Ok Laska is great.
> And my Ubuntu Studio ist rubish
> So I try to install Laska on Ubuntu Studio
> But when I do this, i will get a long list of dependecies
> which could not reallise
> So I not know what should I do

Which question?

What is Laska that you're having trouble installing it?

>
> Mungo1981
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] I repeat my Question becaue I not really sure to do it right

[CCUTM]

Ok Haskell is good.

Ok Laska is great.

And my Ubuntu Studio ist rubish

So I try to install Laska on Ubuntu Studio

But when I do this, i will get a long list of dependecies

which could not reallise

So I not know what should I do

 

Mungo1981
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: Package version question with Cabal

[Volker Wysk]

Am Montag, 19. Januar 2015, 23:32:09 schrieben Sie:
 On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk vertei...@volker-wysk.de
 
 wrote:
  I've uploaded my library to Hackage, and now I'm trying to install it via
  cabal:
 At a guess, the index has not yet been updated --- you may need to wait
 some time (might be as short as an hour) before trying to install it from
 Hackage.
 
 You also need to run cabal update to download the updated package index
 so your local cabal-install knows about the new package.

I'm not completely sure what happened, but now it seems to work. The Default 
available version is the latest one. Looks like you have been right. Thanx.

Volker
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Package version question with Cabal

[Volker Wysk]

Am Dienstag, 20. Januar 2015, 05:14:15 schrieb Volker Wysk:
 ~/src/hsshellscript $ cabal install

Oops, this should be cabal install hsshellscript-3.3.3, not just cabal 
install:

~/src/hsshellscript $ cabal install hsshellscript-3.3.3
Resolving dependencies...
All the requested packages are already installed:
hsshellscript-3.3.3
Use --reinstall if you want to reinstall anyway.

But when I try --reinstall, I get this error:

~/src/hsshellscript $ cabal --reinstall install hsshellscript-3.3.3
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: hsshellscript (user goal)
rejecting: hsshellscript-3.3.2, 3.3.1, 3.3.0, 3.2.0, 3.1.0 (global constraint
requires ==3.3.3)
Dependency tree exhaustively searched.

What does this mean...?

I've also in vain searched for a way to remove a cabal installed package.

Thanks,
Volker

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Package version question with Cabal

[Volker Wysk]

Hi!

I've uploaded my library to Hackage, and now I'm trying to install it via 
cabal:

~/src/hsshellscript $ cabal install 
Resolving dependencies...
In order, the following will be installed:
hsshellscript-3.3.3 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring hsshellscript-3.3.3...
Building hsshellscript-3.3.3...
Preprocessing library hsshellscript-3.3.3...
In-place registering hsshellscript-3.3.3...
Creating package registration file: /tmp/pkgConf-hsshellscript-3.37397.3
Installing library in
/home/v/.cabal/lib/x86_64-linux-ghc-7.8.3/hsshellscript-3.3.3
Registering hsshellscript-3.3.3...
Installed hsshellscript-3.3.3

~/src/hsshellscript $ cabal list hsshellscript
* hsshellscript
Synopsis: Haskell for Unix shell scripting tasks
Default available version: 3.3.2
Installed versions: 3.3.1, 3.3.2, 3.3.3
Homepage: http://www.volker-wysk.de/hsshellscript/
License:  LGPL

The thing wich looks like a problem is, that the new version isn't made the 
Default available version. It is 3.3.3, but Default available version is 
still 3.3.2.

Is this a problem? How do I register a new default version?

Bye
Volker

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Package version question with Cabal

[Brandon Allbery]

On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk vertei...@volker-wysk.de
wrote:

 I've uploaded my library to Hackage, and now I'm trying to install it via
 cabal:


At a guess, the index has not yet been updated --- you may need to wait
some time (might be as short as an hour) before trying to install it from
Hackage.

You also need to run cabal update to download the updated package index
so your local cabal-install knows about the new package.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: question about GADT's and error messages

[Richard Eisenberg]

My understanding of OutsideIn leads me to believe that GHC 7.8 has the behavior 
closer to that spec. See Section 5.2 of that paper 
(http://research.microsoft.com/en-us/um/people/simonpj/Papers/constraints/jfp-outsidein.pdf),
 which is a relatively accessible explanation of this phenomenon. Daniel's 
explanation is essentially a condensed version of that section.

I'm not surprised that the behavior changed between GHC 6.x and 7.x, as I 
believe 7.x is what brought in OutsideIn. I don't know much about the change 
between 7.6 and 7.8, though. And, I agree that the untouchable error messages 
are generally inscrutable. When I see that message in my own code, my takeaway 
is generally I have a mistake somewhere near that line, nothing more specific 
or useful. I've accordingly posted a bug report #9109 
(https://ghc.haskell.org/trac/ghc/ticket/9109). Please comment there if you 
have either useful examples or other contributions to the fix -- it may be hard 
to get this one right.

Richard

On May 13, 2014, at 5:51 PM, Andres Löh and...@well-typed.com wrote:

 Hi.
 
 Daniel is certainly right to point out general problems with GADT
 pattern matching and principal types. Nevertheless, the changing
 behaviour of GHC over time is currently a bit confusing to me.
 
 In GHC-6.12.3, Doaitse's program fails with three errors (demo1,
 demo2, demo4, all the GADT pattern matches without type signature),
 and the error messages are:
 
 /home/andres/trans/GT.hs:7:15:
GADT pattern match in non-rigid context for `AInt'
  Probable solution: add a type signature for the scrutinee of the
 case expression
In the pattern: AInt i
In a case alternative: (AInt i) - print i
In the expression: case a of { (AInt i) - print i }
 
 /home/andres/trans/GT.hs:33:18:
GADT pattern match with non-rigid result type `t'
  Solution: add a type signature for the entire case expression
In a case alternative: (AInt i) - print i
In the expression: case a of { (AInt i) - print i }
In the expression: do { case a of { (AInt i) - print i } }
 
 /home/andres/trans/GT.hs:41:18:
GADT pattern match with non-rigid result type `t'
  Solution: add a type signature for the entire case expression
In a case alternative: (AInt i) - print i
In the expression: case AInt 3 of { (AInt i) - print i }
In the expression: do { case AInt 3 of { (AInt i) - print i } }
 
 These error messages are conservative, but clear. They ask the user to
 add a type signature.
 
 With GHC-7.0.4, GHC-7.2.1, GHC-7.4.2, and GHC-7.6.3, the program
 compiles without error, including demo1.
 
 With GHC-7.8.2, the compiler reports the error Doaitse mentioned:
 
 /home/andres/trans/GT.hs:7:27:
Couldn't match expected type ‘t’ with actual type ‘IO ()’
  ‘t’ is untouchable
inside the constraints (t1 ~ Int)
 
 I think the error message would be more helpful if it would mention
 adding a type signature as a possible fix again.
 
 But, assuming for the time being that GHC is correct to reject this
 program and that GHC-7 was wrong up until now, then I'd like to know
 what the new rule for GADT pattern matching is. Obviously, it's more
 relaxed than it used to be (because demo2 and demo4 are still
 accepted). Also, am I correct that the OutsideIn JFP paper is still
 the correct description of what's going on in the type checker? If so,
 is GHC-7.6 or GHC-7.8 closer to implementing what the OutsideIn paper
 describes? Is the change in behaviour documented somewhere?
 
 Thanks.
 
 Cheers,
  Andres
 
 -- 
 Andres Löh, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com
 
 Registered in England  Wales, OC335890
 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

question about GADT's and error messages

[S. Doaitse Swierstra]

Given the following code:

{-# LANGUAGE GADTs #-}
data Any a where
AInt :: Int - Any Int

-- demo 1 does not compile
{-
demo1 a = do case a of
(AInt i) - print i

 Couldn't match expected type ‘t’ with actual type ‘IO ()’
   ‘t’ is untouchable
 inside the constraints (t1 ~ Int)
 bound by a pattern with constructor
AInt :: Int - Any Int,
  in a case alternative
 at /Users/doaitse/TryHaskell/TestGADT.hs:6:17-22
   ‘t’ is a rigid type variable bound by
   the inferred type of demo1 :: Any t1 - t
   at /Users/doaitse/TryHaskell/TestGADT.hs:5:1
 Relevant bindings include
   demo1 :: Any t1 - t
 (bound at /Users/doaitse/TryHaskell/TestGADT.hs:5:1)
 In the expression: print i
 In a case alternative: (AInt i) - print i
Failed, modules loaded: none.
-}


-- all the following go through without complaints:

a = AInt 3
demo2 = do case a of
(AInt i) - print i

demo3 :: IO ()
demo3 = do case a of
(AInt i) - print i


demo4 = do case AInt 3 of
(AInt i) - print i

demo5 :: Any Int - IO ()
demo5 a = do case a of
(AInt i) - print i

I do not see why the error message in demo1 arises. It claims it can't match 
some t with the type IO (), but when I tell that the result is IO () it can?
I think at least the error message is confusing, and not very helpful. I would 
have in no way been able to get the clue that add a type signature as in the 
case of demo5 would solve the problem.

What am I overlooking?

Doaitse


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: question about GADT's and error messages

[Daniel Wagner]

I just hit a similar error the other day. I think the gist of it is that 
there are two perfectly good types, and neither is more general than the 
other. A slightly different example shows why more clearly:


foo (AInt i) = (3 :: Int)

Now, what type should this have?

foo :: Any a - a
foo :: Any a - Int

both seem pretty good, and neither is clearly better. It's not *as* 
obvious what the two candidates might be for your example, but maybe you 
could imagine something like these two types:


demo1 :: AInt a - IO ()
type family Foo a
type instance Foo Int = IO ()
demo1 :: AInt a - Foo a

Again, not too clear that one is better, I think.
~d

On 2014-05-13 14:20, S. Doaitse Swierstra wrote:

Given the following code:

{-# LANGUAGE GADTs #-}
data Any a where
AInt :: Int - Any Int

-- demo 1 does not compile
{-
demo1 a = do case a of
(AInt i) - print i

 Couldn't match expected type ‘t’ with actual type ‘IO ()’
   ‘t’ is untouchable
 inside the constraints (t1 ~ Int)
 bound by a pattern with constructor
AInt :: Int - Any Int,
  in a case alternative
 at /Users/doaitse/TryHaskell/TestGADT.hs:6:17-22
   ‘t’ is a rigid type variable bound by
   the inferred type of demo1 :: Any t1 - t
   at /Users/doaitse/TryHaskell/TestGADT.hs:5:1
 Relevant bindings include
   demo1 :: Any t1 - t
 (bound at /Users/doaitse/TryHaskell/TestGADT.hs:5:1)
 In the expression: print i
 In a case alternative: (AInt i) - print i
Failed, modules loaded: none.
-}


-- all the following go through without complaints:

a = AInt 3
demo2 = do case a of
(AInt i) - print i

demo3 :: IO ()
demo3 = do case a of
(AInt i) - print i


demo4 = do case AInt 3 of
(AInt i) - print i

demo5 :: Any Int - IO ()
demo5 a = do case a of
(AInt i) - print i

I do not see why the error message in demo1 arises. It claims it can't
match some t with the type IO (), but when I tell that the result is
IO () it can?
I think at least the error message is confusing, and not very helpful.
I would have in no way been able to get the clue that add a type
signature as in the case of demo5 would solve the problem.

What am I overlooking?

Doaitse


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: question about GADT's and error messages

[Andres Löh]

Hi.

Daniel is certainly right to point out general problems with GADT
pattern matching and principal types. Nevertheless, the changing
behaviour of GHC over time is currently a bit confusing to me.

In GHC-6.12.3, Doaitse's program fails with three errors (demo1,
demo2, demo4, all the GADT pattern matches without type signature),
and the error messages are:

/home/andres/trans/GT.hs:7:15:
GADT pattern match in non-rigid context for `AInt'
  Probable solution: add a type signature for the scrutinee of the
case expression
In the pattern: AInt i
In a case alternative: (AInt i) - print i
In the expression: case a of { (AInt i) - print i }

/home/andres/trans/GT.hs:33:18:
GADT pattern match with non-rigid result type `t'
  Solution: add a type signature for the entire case expression
In a case alternative: (AInt i) - print i
In the expression: case a of { (AInt i) - print i }
In the expression: do { case a of { (AInt i) - print i } }

/home/andres/trans/GT.hs:41:18:
GADT pattern match with non-rigid result type `t'
  Solution: add a type signature for the entire case expression
In a case alternative: (AInt i) - print i
In the expression: case AInt 3 of { (AInt i) - print i }
In the expression: do { case AInt 3 of { (AInt i) - print i } }

These error messages are conservative, but clear. They ask the user to
add a type signature.

With GHC-7.0.4, GHC-7.2.1, GHC-7.4.2, and GHC-7.6.3, the program
compiles without error, including demo1.

With GHC-7.8.2, the compiler reports the error Doaitse mentioned:

/home/andres/trans/GT.hs:7:27:
Couldn't match expected type ‘t’ with actual type ‘IO ()’
  ‘t’ is untouchable
inside the constraints (t1 ~ Int)

I think the error message would be more helpful if it would mention
adding a type signature as a possible fix again.

But, assuming for the time being that GHC is correct to reject this
program and that GHC-7 was wrong up until now, then I'd like to know
what the new rule for GADT pattern matching is. Obviously, it's more
relaxed than it used to be (because demo2 and demo4 are still
accepted). Also, am I correct that the OutsideIn JFP paper is still
the correct description of what's going on in the type checker? If so,
is GHC-7.6 or GHC-7.8 closer to implementing what the OutsideIn paper
describes? Is the change in behaviour documented somewhere?

Thanks.

Cheers,
  Andres

-- 
Andres Löh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England  Wales, OC335890
250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

OutsideIn(X) question

[Alejandro Serrano Mena]

(Cross-posted from Haskell-Café)

I don't know if this is the best forum to ask questions about the
OutsideIn(X) paper that lies below type inference in GHC. Any way, I sent
it to Haskell-café and was advised to send it here also.

My question related about the proof of soundness and principality,
specifically Lemma 7.2 (to be found in page 67). In that lemma, it's stated
that QQ and \phi' Q_q ||- \phi Q_w - \phi' Q_w'. I'm trying to recover
the proof (which is omitted in the text), but I stumble upon a wall when
trying to work out what happens in the case an axiom is applied.

In particular, I'm playing with an example where

QQ (the set of axioms) = { forall. C a = D a } (where C and D are
one-parameter type classes)
Q_q = { }
Q_w = { D Int }

Thus, if I apply the rule DINSTW (to be found in page 65), I get a new

Q_w' = { C Int }

Now, if the lemma 7.2 is true, it should be the case that

(1)  QQ ||- C Int - D Int

which in particular means that I have the two implications

(2)  { forall. C a = D a, C Int } ||- D Int
(3)  { forall. C a = D a, D Int } ||- C Int

(2) follows easily by applying the AXIOM rule of ||- (as shown in page 54).
However, I don't see how to make (3) work :(
I think that understanding this example will be key for my understanding of
the whole system.

Anybody could point to the error in my reasoning or to places where I could
find more information?
Thanks in advance.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] A question regarding reading CPP definitions from a C header

[Malcolm Wallace]

If you use cpphs as a library, there is an API called runCpphsReturningSymTab.  
Thence you can throw away the actual pre-preprocessed result text, keep only 
the symbol table, and lookup whatever macros you wish to find their values.  I 
suggest you make this into a little code-generator, to produce a Haskell module 
containing the values you need.

On 5 Oct 2013, at 21:37, Ömer Sinan Ağacan wrote:

 Hi all,
 
 Let's say I want to #include a C header file in my Haskell library
 just to read some macro definitions. The C header file also contains
 some C code. Is there a way to load only macro definitions and not C
 code in #include declarations in Haskell?
 
 What I'm trying to do is I'm linking my library against this C library
 but I want to support different versions of this C library, so I want
 to read it's version from one of it's header files. The problem is the
 header file contains some C code and makes my Haskell source code
 mixed with C source before compilation.
 
 Any suggestions would be appreciated,

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A question regarding reading CPP definitions from a C header

[Ömer Sinan Ağacan]

Thanks for your answer, looks like this is my only option to do this.

Can you provide some information about what does parameters of
runCpphsReturningSymTab stands for? I made several attempts but
couldn't get any useful return value.

For example, I have no idea what does third parameter does. Also,
second parameter.

Thanks,

---
Ömer Sinan Ağacan
http://osa1.net


2013/10/7 Malcolm Wallace malcolm.wall...@me.com:
 If you use cpphs as a library, there is an API called 
 runCpphsReturningSymTab.  Thence you can throw away the actual 
 pre-preprocessed result text, keep only the symbol table, and lookup whatever 
 macros you wish to find their values.  I suggest you make this into a little 
 code-generator, to produce a Haskell module containing the values you need.

 On 5 Oct 2013, at 21:37, Ömer Sinan Ağacan wrote:

 Hi all,

 Let's say I want to #include a C header file in my Haskell library
 just to read some macro definitions. The C header file also contains
 some C code. Is there a way to load only macro definitions and not C
 code in #include declarations in Haskell?

 What I'm trying to do is I'm linking my library against this C library
 but I want to support different versions of this C library, so I want
 to read it's version from one of it's header files. The problem is the
 header file contains some C code and makes my Haskell source code
 mixed with C source before compilation.

 Any suggestions would be appreciated,

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A question regarding reading CPP definitions from a C header

[Carl Howells]

Have you looked into using hsc2hs? If I understand your problem, it's
designed exactly to solve it.

-- 
Carl


On Mon, Oct 7, 2013 at 12:20 PM, Ömer Sinan Ağacan omeraga...@gmail.comwrote:

 Thanks for your answer, looks like this is my only option to do this.

 Can you provide some information about what does parameters of
 runCpphsReturningSymTab stands for? I made several attempts but
 couldn't get any useful return value.

 For example, I have no idea what does third parameter does. Also,
 second parameter.

 Thanks,

 ---
 Ömer Sinan Ağacan
 http://osa1.net


 2013/10/7 Malcolm Wallace malcolm.wall...@me.com:
  If you use cpphs as a library, there is an API called
 runCpphsReturningSymTab.  Thence you can throw away the actual
 pre-preprocessed result text, keep only the symbol table, and lookup
 whatever macros you wish to find their values.  I suggest you make this
 into a little code-generator, to produce a Haskell module containing the
 values you need.
 
  On 5 Oct 2013, at 21:37, Ömer Sinan Ağacan wrote:
 
  Hi all,
 
  Let's say I want to #include a C header file in my Haskell library
  just to read some macro definitions. The C header file also contains
  some C code. Is there a way to load only macro definitions and not C
  code in #include declarations in Haskell?
 
  What I'm trying to do is I'm linking my library against this C library
  but I want to support different versions of this C library, so I want
  to read it's version from one of it's header files. The problem is the
  header file contains some C code and makes my Haskell source code
  mixed with C source before compilation.
 
  Any suggestions would be appreciated,
 
 ___
 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] A question regarding reading CPP definitions from a C header

[Ömer Sinan Ağacan]

Carl, thank you very much. This is exactly what I was looking for, and
it solved my problem in 5 minutes.

What's awesome is that when Cabal finds a .hsc file it automatically
calls this tool. Great.

Thanks again.

---
Ömer Sinan Ağacan
http://osa1.net


2013/10/8 Carl Howells chowell...@gmail.com:
 Have you looked into using hsc2hs? If I understand your problem, it's
 designed exactly to solve it.

 --
 Carl


 On Mon, Oct 7, 2013 at 12:20 PM, Ömer Sinan Ağacan omeraga...@gmail.com
 wrote:

 Thanks for your answer, looks like this is my only option to do this.

 Can you provide some information about what does parameters of
 runCpphsReturningSymTab stands for? I made several attempts but
 couldn't get any useful return value.

 For example, I have no idea what does third parameter does. Also,
 second parameter.

 Thanks,

 ---
 Ömer Sinan Ağacan
 http://osa1.net


 2013/10/7 Malcolm Wallace malcolm.wall...@me.com:
  If you use cpphs as a library, there is an API called
  runCpphsReturningSymTab.  Thence you can throw away the actual
  pre-preprocessed result text, keep only the symbol table, and lookup
  whatever macros you wish to find their values.  I suggest you make this 
  into
  a little code-generator, to produce a Haskell module containing the values
  you need.
 
  On 5 Oct 2013, at 21:37, Ömer Sinan Ağacan wrote:
 
  Hi all,
 
  Let's say I want to #include a C header file in my Haskell library
  just to read some macro definitions. The C header file also contains
  some C code. Is there a way to load only macro definitions and not C
  code in #include declarations in Haskell?
 
  What I'm trying to do is I'm linking my library against this C library
  but I want to support different versions of this C library, so I want
  to read it's version from one of it's header files. The problem is the
  header file contains some C code and makes my Haskell source code
  mixed with C source before compilation.
 
  Any suggestions would be appreciated,
 
 ___
 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

[Haskell-cafe] A question regarding reading CPP definitions from a C header

[Ömer Sinan Ağacan]

Hi all,

Let's say I want to #include a C header file in my Haskell library
just to read some macro definitions. The C header file also contains
some C code. Is there a way to load only macro definitions and not C
code in #include declarations in Haskell?

What I'm trying to do is I'm linking my library against this C library
but I want to support different versions of this C library, so I want
to read it's version from one of it's header files. The problem is the
header file contains some C code and makes my Haskell source code
mixed with C source before compilation.

Any suggestions would be appreciated,

Thanks,


---
Ömer Sinan Ağacan
http://osa1.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[arch-haskell] Silly question (arch-haskell vs cabal)

[Dawid Loubser]

Hi all,

As a new user of arch-haskell, I would just like to put the question out
there: What is the point of arch-haskell, vs using cabal? Is it simply
for the elegance of using a single package manager (pacman) for all
packages on my system (Haskell-related and not) or is there some other
inherent problem I can expect down the line if I were to use the cabal
ecosystem?

sorry if this is a redundant question -
Dawid Loubser


signature.asc
Description: This is a digitally signed message part
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] Silly question (arch-haskell vs cabal)

[Ramana Kumar]

One version of the answer to your question can be found here:
https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/


On Mon, Sep 23, 2013 at 10:29 AM, Dawid Loubser dawid.loub...@ibi.co.zawrote:

 Hi all,

 As a new user of arch-haskell, I would just like to put the question out
 there: What is the point of arch-haskell, vs using cabal? Is it simply
 for the elegance of using a single package manager (pacman) for all
 packages on my system (Haskell-related and not) or is there some other
 inherent problem I can expect down the line if I were to use the cabal
 ecosystem?

 sorry if this is a redundant question -
 Dawid Loubser

 ___
 arch-haskell mailing list
 arch-haskell@haskell.org
 http://www.haskell.org/mailman/listinfo/arch-haskell


___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] Silly question (arch-haskell vs cabal)

[Dawid Loubser]

Ramana, thank you for providing exactly the answer I was looking for! I
understand the differences between Cabal and cabal-install much better
now, thank you - this is a very informative article.

I have to admit, cabal-install has generallly just worked for me (as
an amateur starting out with Haskell), whereas arch-haskell has often
incurred failures when building. I am going to try again from a clean
sheet, and if I still have issues with arch-haskell, I will start
raising them with the community.

kind regards,
Dawid Loubser


Op Ma, 2013-09-23 om 10:48 +0100 skryf Ramana Kumar:
 One version of the answer to your question can be found here:
 https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
 
 
 
 On Mon, Sep 23, 2013 at 10:29 AM, Dawid Loubser
 dawid.loub...@ibi.co.za wrote:
 Hi all,
 
 As a new user of arch-haskell, I would just like to put the
 question out
 there: What is the point of arch-haskell, vs using cabal? Is
 it simply
 for the elegance of using a single package manager (pacman)
 for all
 packages on my system (Haskell-related and not) or is there
 some other
 inherent problem I can expect down the line if I were to use
 the cabal
 ecosystem?
 
 sorry if this is a redundant question -
 Dawid Loubser
 
 ___
 arch-haskell mailing list
 arch-haskell@haskell.org
 http://www.haskell.org/mailman/listinfo/arch-haskell
 
 
 


signature.asc
Description: This is a digitally signed message part
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] Silly question (arch-haskell vs cabal)

[Magnus Therning]

On Mon, Sep 23, 2013 at 12:06:19PM +0200, Dawid Loubser wrote:
 I have to admit, cabal-install has generallly just worked for me
 (as an amateur starting out with Haskell), whereas arch-haskell has
 often incurred failures when building. I am going to try again from
 a clean sheet, and if I still have issues with arch-haskell, I will
 start raising them with the community.

A few times when I've commented on threads relating to package
managers and cabal-install I've also heard comments along the lines of
most questions related to installing Haskell libs come from users of
distro package managers, not from from users of cabal-install.
However, this doesn't match my personal experience at all.

If you do indeed have /any/ problems with [haskell-core] then please
raise them on github.com/archhaskell/habs (or here if that fails)
since I'm very interested in making sure our packages install and work
properly.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

When the people fear their government, there is tyranny; when the
government fears the people, there is liberty.
 -- Thomas Jefferson


pgpZu4zOY7aBq.pgp
Description: PGP signature
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

RE: Question about correct GHC-API use for type checking (or zonking, or tidying)

[p.k.f.holzenspies]

Well, my tcLocalBinds seems to have a different type then yours (this is from 
my copy of 7.6.3 and it's the same in the HEAD that I just synced):

tcLocalBinds :: HsLocalBinds Name - TcM thing - TcM (HsLocalBinds TcId, thing)

If I want to get a GblEnv out, I can use getGblEnv, but doing this:


mkId :: Maybe FreeVars - LHsExpr Name - Name - TcM Id
mkId fvs expr@(L l _) nm = do
  ((binds', gbl_env),lie) - captureConstraints $ tcLocalBinds binds getGblEnv
  setGblEnv gbl_env (tcLookupId nm)
where
binds= HsValBinds $ ValBindsOut [(NonRecursive, unitBag fixbnd)] []
the_bind = mkTopFunBind (L l nm) [mkMatch [] expr emptyLocalBinds]
fixbnd   = L l $ maybe the_bind (\vs - the_bind { bind_fvs = vs }) fvs


fails on the tcLookupId with a GHC internal error complaining that my name is 
not in scope during type checking, but it passed the renamer.

Ph.




From: Simon Peyton-Jones [mailto:simo...@microsoft.com]
Sent: dinsdag 10 september 2013 14:19
To: Holzenspies, P.K.F. (EWI)
Cc: glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

What goes wrong if you follow my suggestion below?

tcLocalBinds takes a set of bindings, such as x=e
and returns a GblEnv whose type envt is extended with a binding for x with its 
generalised type.
This type wil indeed be closed, unless the current environment (in which 
tcLocalBinds runs) has bindings with open types. Which in your case it probably 
doesn't.

I feel that I am not being helpful but I'm not sure how to help more.

S

From: Philip K.F. Hölzenspies [mailto:p.k.f.holzensp...@utwente.nl]
Sent: 04 September 2013 21:25
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
Subject: Re: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

Ah, this is good to know. What I really would like is a function:

mkId :: Name - LHsExpr Name - TcM Id

where that Id is something I can store in my own monad (IA). The meaning of 
this, is indeed let name = expression as a top-level binding. The 
behaviour should actually be the same as that statement at the ghci-prompt. My 
IA monad implements liftTcM as something that invokes a TcM-monad, i.e.

liftTcM :: TcM b - IA b
liftTcM thing_inside = do
hsc_env - getSession
stored_ids - getStoredIds :: IA [Id]-- this is the list of all Ids 
made through mkId mentioned above
ioMsgMaybe . initTcPrintErrors hsc_env iNTERACTIVE $
setInteractiveContext hsc_env (hsc_IC hsc_env) $
tcExtendGlobalValEnv stored_ids $ -- or tcExtendIdEnv??
thing_inside

In the example you give below, I'm curious which thing_inside you give to 
tcLocalBinds to get you the correct global environment. Also, if I do what you 
suggest, i.e.

poly_id - setGblEnv gbl_env (tcLookupId the_id_name)

is that poly_id self contained, in the sense that I can put it in a new 
instantiation as shown above?

Regards,
Philip









[cid:image001.jpg@01CEAEDB.407DA510]
Simon Peyton-Jonesmailto:simo...@microsoft.com
September 4, 2013 6:00 PM
The id you are getting is a monomorphic id, with a type like a-a, not the 
polymorphic forall a. a-a.  You don't want to go round arbitrarily creating a 
new Id with the same unique but a different type. I have no idea what would 
happen then.

It's hard for me to understand just what you code is trying to do.  I think you 
are making bindig
it = some expr

and then you want the type of it.  Maybe something like

   (binds', gbl_env) - tcLocalBinds (..your bindin..)
   poly_id - setGblEnv gbl_env (tcLooupId the_id_name)

But I'm not totally sure.

S
inline: image001.jpg___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] GHC API question: Getting access to cpp processed source

[AlanKim Zimmerman]

Thanks for the reference, but GHC already invokes the CPP.

I think I am going to have to invoke a load of the module with ghc flags
set to keep the output of the CPP phase, and then re-invoke it on that
output to get the tokens.

My question is more whether this CPP output can be kept in the GHC session
for re-use, or whether I will have to mess around on the file system.

Alan


On Wed, Sep 11, 2013 at 12:56 AM, Henk-Jan van Tuyl hjgt...@chello.nlwrote:

 On Wed, 11 Sep 2013 00:54:07 +0200, Henk-Jan van Tuyl hjgt...@chello.nl
 wrote:

  Another option could be the cpphs package; the documentation has
 disappeared from haskell.org, but can be found in the Web Archive[0].


 I just found the latest documentation at
 http://code.haskell.org/cpphs/**docs/http://code.haskell.org/cpphs/docs/

 Regards,
 Henk-Jan van Tuyl



 --
 Folding@home
 What if you could share your unused computer power to help find a cure? In
 just 5 minutes you can join the world's biggest networked computer and get
 us closer sooner. Watch the video.
 http://folding.stanford.edu/


 http://Van.Tuyl.eu/
 http://members.chello.nl/**hjgtuyl/tourdemonad.htmlhttp://members.chello.nl/hjgtuyl/tourdemonad.html
 Haskell programming
 --

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC API question: Getting access to cpp processed source

[Carter Schonwald]

you need to run a preprocessor on it to remove the directives


On Tue, Sep 10, 2013 at 4:03 PM, AlanKim Zimmerman alan.z...@gmail.comwrote:

 Hi Cafe

 I have just discovered that GHC.getTokenStream fails if it is used on a
 module with CPP directives in it.

 This is reported in http://ghc.haskell.org/trac/ghc/ticket/8265

 Is there an easy way to get access to the pre-processed source, without
 having to explicitly write it to an output file in a temporary location?

 In other words an equivalent to getModuleSourceAndFlags that does the
 right thing.

 This currently prevents HaRe from processing files with preprocessor
 directives in them, I would like to come up with a workaround for current
 GHC versions, rather than having to wait for a future one.

 Regards
   Alan

 ___
 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] GHC API question: Getting access to cpp processed source

[Henk-Jan van Tuyl]

On Tue, 10 Sep 2013 22:03:16 +0200, AlanKim Zimmerman  
alan.z...@gmail.com wrote:



Is there an easy way to get access to the pre-processed source, without
having to explicitly write it to an output file in a temporary location?


You can run cpp with function readProcess, as done in function  
readHeaderFile in

https://github.com/wxHaskell/wxHaskell/blob/master/wxdirect/src/ParseC.hs

Windows does not come with cpp; one can install MinGW for this purpose.

Another option could be the cpphs package; the documentation has  
disappeared from haskell.org, but can be found in the Web Archive[0].


Regards,
Henk-Jan van Tuyl


[0] http://web.archive.org/web/20100620174616/http://haskell.org/cpphs/


--
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.

http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC API question: Getting access to cpp processed source

[Henk-Jan van Tuyl]

On Wed, 11 Sep 2013 00:54:07 +0200, Henk-Jan van Tuyl hjgt...@chello.nl  
wrote:


Another option could be the cpphs package; the documentation has  
disappeared from haskell.org, but can be found in the Web Archive[0].


I just found the latest documentation at
http://code.haskell.org/cpphs/docs/

Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.

http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHC API question: Getting access to cpp processed source

[AlanKim Zimmerman]

Hi Cafe

I have just discovered that GHC.getTokenStream fails if it is used on a
module with CPP directives in it.

This is reported in http://ghc.haskell.org/trac/ghc/ticket/8265

Is there an easy way to get access to the pre-processed source, without
having to explicitly write it to an output file in a temporary location?

In other words an equivalent to getModuleSourceAndFlags that does the right
thing.

This currently prevents HaRe from processing files with preprocessor
directives in them, I would like to come up with a workaround for current
GHC versions, rather than having to wait for a future one.

Regards
  Alan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: Question about correct GHC-API use for type checking (or zonking, or tidying)

[Simon Peyton-Jones]

The id you are getting is a monomorphic id, with a type like a-a, not the 
polymorphic forall a. a-a.  You don't want to go round arbitrarily creating a 
new Id with the same unique but a different type. I have no idea what would 
happen then.

It's hard for me to understand just what you code is trying to do.  I think you 
are making bindig
it = some expr

and then you want the type of it.  Maybe something like

   (binds', gbl_env) - tcLocalBinds (..your bindin..)
   poly_id - setGblEnv gbl_env (tcLooupId the_id_name)

But I'm not totally sure.

S


From: p.k.f.holzensp...@utwente.nl [mailto:p.k.f.holzensp...@utwente.nl]
Sent: 03 September 2013 14:18
To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

Dear Simon, et al,

I had a chance to try it now. The strange thing is that when I use the lines:

zonked_id - TcMType.zonkId id
say $ zonked idType:  ++ pp (idType zonked_id)

that is still some unresolved type variable (i.e. prints as b_i). Since I 
already have the intended target-type (considering the code by which it is 
produced), is it safe to do what TcMType.zonkId does and manually set it? In 
other words, I now do this:

zonked_ty - zonkTcType all_expr_ty
return (setIdType id zonked_ty)

Will this bite me later?

Regards,
Philip



From: Simon Peyton-Jones [mailto:simo...@microsoft.com]
Sent: maandag 2 september 2013 13:34
To: Holzenspies, P.K.F. (EWI); 
glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

Does this mean that for the idType to come out correctly I should also zonk 
(AND BIND) the Id-value I return?

Yes, zonk the type and grab the type that comes back.

S

From: p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl 
[mailto:p.k.f.holzensp...@utwente.nl]
Sent: 30 August 2013 17:49
To: Simon Peyton-Jones; 
glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
Subject: Re: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

I feel so unbelievably ignorant now. I thought with all the IORefs in the type 
checking process that zonking did this in these refs. Somehow I started 
thinking that some of these remained in SDocs, not thinking showSDoc is pure 
and results in a String, which holds no IORefs.

Does this mean that for the idType to come out correctly I should also zonk 
(AND BIND) the Id-value I return?

Ph.




Sent from Samsung Mobile



 Original message 
From: Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com
Date: 30/08/2013 18:25 (GMT+01:00)
To: Holzenspies, P.K.F. (EWI) 
p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl,glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)
Haskell is a *functional* language.  Consider

say $   pre-zonk:   ++ pp all_expr_ty
zonkTcType all_expr_ty
say $   post-zonk:  ++ pp all_expr_ty

pp is a pure function; it is given the same input both times, so of course it 
produces the same output.

If you collect the result of zonkTcType you might have better luck, thus:

say $   pre-zonk:   ++ pp all_expr_ty
zonked_expr_ty - zonkTcType all_expr_ty
say $   post-zonk:  ++ pp zonked_expr_ty

Zonking walks over a type, returning a new type in which unification variables 
are replaced by the types they unified to.

Hope this helps

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.orgmailto:boun...@haskell.org] On Behalf Of 
p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl
| Sent: 29 August 2013 14:42
| To: 
glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
| Subject: Question about correct GHC-API use for type checking (or
| zonking, or tidying)
|
| Dear GHC-ers,
|
| I'm working on building an interactive environment around the
| composition of expressions. Users can type in (i.e. give strings of)
| expressions and can then use these expressions to produce other
| expressions. I'm close to having a working GHC-API binding for this. The
| resulting types, however, still contain some things I don't quite
| understand. Any help would be appreciated.
|
| Below, I've included the function exprFromString which should parse,
| rename and typecheck strings to Id-things and give their type (although,
| ideally, the idType of said Id-thing should be the same as the type
| returned). This function lives in the IA (InterActive) monad; a monad
| that is a GhcMonad and can lift monadic computations in TcM into itself
| using liftTcM (which uses the initTcPrintErrors and
| setInteractiveContext functions similarly to TcRnDriver.tcRnExpr).
|
| Near the end of the function, debugging output is produced. This output
| confuses me slightly. Here

RE: Question about correct GHC-API use for type checking (or zonking, or tidying)

[Simon Peyton-Jones]

Does this mean that for the idType to come out correctly I should also zonk 
(AND BIND) the Id-value I return?

Yes, zonk the type and grab the type that comes back.

S

From: p.k.f.holzensp...@utwente.nl [mailto:p.k.f.holzensp...@utwente.nl]
Sent: 30 August 2013 17:49
To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org
Subject: Re: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

I feel so unbelievably ignorant now. I thought with all the IORefs in the type 
checking process that zonking did this in these refs. Somehow I started 
thinking that some of these remained in SDocs, not thinking showSDoc is pure 
and results in a String, which holds no IORefs.

Does this mean that for the idType to come out correctly I should also zonk 
(AND BIND) the Id-value I return?

Ph.




Sent from Samsung Mobile



 Original message 
From: Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com
Date: 30/08/2013 18:25 (GMT+01:00)
To: Holzenspies, P.K.F. (EWI) 
p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl,glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

Haskell is a *functional* language.  Consider

say $   pre-zonk:   ++ pp all_expr_ty
zonkTcType all_expr_ty
say $   post-zonk:  ++ pp all_expr_ty

pp is a pure function; it is given the same input both times, so of course it 
produces the same output.

If you collect the result of zonkTcType you might have better luck, thus:

say $   pre-zonk:   ++ pp all_expr_ty
zonked_expr_ty - zonkTcType all_expr_ty
say $   post-zonk:  ++ pp zonked_expr_ty

Zonking walks over a type, returning a new type in which unification variables 
are replaced by the types they unified to.

Hope this helps

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.orgmailto:boun...@haskell.org] On Behalf Of 
p.k.f.holzensp...@utwente.nlmailto:p.k.f.holzensp...@utwente.nl
| Sent: 29 August 2013 14:42
| To: 
glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
| Subject: Question about correct GHC-API use for type checking (or
| zonking, or tidying)
|
| Dear GHC-ers,
|
| I'm working on building an interactive environment around the
| composition of expressions. Users can type in (i.e. give strings of)
| expressions and can then use these expressions to produce other
| expressions. I'm close to having a working GHC-API binding for this. The
| resulting types, however, still contain some things I don't quite
| understand. Any help would be appreciated.
|
| Below, I've included the function exprFromString which should parse,
| rename and typecheck strings to Id-things and give their type (although,
| ideally, the idType of said Id-thing should be the same as the type
| returned). This function lives in the IA (InterActive) monad; a monad
| that is a GhcMonad and can lift monadic computations in TcM into itself
| using liftTcM (which uses the initTcPrintErrors and
| setInteractiveContext functions similarly to TcRnDriver.tcRnExpr).
|
| Near the end of the function, debugging output is produced. This output
| confuses me slightly. Here is the output for the three inputs map (+1)
| [1..10], 5 and \\x - xfile:///\\x%20-%3e%20x:
|
|
| map (+1) [1..10]
|   pre-zonk:  forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   post-zonk: forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   idType:[b_c]
|   tidied:forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
| 5
|   pre-zonk:  forall a. GHC.Num.Num a_d = t_c
|   post-zonk: forall a. GHC.Num.Num a_d = t_c
|   idType:a_b
|   tidied:forall a. GHC.Num.Num a_d = t_c
| \x - x
|   pre-zonk:  forall t. t_e
|   post-zonk: forall t. t_e
|   idType:forall t. t - t
|   tidied:forall t. t_e
|
|
| The zonking and tidying part of the type-checking process are still a
| bit unclear to me and I suspect the problems arise there. It looks to me
| that the type variables in the quantifications are different ones from
| those in the pi/rho-types. I had expected the types to only contain the
| variables over which they are quantified, so e.g. in the map-example, I
| had expected forall b . (GHC.Enum.Enum b, GHC.Num.Num b) = [b]
|
| Can anyone explain what I'm missing?
|
| Regards,
| Philip
|
|
|
|
|
| exprFromString :: String - IA (Id,Type)
| exprFromString str = do
|   dfs - getDynFlags
|   let pp  = showSDoc dfs . ppr
|   pst - mkPState dfs buf $ newRealSrcLoc
|
| {- Parse -}
|   (loc,rdr_expr) - case unP parseStmt pst of
| PFailed span err - throwOneError (mkPlainErrMsg dfs span err)
| POk pst' (Just (L l (ExprStmt rdr_expr _ _ _))) - do
|   logWarningsReportErrors (getMessages pst')
|   return (l,rdr_expr)
| POk pst' thing - throw $ maybe EmptyParse (const
| NonExpressionParse) thing
|   liftTcM $ do
| fresh_it - freshName loc str
|
| {- Rename

Re: Question about correct GHC-API use for type checking (or zonking, or tidying)

[p.k.f.holzenspies]

I feel so unbelievably ignorant now. I thought with all the IORefs in the type 
checking process that zonking did this in these refs. Somehow I started 
thinking that some of these remained in SDocs, not thinking showSDoc is pure 
and results in a String, which holds no IORefs.

Does this mean that for the idType to come out correctly I should also zonk 
(AND BIND) the Id-value I return?

Ph.




Sent from Samsung Mobile



 Original message 
From: Simon Peyton-Jones simo...@microsoft.com
Date: 30/08/2013 18:25 (GMT+01:00)
To: Holzenspies, P.K.F. (EWI) 
p.k.f.holzensp...@utwente.nl,glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)


Haskell is a *functional* language.  Consider

say $   pre-zonk:   ++ pp all_expr_ty
zonkTcType all_expr_ty
say $   post-zonk:  ++ pp all_expr_ty

pp is a pure function; it is given the same input both times, so of course it 
produces the same output.

If you collect the result of zonkTcType you might have better luck, thus:

say $   pre-zonk:   ++ pp all_expr_ty
zonked_expr_ty - zonkTcType all_expr_ty
say $   post-zonk:  ++ pp zonked_expr_ty

Zonking walks over a type, returning a new type in which unification variables 
are replaced by the types they unified to.

Hope this helps

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of p.k.f.holzensp...@utwente.nl
| Sent: 29 August 2013 14:42
| To: glasgow-haskell-users@haskell.org
| Subject: Question about correct GHC-API use for type checking (or
| zonking, or tidying)
|
| Dear GHC-ers,
|
| I'm working on building an interactive environment around the
| composition of expressions. Users can type in (i.e. give strings of)
| expressions and can then use these expressions to produce other
| expressions. I'm close to having a working GHC-API binding for this. The
| resulting types, however, still contain some things I don't quite
| understand. Any help would be appreciated.
|
| Below, I've included the function exprFromString which should parse,
| rename and typecheck strings to Id-things and give their type (although,
| ideally, the idType of said Id-thing should be the same as the type
| returned). This function lives in the IA (InterActive) monad; a monad
| that is a GhcMonad and can lift monadic computations in TcM into itself
| using liftTcM (which uses the initTcPrintErrors and
| setInteractiveContext functions similarly to TcRnDriver.tcRnExpr).
|
| Near the end of the function, debugging output is produced. This output
| confuses me slightly. Here is the output for the three inputs map (+1)
| [1..10], 5 and \\x - x:
|
|
| map (+1) [1..10]
|   pre-zonk:  forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   post-zonk: forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   idType:[b_c]
|   tidied:forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
| 5
|   pre-zonk:  forall a. GHC.Num.Num a_d = t_c
|   post-zonk: forall a. GHC.Num.Num a_d = t_c
|   idType:a_b
|   tidied:forall a. GHC.Num.Num a_d = t_c
| \x - x
|   pre-zonk:  forall t. t_e
|   post-zonk: forall t. t_e
|   idType:forall t. t - t
|   tidied:forall t. t_e
|
|
| The zonking and tidying part of the type-checking process are still a
| bit unclear to me and I suspect the problems arise there. It looks to me
| that the type variables in the quantifications are different ones from
| those in the pi/rho-types. I had expected the types to only contain the
| variables over which they are quantified, so e.g. in the map-example, I
| had expected forall b . (GHC.Enum.Enum b, GHC.Num.Num b) = [b]
|
| Can anyone explain what I'm missing?
|
| Regards,
| Philip
|
|
|
|
|
| exprFromString :: String - IA (Id,Type)
| exprFromString str = do
|   dfs - getDynFlags
|   let pp  = showSDoc dfs . ppr
|   pst - mkPState dfs buf $ newRealSrcLoc
|
| {- Parse -}
|   (loc,rdr_expr) - case unP parseStmt pst of
| PFailed span err - throwOneError (mkPlainErrMsg dfs span err)
| POk pst' (Just (L l (ExprStmt rdr_expr _ _ _))) - do
|   logWarningsReportErrors (getMessages pst')
|   return (l,rdr_expr)
| POk pst' thing - throw $ maybe EmptyParse (const
| NonExpressionParse) thing
|   liftTcM $ do
| fresh_it - freshName loc str
|
| {- Rename -}
| (rn_expr, fvs) - checkNoErrs $ rnLExpr rdr_expr
|
| {- Typecheck -}
| let binds = mkBinds fresh_it rn_expr fvs
|
| (((_bnds,((_tc_expr,res_ty),id)),untch),lie) - captureConstraints .
| captureUntouchables $
|   tcLocalBinds binds ((,) $ tcInferRho rn_expr * tcLookupId
| fresh_it)
| ((qtvs, dicts, _bool, _evbinds), lie_top) - captureConstraints $
|   simplifyInfer True False [(fresh_it, res_ty)] (untch,lie)
|
| let all_expr_ty = mkForAllTys qtvs (mkPiTypes dicts res_ty)
| say str
| say $   pre-zonk:   ++ pp all_expr_ty
| zonkTcType all_expr_ty
| say $   post-zonk

RE: Question about correct GHC-API use for type checking (or zonking, or tidying)

[Simon Peyton-Jones]

Haskell is a *functional* language.  Consider

say $   pre-zonk:   ++ pp all_expr_ty
zonkTcType all_expr_ty
say $   post-zonk:  ++ pp all_expr_ty

pp is a pure function; it is given the same input both times, so of course it 
produces the same output.

If you collect the result of zonkTcType you might have better luck, thus:

say $   pre-zonk:   ++ pp all_expr_ty
zonked_expr_ty - zonkTcType all_expr_ty
say $   post-zonk:  ++ pp zonked_expr_ty

Zonking walks over a type, returning a new type in which unification variables 
are replaced by the types they unified to.

Hope this helps

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of p.k.f.holzensp...@utwente.nl
| Sent: 29 August 2013 14:42
| To: glasgow-haskell-users@haskell.org
| Subject: Question about correct GHC-API use for type checking (or
| zonking, or tidying)
| 
| Dear GHC-ers,
| 
| I'm working on building an interactive environment around the
| composition of expressions. Users can type in (i.e. give strings of)
| expressions and can then use these expressions to produce other
| expressions. I'm close to having a working GHC-API binding for this. The
| resulting types, however, still contain some things I don't quite
| understand. Any help would be appreciated.
| 
| Below, I've included the function exprFromString which should parse,
| rename and typecheck strings to Id-things and give their type (although,
| ideally, the idType of said Id-thing should be the same as the type
| returned). This function lives in the IA (InterActive) monad; a monad
| that is a GhcMonad and can lift monadic computations in TcM into itself
| using liftTcM (which uses the initTcPrintErrors and
| setInteractiveContext functions similarly to TcRnDriver.tcRnExpr).
| 
| Near the end of the function, debugging output is produced. This output
| confuses me slightly. Here is the output for the three inputs map (+1)
| [1..10], 5 and \\x - x:
| 
| 
| map (+1) [1..10]
|   pre-zonk:  forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   post-zonk: forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
|   idType:[b_c]
|   tidied:forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
| 5
|   pre-zonk:  forall a. GHC.Num.Num a_d = t_c
|   post-zonk: forall a. GHC.Num.Num a_d = t_c
|   idType:a_b
|   tidied:forall a. GHC.Num.Num a_d = t_c
| \x - x
|   pre-zonk:  forall t. t_e
|   post-zonk: forall t. t_e
|   idType:forall t. t - t
|   tidied:forall t. t_e
| 
| 
| The zonking and tidying part of the type-checking process are still a
| bit unclear to me and I suspect the problems arise there. It looks to me
| that the type variables in the quantifications are different ones from
| those in the pi/rho-types. I had expected the types to only contain the
| variables over which they are quantified, so e.g. in the map-example, I
| had expected forall b . (GHC.Enum.Enum b, GHC.Num.Num b) = [b]
| 
| Can anyone explain what I'm missing?
| 
| Regards,
| Philip
| 
| 
| 
| 
| 
| exprFromString :: String - IA (Id,Type)
| exprFromString str = do
|   dfs - getDynFlags
|   let pp  = showSDoc dfs . ppr
|   pst - mkPState dfs buf $ newRealSrcLoc
| 
| {- Parse -}
|   (loc,rdr_expr) - case unP parseStmt pst of
| PFailed span err - throwOneError (mkPlainErrMsg dfs span err)
| POk pst' (Just (L l (ExprStmt rdr_expr _ _ _))) - do
|   logWarningsReportErrors (getMessages pst')
|   return (l,rdr_expr)
| POk pst' thing - throw $ maybe EmptyParse (const
| NonExpressionParse) thing
|   liftTcM $ do
| fresh_it - freshName loc str
| 
| {- Rename -}
| (rn_expr, fvs) - checkNoErrs $ rnLExpr rdr_expr
| 
| {- Typecheck -}
| let binds = mkBinds fresh_it rn_expr fvs
| 
| (((_bnds,((_tc_expr,res_ty),id)),untch),lie) - captureConstraints .
| captureUntouchables $
|   tcLocalBinds binds ((,) $ tcInferRho rn_expr * tcLookupId
| fresh_it)
| ((qtvs, dicts, _bool, _evbinds), lie_top) - captureConstraints $
|   simplifyInfer True False [(fresh_it, res_ty)] (untch,lie)
| 
| let all_expr_ty = mkForAllTys qtvs (mkPiTypes dicts res_ty)
| say str
| say $   pre-zonk:   ++ pp all_expr_ty
| zonkTcType all_expr_ty
| say $   post-zonk:  ++ pp all_expr_ty
| say $   idType: ++ pp (idType id)
| say $   tidied: ++ pp (tidyTopType all_expr_ty)
| 
| return (id,all_expr_ty)
|   where
|   say = liftIO . putStrLn
|   buf = stringToStringBuffer str
|   freshName loc str = (\u - mkInternalName u name loc) $ newUnique
| where
| name = mkOccNameFS varName $ fsLit $ it ++ show (lineOf loc)
| isVarChar c = isAlphaNum c || c == '_' || c == '\''
| lineOf (RealSrcSpan s) = srcSpanStartLine s
| lineOf _ = -1
| 
|   mkBinds :: Name - LHsExpr Name - FreeVars - HsLocalBinds Name
|   mkBinds nm e@(L l _) fvs = HsValBinds $ ValBindsOut [(NonRecursive,
| unitBag the_bind)] []
| where
| the_bind = L l (mkTopFunBind

Question about correct GHC-API use for type checking (or zonking, or tidying)

[p.k.f.holzenspies]

Dear GHC-ers,

I'm working on building an interactive environment around the composition of 
expressions. Users can type in (i.e. give strings of) expressions and can then 
use these expressions to produce other expressions. I'm close to having a 
working GHC-API binding for this. The resulting types, however, still contain 
some things I don't quite understand. Any help would be appreciated.

Below, I've included the function exprFromString which should parse, rename and 
typecheck strings to Id-things and give their type (although, ideally, the 
idType of said Id-thing should be the same as the type returned). This function 
lives in the IA (InterActive) monad; a monad that is a GhcMonad and can lift 
monadic computations in TcM into itself using liftTcM (which uses the 
initTcPrintErrors and setInteractiveContext functions similarly to 
TcRnDriver.tcRnExpr).

Near the end of the function, debugging output is produced. This output 
confuses me slightly. Here is the output for the three inputs map (+1) 
[1..10], 5 and \\x - x:


map (+1) [1..10]
  pre-zonk:  forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
  post-zonk: forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
  idType:[b_c]
  tidied:forall b. (GHC.Enum.Enum b_i, GHC.Num.Num b_i) = [b_i]
5
  pre-zonk:  forall a. GHC.Num.Num a_d = t_c
  post-zonk: forall a. GHC.Num.Num a_d = t_c
  idType:a_b
  tidied:forall a. GHC.Num.Num a_d = t_c
\x - x
  pre-zonk:  forall t. t_e
  post-zonk: forall t. t_e
  idType:forall t. t - t
  tidied:forall t. t_e


The zonking and tidying part of the type-checking process are still a bit 
unclear to me and I suspect the problems arise there. It looks to me that the 
type variables in the quantifications are different ones from those in the 
pi/rho-types. I had expected the types to only contain the variables over which 
they are quantified, so e.g. in the map-example, I had expected forall b . 
(GHC.Enum.Enum b, GHC.Num.Num b) = [b]

Can anyone explain what I'm missing?

Regards,
Philip





exprFromString :: String - IA (Id,Type)
exprFromString str = do
  dfs - getDynFlags
  let pp  = showSDoc dfs . ppr
  pst - mkPState dfs buf $ newRealSrcLoc

{- Parse -}
  (loc,rdr_expr) - case unP parseStmt pst of
PFailed span err - throwOneError (mkPlainErrMsg dfs span err)
POk pst' (Just (L l (ExprStmt rdr_expr _ _ _))) - do
  logWarningsReportErrors (getMessages pst')
  return (l,rdr_expr)
POk pst' thing - throw $ maybe EmptyParse (const NonExpressionParse) thing
  liftTcM $ do
fresh_it - freshName loc str

{- Rename -}
(rn_expr, fvs) - checkNoErrs $ rnLExpr rdr_expr

{- Typecheck -}
let binds = mkBinds fresh_it rn_expr fvs

(((_bnds,((_tc_expr,res_ty),id)),untch),lie) - captureConstraints . 
captureUntouchables $
  tcLocalBinds binds ((,) $ tcInferRho rn_expr * tcLookupId fresh_it)
((qtvs, dicts, _bool, _evbinds), lie_top) - captureConstraints $
  simplifyInfer True False [(fresh_it, res_ty)] (untch,lie)

let all_expr_ty = mkForAllTys qtvs (mkPiTypes dicts res_ty)
say str
say $   pre-zonk:   ++ pp all_expr_ty
zonkTcType all_expr_ty
say $   post-zonk:  ++ pp all_expr_ty
say $   idType: ++ pp (idType id)
say $   tidied: ++ pp (tidyTopType all_expr_ty)

return (id,all_expr_ty)
  where
  say = liftIO . putStrLn
  buf = stringToStringBuffer str
  freshName loc str = (\u - mkInternalName u name loc) $ newUnique
where
name = mkOccNameFS varName $ fsLit $ it ++ show (lineOf loc)
isVarChar c = isAlphaNum c || c == '_' || c == '\''
lineOf (RealSrcSpan s) = srcSpanStartLine s
lineOf _ = -1

  mkBinds :: Name - LHsExpr Name - FreeVars - HsLocalBinds Name
  mkBinds nm e@(L l _) fvs = HsValBinds $ ValBindsOut [(NonRecursive, unitBag 
the_bind)] []
where
the_bind = L l (mkTopFunBind (L l nm) [mkMatch [] e emptyLocalBinds]) { 
bind_fvs = fvs }



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] A question about laziness and performance in document serialization.

[Roman Cheplyaka]

* Kyle Hanson hanoo...@gmail.com [2013-08-20 18:23:48-0700]
 So I am not entirely clear on how to optimize for performance for lazy
 bytestrings.
 
 Currently I have a (Lazy) Map that contains large BSON values (more than
 1mb when serialized each). I can serialize BSON documents to Lazy
 ByteStrings using Data.Binary.runPut. I then write this bytestring to a
 socket using Network.Socket.ByteString.Lazy.
 
 My question is this, if the Map object doesn't change (no updates) when it
 serializes the same document to the socket 2x in a row, does it re-evaluate
 the whole BSON value and convert it to a bytestring each time?

Yes.

 Lets say I wanted to have a cache of bytestings so I have another Map
 object that has the serialized bytestrings that I populate it with every
 time the original BSON Map changes. Should the map be strict or lazy?

This is the wrong question. The right question is, do you want the
values be strict (evaluated) or lazy (kept unevaluated until required)?

If you want values to be lazy, then you have to use the lazy Map.

If you want values to be strict, then you may either use the strict Map,
or still use the lazy Map but make sure that the values are evaluated
when you place them in the map. Using the strict Map is probably a
better idea, but the lazy Map lets you have finer control over what is
lazy and what is forced (should you need it).

Note that the lazy bytestring is just a lazy list of strict bytestrings.
Even placing it in the strict map wouldn't force its evaluation.

 Should the bytestrings it stores be strict or lazy?

For a cache, it makes sense to store strict bytestrings (unless they are
so large that it may be hard to allocate that much of contiguous space).

Lazy bytestrings are useful for streaming, when you use a chunk and then
discard it.

Using strict bytestrings doesn't imply that you want to store them
evaluated. Depending on your circumstances, it may be a good idea to
store strict bytestrings lazily, so that they do not take space and time
until they are requested for the first time.

Simply operating with the words lazy and strict may be very confusing,
since they refer to different things in different contexts. Every time
you read that something is lazy or strict, try to decipher it in terms
of the basic evaluation properties.

HTH,
Roman


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] A question about laziness and performance in document serialization.

[Kyle Hanson]

So I am not entirely clear on how to optimize for performance for lazy
bytestrings.

Currently I have a (Lazy) Map that contains large BSON values (more than
1mb when serialized each). I can serialize BSON documents to Lazy
ByteStrings using Data.Binary.runPut. I then write this bytestring to a
socket using Network.Socket.ByteString.Lazy.

My question is this, if the Map object doesn't change (no updates) when it
serializes the same document to the socket 2x in a row, does it re-evaluate
the whole BSON value and convert it to a bytestring each time?

Lets say I wanted to have a cache of bytestings so I have another Map
object that has the serialized bytestrings that I populate it with every
time the original BSON Map changes. Should the map be strict or lazy?
Should the bytestrings it stores be strict or lazy?

Any help in understanding laziness would be appreciated.

--
Kyle Hanson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Question about `compileToCoreModule`

[Daniel F]

Hi, everyone, I have a question about `compileToCoreModule` function from
the GHC module.

I noticed that the following code not just outputs the Core code, but also
produces object files and a linked executable (in case when 'test.hs' is a
program):

---
module Main where

import DynFlags
import GHC
import GHC.Paths
import MonadUtils
import Outputable

main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags  dflags
cm - compileToCoreModule test.hs
output cm

-- | Outputs any value that can be pretty-printed using the default style
output :: (GhcMonad m, MonadIO m) = Outputable a = a - m ()
output a = do
dfs - getSessionDynFlags
let style = defaultUserStyle
let cntx = initSDocContext dfs style
liftIO $ print $ runSDoc (ppr a) cntx
-


I thought this was strange and looked up the source of
'compileToCoreModule', and indeed, it calls 'load LoadAllTargets'. So my
question is, why is it necessary to do so? I had the impression that
compiling Haskell to Core is a step that precedes compiling to the actual
binary.

NB: I tried setting `ghcLink' and `hscTarget' options in dynflags to
`NoLink' and `HscNothing' respectively, but that resulted in somewhat weird
Core:

$ cat test.hs
module Test (test) where

test :: Int
test = 123

test2 :: String
test2 = Hi

$ ./testcore
%module main:Test (Safe-Inferred) [(reF, Identifier `Test.test')]
Test.test :: GHC.Types.Int
[LclIdX]
Test.test = GHC.Types.I# 123

$ ./testcore-nolinknothing
%module main:Test (Safe-Inferred) []


Thanks.

-- 
Sincerely yours,
-- Daniil Frumin
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] haskell-gtk entry question

[Claude Heiland-Allen]

Hi Brian,

On 25/07/13 04:14, bri...@aracnet.com wrote:
 This should be simple, and I thought it had it working, but I've broken it 
 and can't figure out why.
 
 What I want is to invoke the callback whenever the user activates and entry 
 in a dialogbox, so I did both this :

Not sure what you mean by dialogbox here.  A complete (but small)
example would help.

   Gtk.on entry Gtk.entryActivate (boxHandler entry)

Perhaps it's a terminology confusion: in GTK, activate for an entry
means pressing return key.  This program works fine for me, pressing
return prints the text I entered in the box:

8
import Graphics.UI.Gtk

main :: IO ()
main = do
  initGUI
  window - windowNew
  entry - entryNew
  set window [ containerBorderWidth := 10, containerChild := entry ]
  entry `on` entryActivate $ putStrLn = entryGetText entry
  onDestroy window mainQuit
  widgetShowAll window
  mainGUI
8

 (I believe this supercedes the previous method which was onEntryActivate)
 
 and this
 
   Gtk.on entry Gtk.entryPreeditChanged (boxHandler entry)
 
 however neither method will invoke the callback.  The program compiles and 
 works just fine, it's just that the callback never runs.

Maybe you instead mean to do something when the widget is focussed for
input?

8
import Control.Monad.Trans (liftIO)
...
  entry `on` focusInEvent $ tryEvent $ liftIO $ putStrLn focusInEvent
8


Claude
-- 
http://mathr.co.uk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell-gtk entry question

[briand]

On Sat, 27 Jul 2013 15:44:44 +0100
Claude Heiland-Allen cla...@mathr.co.uk wrote:

 Perhaps it's a terminology confusion: in GTK, activate for an entry
 means pressing return key.  This program works fine for me, pressing
 return prints the text I entered in the box:
 
 8
 import Graphics.UI.Gtk
 
 main :: IO ()
 main = do
   initGUI
   window - windowNew
   entry - entryNew
   set window [ containerBorderWidth := 10, containerChild := entry ]
   entry `on` entryActivate $ putStrLn = entryGetText entry
   onDestroy window mainQuit
   widgetShowAll window
   mainGUI
 8

yes that's part of the problem - I thought that tabbing through the fields 
should be an activate event.  still I had some other problem, and I'm not 
sure what it was.  however thanks to your example I now have the dialog working 
as it should.

thanks very much !

Brian


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Parsec question

[C K Kashyap]

Dear Cafe,

I am trying to implement[1] parsec in go using the Monadic Parser
Combinators paper [2] . I've been able to implement plus bind and
many
While doing the implementation - I looked at bind closely

bind :: Parser a - (a - Parser b) - Parser b
p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]

I wondered if the result needs the complete list - wouldn't just the first
successful value suffice?
Perhaps -
p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]

Will this miss out matches?


Regards,
Kashyap

[1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
[2] Monadic Parser Combinators: Graham Hutton, Erik Meijer
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec question

[Roman Cheplyaka]

Think about this: if you always take only the first element, why do you
need lists at all?

Roman

* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
 Dear Cafe,
 
 I am trying to implement[1] parsec in go using the Monadic Parser
 Combinators paper [2] . I've been able to implement plus bind and
 many
 While doing the implementation - I looked at bind closely
 
 bind :: Parser a - (a - Parser b) - Parser b
 p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]
 
 I wondered if the result needs the complete list - wouldn't just the first
 successful value suffice?
 Perhaps -
 p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]
 
 Will this miss out matches?
 
 
 Regards,
 Kashyap
 
 [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
 [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer

 ___
 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] Parsec question

[Kashyap CK]

There is reference in the paper that empty list indicates failure...so
could we just use it like Maybe? I'd like it very much if I could get
an example of a missed match by not using the complete match.

regards,
Kashyap

Sent from my Windows Phone
From: Roman Cheplyaka
Sent: 24/07/2013 8:19 PM
To: C K Kashyap
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you
need lists at all?

Roman

* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
 Dear Cafe,

 I am trying to implement[1] parsec in go using the Monadic Parser
 Combinators paper [2] . I've been able to implement plus bind and
 many
 While doing the implementation - I looked at bind closely

 bind :: Parser a - (a - Parser b) - Parser b
 p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]

 I wondered if the result needs the complete list - wouldn't just the first
 successful value suffice?
 Perhaps -
 p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]

 Will this miss out matches?


 Regards,
 Kashyap

 [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
 [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer

 ___
 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] Parsec question

[Kyle Miller]

Because of laziness, you do in a sense only take the first successful
value.  When I've made parser combinators for Python before, I've used
either generators or exceptions to get lazy evaluation, since computing the
whole list of possibilities for each bind would ruin the running time of
the algorithm (or make it never terminate).  From your go code, it looks
like you're evaluating the entire list.

The bind you give looks like it's for a backtracking parser.  For
non-backtracking, though, I believe it would be possible to use Maybe.
 Parsec has a different bind operator which only lets backtracking happen
when you explicitly allow it with 'try'.

Assuming you're wanting a full backtracking parser, here's a counterexample
for the take 1:

needsList = do
  v - many (char 'a')
  a - return v  -- just to make sure the take 1 bind happens at least
once before the next step
  guard $ length a == 3
  return a

If my input string is , then many (char 'a') will produce matches of
'', 'a', 'aa', 'aaa', and '', but the bind will probably force the
incorrect one of these before it reaches the guard.

I can't guarantee this is any good, and I haven't looked at it in a while,
but at [1] I have an example of using exceptions to get a parsec-like
backtracking-when-explicitly-allowed parser.  I was planning on writing an
article about how to do this technique, but I never got around to it.

Kyle

[1] https://github.com/kmill/metaview/blob/master/src/mparserlib/parser.py


On Wed, Jul 24, 2013 at 10:26 AM, C K Kashyap ckkash...@gmail.com wrote:

 Dear Cafe,

 I am trying to implement[1] parsec in go using the Monadic Parser
 Combinators paper [2] . I've been able to implement plus bind and
 many
 While doing the implementation - I looked at bind closely

 bind :: Parser a - (a - Parser b) - Parser b
 p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]

 I wondered if the result needs the complete list - wouldn't just the first
 successful value suffice?
 Perhaps -
 p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]

 Will this miss out matches?


 Regards,
 Kashyap

 [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
 [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer

 ___
 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] Parsec question

[Roman Cheplyaka]

To construct such an example, you have to ask yourself: when can we get a
list of more than one element?

Consider this:

  a = char 'a'

  ((a  a) | a)  a

Suppose that our input is aa. The result of ((a  a) | a) would be
the list

  [('a', ), ('a', a)]

If you proceed with the first element of the list, the overall parse
will fail. It can only succeed if you then try the second element.

By the way, you shouldn't confuse Parsec (the library) with the general
concept of parser combinators or the implementation from the paper you
reference. The above parse would fail in Parsec as well, despite the
fact that Parsec allows backtracking.

Roman

* Kashyap CK ckkash...@gmail.com [2013-07-24 08:38:53-0700]
 There is reference in the paper that empty list indicates failure...so
 could we just use it like Maybe? I'd like it very much if I could get
 an example of a missed match by not using the complete match.
 
 regards,
 Kashyap
 
 Sent from my Windows Phone
 From: Roman Cheplyaka
 Sent: 24/07/2013 8:19 PM
 To: C K Kashyap
 Cc: Haskell Cafe
 Subject: Re: [Haskell-cafe] Parsec question
 Think about this: if you always take only the first element, why do you
 need lists at all?
 
 Roman
 
 * C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
  Dear Cafe,
 
  I am trying to implement[1] parsec in go using the Monadic Parser
  Combinators paper [2] . I've been able to implement plus bind and
  many
  While doing the implementation - I looked at bind closely
 
  bind :: Parser a - (a - Parser b) - Parser b
  p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]
 
  I wondered if the result needs the complete list - wouldn't just the first
  successful value suffice?
  Perhaps -
  p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]
 
  Will this miss out matches?
 
 
  Regards,
  Kashyap
 
  [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
  [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer
 
  ___
  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

[Haskell-cafe] haskell-gtk entry question

[briand]

Hello all,

This should be simple, and I thought it had it working, but I've broken it and 
can't figure out why.

What I want is to invoke the callback whenever the user activates and entry in 
a dialogbox, so I did both this :

  Gtk.on entry Gtk.entryActivate (boxHandler entry)

(I believe this supercedes the previous method which was onEntryActivate)

and this

  Gtk.on entry Gtk.entryPreeditChanged (boxHandler entry)


however neither method will invoke the callback.  The program compiles and 
works just fine, it's just that the callback never runs.

Thank you,

Brian


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec question

[C K Kashyap]

Thanks Kyle,

My initial implementation was evaluating the whole list - the current one
though just returns the first successful result. Anyway, I think I need the
backtracking - I would want the aaa as the result :)

I will now explore using go-routines to implement laziness.

Thank you so much for your input.

Regards,
Kashyap




On Thu, Jul 25, 2013 at 1:44 AM, Kyle Miller kmill31...@gmail.com wrote:

 Because of laziness, you do in a sense only take the first successful
 value.  When I've made parser combinators for Python before, I've used
 either generators or exceptions to get lazy evaluation, since computing the
 whole list of possibilities for each bind would ruin the running time of
 the algorithm (or make it never terminate).  From your go code, it looks
 like you're evaluating the entire list.

 The bind you give looks like it's for a backtracking parser.  For
 non-backtracking, though, I believe it would be possible to use Maybe.
  Parsec has a different bind operator which only lets backtracking happen
 when you explicitly allow it with 'try'.

 Assuming you're wanting a full backtracking parser, here's a
 counterexample for the take 1:

 needsList = do
   v - many (char 'a')
   a - return v  -- just to make sure the take 1 bind happens at least
 once before the next step
   guard $ length a == 3
   return a

 If my input string is , then many (char 'a') will produce matches of
 '', 'a', 'aa', 'aaa', and '', but the bind will probably force the
 incorrect one of these before it reaches the guard.

 I can't guarantee this is any good, and I haven't looked at it in a while,
 but at [1] I have an example of using exceptions to get a parsec-like
 backtracking-when-explicitly-allowed parser.  I was planning on writing an
 article about how to do this technique, but I never got around to it.

 Kyle

 [1] https://github.com/kmill/metaview/blob/master/src/mparserlib/parser.py


 On Wed, Jul 24, 2013 at 10:26 AM, C K Kashyap ckkash...@gmail.com wrote:

 Dear Cafe,

 I am trying to implement[1] parsec in go using the Monadic Parser
 Combinators paper [2] . I've been able to implement plus bind and
 many
 While doing the implementation - I looked at bind closely

 bind :: Parser a - (a - Parser b) - Parser b
 p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]

 I wondered if the result needs the complete list - wouldn't just the
 first successful value suffice?
 Perhaps -
 p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]

 Will this miss out matches?


 Regards,
 Kashyap

 [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
 [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer

 ___
 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] Parsec question

[C K Kashyap]

Thanks Roman .. I'll try and implement laziness to retain the whole list.
Regards,
Kashyap


On Thu, Jul 25, 2013 at 3:41 AM, Roman Cheplyaka r...@ro-che.info wrote:

 To construct such an example, you have to ask yourself: when can we get a
 list of more than one element?

 Consider this:

   a = char 'a'

   ((a  a) | a)  a

 Suppose that our input is aa. The result of ((a  a) | a) would be
 the list

   [('a', ), ('a', a)]

 If you proceed with the first element of the list, the overall parse
 will fail. It can only succeed if you then try the second element.

 By the way, you shouldn't confuse Parsec (the library) with the general
 concept of parser combinators or the implementation from the paper you
 reference. The above parse would fail in Parsec as well, despite the
 fact that Parsec allows backtracking.

 Roman

 * Kashyap CK ckkash...@gmail.com [2013-07-24 08:38:53-0700]
  There is reference in the paper that empty list indicates failure...so
  could we just use it like Maybe? I'd like it very much if I could get
  an example of a missed match by not using the complete match.
 
  regards,
  Kashyap
 
  Sent from my Windows Phone
  From: Roman Cheplyaka
  Sent: 24/07/2013 8:19 PM
  To: C K Kashyap
  Cc: Haskell Cafe
  Subject: Re: [Haskell-cafe] Parsec question
  Think about this: if you always take only the first element, why do you
  need lists at all?
 
  Roman
 
  * C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
   Dear Cafe,
  
   I am trying to implement[1] parsec in go using the Monadic Parser
   Combinators paper [2] . I've been able to implement plus bind and
   many
   While doing the implementation - I looked at bind closely
  
   bind :: Parser a - (a - Parser b) - Parser b
   p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]
  
   I wondered if the result needs the complete list - wouldn't just the
 first
   successful value suffice?
   Perhaps -
   p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]
  
   Will this miss out matches?
  
  
   Regards,
   Kashyap
  
   [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
   [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer
 
   ___
   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] Harder Question - Chapter 4 - 4.12 - haskell the craft of functional programming - Second Edition

[Anton Nikishaev]

Manoel Menezes manoel.menezes...@gmail.com writes:

 Hi everybody!

 I am trying to solve the question for a long time:

 [4.12 Harder] Find out the maximum number of pieces we can get by
 making a given number of flat (that is planar) cuts through a solid
 block. It is not the same answer as we calculated for straight-line
 cuts of a flat piece of paper.    I find out that this function has
 the following results:

 f 0 = 1
 f 1 = 2
 f 2 = 4
 f 3 = 8

 That is, from 0 to 3, the flat cuts all the pieces in two other
 pieces, so the number of pieces is doubled.

 But, starting from f 4, the flat can not cuts all the pieces, in case
 of f 4, the flat can cut 6 out of the 8 pieces, resulting in 12 pieces
 plus 2 pieces 2 = 14 pieces.

It can cut 7, so it is 2*7+1.

Forget about block borders and suppose you have n-1 planes and add a new
place.  It will cut each n-1 planes.  Now look at this new plane with
intersection lines (n-1 ones) in it. Each region in plane adds one new
3D piece, so

  F(0) = 1;
  F(n) = F(n-1) + P(n-1),

where P(n) is max number of pieces slicing plane with n cuts.

Spoiler: cake numbers



-- 
lelf




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Harder Question - Chapter 4 - 4.12 - haskell the craft of functional programming - Second Edition

[Manoel Menezes]

Hi everybody!

I am trying to solve the question for a long time:

[*4.12 Harder] Find out the maximum number of pieces we can get by making a
given*
*number of flat (that is planar) cuts through a solid block. It is not the
same*
*answer as we calculated for straight-line cuts of a flat piece of paper.*

I find out that this function has the following results:

f 0 = 1
f 1 = 2
f 2 = 4
f 3 = 8

That is, from 0 to 3, the flat cuts all the pieces in two other pieces, so
the number of pieces is doubled.

But, starting from f 4, the flat can not cuts all the pieces, in case of f
4, the flat can cut 6 out of the 8 pieces, resulting
in 12 pieces plus 2 pieces 2 = 14 pieces.

But I can not reach a general case.

Can anybody help me to find out the solution?

Thank you very much!

Manoel Menezes.
__
 Manoel Messias da Silva Menezes Jr
 M.Sc.in Computer Science
 Federal University of Pernambuco
 System Analyst - Petrobras
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] newbie question about Functional dependencies conflict between instance declarations:.....

[Nicholls, Mark]

Hello,

I largely don't know what I'm doing or even trying to do, it is a voyage into 
the unknownbutif I go...

 {-# LANGUAGE MultiParamTypeClasses #-}
 {-# LANGUAGE FunctionalDependencies #-}
 {-# LANGUAGE FlexibleInstances #-}
 {-# LANGUAGE UndecidableInstances #-}

 class Foo x y | x - y, y - x
 instance Foo Integer Integer

That seems to workand my head seems to say...your created some sort of 
binary relation between 2 types...and made Integer,Integer a member of it...

Something like that anyway

Then I go

 data Bar

 instance Foo Bar x

Error!but I'm think I understand thisI can't claim that Bar,x is a 
member of Foo and Integer,Integer is member of Foo and preserve my functional 
dependencies, because Bar,Integer is now a member of Foo..

Bad programmer...


So how I naively go


 class NotAnInteger a

 instance (NotAnInteger x) = Foo Bar x

I haven't declared integer to be NotAnIntegerso (in a closed 
world)this would seem to exclude the contradictionbut...


Functional dependencies conflict between instance declarations:
  instance Foo Integer Integer -- Defined at liam1.lhs:7:12
  instance NotAnInteger x = Foo Bar x -- Defined at liam1.lhs:13:12

So

i)I clearly don't understand something about the type 
system.

ii)   I don't know how to restrict type variables in instance 
declarationsi.e. how do I use the notion of Foo across different 
combinations of types, without them colliding.







CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright 
(and other intellectual property rights). If you are not the intended recipient 
please e-mail the sender and then delete the email and any attached files 
immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any 
attachments are virus free, it is your responsibility to ensure that this 
message and any attachments are virus free and do not affect your systems / 
data.

Communicating by email is not 100% secure and carries risks such as delay, data 
corruption, non-delivery, wrongful interception and unauthorised amendment. If 
you communicate with us by e-mail, you acknowledge and assume these risks, and 
you agree to take appropriate measures to minimise these risks when e-mailing 
us.

MTV Networks International, MTV Networks UK  Ireland, Greenhouse, Nickelodeon 
Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be 
Viacom, Viacom International Media Networks and VIMN and Comedy Central are all 
trading names of MTV Networks Europe.  MTV Networks Europe is a partnership 
between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for 
service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie question about Functional dependencies conflict between instance declarations:.....

[Erik Hesselink]

The constraint on an instance never influences which instance is
selected. So as far as instance selection goes, 'instance Foo x' and
'instance C x = Foo x' are the same. The constraint is only checked
after the instance is selected.

Erik

On Fri, Jul 5, 2013 at 2:43 PM, Nicholls, Mark nicholls.m...@vimn.com wrote:
 Hello,



 I largely don’t know what I’m doing or even trying to do, it is a voyage
 into the unknown….but….if I go…



 {-# LANGUAGE MultiParamTypeClasses #-}

 {-# LANGUAGE FunctionalDependencies #-}

 {-# LANGUAGE FlexibleInstances #-}

 {-# LANGUAGE UndecidableInstances #-}



 class Foo x y | x - y, y - x

 instance Foo Integer Integer



 That seems to work….and my head seems to say…your created some sort of
 binary relation between 2 types…and made Integer,Integer a member of it…



 Something like that anyway….



 Then I go….



 data Bar



 instance Foo Bar x



 Error!but I’m think I understand this….I can’t claim that Bar,x is a
 member of Foo and Integer,Integer is member of Foo and preserve my
 functional dependencies, because Bar,Integer is now a member of Foo..



 Bad programmer…….





 So how I naively go….





 class NotAnInteger a



 instance (NotAnInteger x) = Foo Bar x



 I haven’t declared integer to be “NotAnInteger”….so (in a closed
 world)….this would seem to exclude the contradiction….but…





 Functional dependencies conflict between instance declarations:

   instance Foo Integer Integer -- Defined at liam1.lhs:7:12

   instance NotAnInteger x = Foo Bar x -- Defined at liam1.lhs:13:12



 So

 i)I clearly don’t understand something about the type
 system.

 ii)   I don’t know how to restrict type variables in
 instance declarations….i.e. how do I use the notion of “Foo” across
 different combinations of types, without them colliding.

















 CONFIDENTIALITY NOTICE

 This e-mail (and any attached files) is confidential and protected by
 copyright (and other intellectual property rights). If you are not the
 intended recipient please e-mail the sender and then delete the email and
 any attached files immediately. Any further use or dissemination is
 prohibited.

 While MTV Networks Europe has taken steps to ensure that this email and any
 attachments are virus free, it is your responsibility to ensure that this
 message and any attachments are virus free and do not affect your systems /
 data.

 Communicating by email is not 100% secure and carries risks such as delay,
 data corruption, non-delivery, wrongful interception and unauthorised
 amendment. If you communicate with us by e-mail, you acknowledge and assume
 these risks, and you agree to take appropriate measures to minimise these
 risks when e-mailing us.

 MTV Networks International, MTV Networks UK  Ireland, Greenhouse,
 Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions
 International, Be Viacom, Viacom International Media Networks and VIMN and
 Comedy Central are all trading names of MTV Networks Europe.  MTV Networks
 Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks
 Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent,
 London, NW1 8TT.


 ___
 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] newbie question about Functional dependencies conflict between instance declarations:.....

[Tikhon Jelvis]

You're running into the open worldassumption--anybody could come along
and make Integer part of your NotAnInteger class, and there's nothing you
can do to stop them. This is a design tradeoff for typeclasses: typeclass
instances are always global and are exported to all other modules you use.
This means you cannot ensure a type is *not* part of a typeclass. (Or, at
the very least, you can't convince GHC of this fact.)

For more information about this, take a look at the following StackOverflow
question:
http://stackoverflow.com/questions/8728596/explicitly-import-instances
On Jul 5, 2013 8:47 AM, Nicholls, Mark nicholls.m...@vimn.com wrote:

  Hello,

 ** **

 I largely don’t know what I’m doing or even trying to do, it is a voyage
 into the unknown….but….if I go…

 ** **

  {-# LANGUAGE MultiParamTypeClasses #-}

  {-# LANGUAGE FunctionalDependencies #-}

  {-# LANGUAGE FlexibleInstances #-}

  {-# LANGUAGE UndecidableInstances #-}

 ** **

  class Foo x y | x - y, y - x

  instance Foo Integer Integer

 ** **

 That seems to work….and my head seems to say…your created some sort of
 binary relation between 2 types…and made Integer,Integer a member of it…
 

 ** **

 Something like that anyway….

 ** **

 Then I go….

 ** **

  data Bar

 ** **

  instance Foo Bar x

 ** **

 Error!but I’m think I understand this….I can’t claim that Bar,x is a
 member of Foo and Integer,Integer is member of Foo and preserve my
 functional dependencies, because Bar,Integer is now a member of Foo..***
 *

 ** **

 Bad programmer…….

 ** **

 ** **

 So how I naively go….

 ** **

 ** **

  class NotAnInteger a

 ** **

  instance (NotAnInteger x) = Foo Bar x

 ** **

 I haven’t declared integer to be “NotAnInteger”….so (in a closed
 world)….this would seem to exclude the contradiction….but…

 ** **

 ** **

 Functional dependencies conflict between instance declarations:

   instance Foo Integer Integer -- Defined at liam1.lhs:7:12

   instance NotAnInteger x = Foo Bar x -- Defined at liam1.lhs:13:12**
 **

 ** **

 So 

 **i)**I clearly don’t understand something about the
 type system.

 **ii)   **I don’t know how to restrict type variables in
 instance declarations….i.e. how do I use the notion of “Foo” across
 different combinations of types, without them colliding.

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **



 CONFIDENTIALITY NOTICE

 This e-mail (and any attached files) is confidential and protected by
 copyright (and other intellectual property rights). If you are not the
 intended recipient please e-mail the sender and then delete the email and
 any attached files immediately. Any further use or dissemination is
 prohibited.

 While MTV Networks Europe has taken steps to ensure that this email and
 any attachments are virus free, it is your responsibility to ensure that
 this message and any attachments are virus free and do not affect your
 systems / data.

 Communicating by email is not 100% secure and carries risks such as delay,
 data corruption, non-delivery, wrongful interception and unauthorised
 amendment. If you communicate with us by e-mail, you acknowledge and assume
 these risks, and you agree to take appropriate measures to minimise these
 risks when e-mailing us.

 MTV Networks International, MTV Networks UK  Ireland, Greenhouse,
 Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions
 International, Be Viacom, Viacom International Media Networks and VIMN and
 Comedy Central are all trading names of MTV Networks Europe.  MTV Networks
 Europe is a partnership between MTV Networks Europe Inc. and Viacom
 Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley
 Crescent, London, NW1 8TT.

 ___
 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] newbie question about Functional dependencies conflict between instance declarations:.....

[Nicholls, Mark]

Ah

So it isn't a closed world

So how do I stop my instances clashing?

The x in

instance Foo Bar x

is never intended to be Integer.



Mark Nicholls | Lead broadcast  corporate architect, Programmes  Development 
- Viacom International Media Networks
A: 17-29 Hawley Crescent London NW1 8TT | e: 
nicholls.m...@vimn.commailto:m...@vimn.com T: +44 (0)203 580 2223

[Description: cid:image001.png@01CD488D.9204D030]

From: Tikhon Jelvis [mailto:tik...@jelv.is]
Sent: 05 July 2013 2:08 PM
To: Nicholls, Mark
Cc: haskell-cafe
Subject: Re: [Haskell-cafe] newbie question about Functional dependencies 
conflict between instance declarations:.


You're running into the open worldassumption--anybody could come along and 
make Integer part of your NotAnInteger class, and there's nothing you can do to 
stop them. This is a design tradeoff for typeclasses: typeclass instances are 
always global and are exported to all other modules you use. This means you 
cannot ensure a type is *not* part of a typeclass. (Or, at the very least, you 
can't convince GHC of this fact.)

For more information about this, take a look at the following StackOverflow 
question: http://stackoverflow.com/questions/8728596/explicitly-import-instances
On Jul 5, 2013 8:47 AM, Nicholls, Mark 
nicholls.m...@vimn.commailto:nicholls.m...@vimn.com wrote:
Hello,

I largely don't know what I'm doing or even trying to do, it is a voyage into 
the unknownbutif I go...

 {-# LANGUAGE MultiParamTypeClasses #-}
 {-# LANGUAGE FunctionalDependencies #-}
 {-# LANGUAGE FlexibleInstances #-}
 {-# LANGUAGE UndecidableInstances #-}

 class Foo x y | x - y, y - x
 instance Foo Integer Integer

That seems to workand my head seems to say...your created some sort of 
binary relation between 2 types...and made Integer,Integer a member of it...

Something like that anyway

Then I go

 data Bar

 instance Foo Bar x

Error!but I'm think I understand thisI can't claim that Bar,x is a 
member of Foo and Integer,Integer is member of Foo and preserve my functional 
dependencies, because Bar,Integer is now a member of Foo..

Bad programmer...


So how I naively go


 class NotAnInteger a

 instance (NotAnInteger x) = Foo Bar x

I haven't declared integer to be NotAnIntegerso (in a closed 
world)this would seem to exclude the contradictionbut...


Functional dependencies conflict between instance declarations:
  instance Foo Integer Integer -- Defined at liam1.lhs:7:12
  instance NotAnInteger x = Foo Bar x -- Defined at liam1.lhs:13:12

So

i)I clearly don't understand something about the type 
system.

ii)   I don't know how to restrict type variables in instance 
declarationsi.e. how do I use the notion of Foo across different 
combinations of types, without them colliding.









CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright 
(and other intellectual property rights). If you are not the intended recipient 
please e-mail the sender and then delete the email and any attached files 
immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any 
attachments are virus free, it is your responsibility to ensure that this 
message and any attachments are virus free and do not affect your systems / 
data.

Communicating by email is not 100% secure and carries risks such as delay, data 
corruption, non-delivery, wrongful interception and unauthorised amendment. If 
you communicate with us by e-mail, you acknowledge and assume these risks, and 
you agree to take appropriate measures to minimise these risks when e-mailing 
us.

MTV Networks International, MTV Networks UK  Ireland, Greenhouse, Nickelodeon 
Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be 
Viacom, Viacom International Media Networks and VIMN and Comedy Central are all 
trading names of MTV Networks Europe.  MTV Networks Europe is a partnership 
between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for 
service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright 
(and other intellectual property rights). If you are not the intended recipient 
please e-mail the sender and then delete the email and any attached files 
immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any 
attachments are virus free, it is your responsibility to ensure that this 
message and any attachments are virus free and do not affect your systems / 
data.

Communicating by email is not 100

[Haskell-cafe] Basic Parsec float integer parsing question

[Fredrik Karlsson]

Dear list,

Sorry for asking a simple parsec question, but both Parsec and Haskell is
new to me, so please be gentle :-)

I have this code:


import Text.ParserCombinators.Parsec
import Text.Parsec.Token
import Text.ParserCombinators.Parsec.Char


data VariableLine = VariableLine String String deriving Show
data TierType = IntervalTier | PointTier deriving Show

data Tier = Tier TierType String Float Float Integer
data Label = Interval Float Float String
data LabelFile = LabelFile Float Float

symbol :: Parser Char
symbol = oneOf !#$%|*+-/:=?@^_~

testString = intervals [1]:\nxmin = 0 \nxmax =
0.028192 \ntext = \\
headTS1 = File type = \ooTextFile\\nObject class = \TextGrid\\n\nxmin
=

header :: Parser LabelFile
header = do
headTS1
start - float
string \nxmax = 
end - float
string \ntiers? exists\nsize = 
integer
char '\n'
return $ LabelFile start end



Loading it into ghci I get :

Prelude :l parsectest.hs
[1 of 1] Compiling Main ( parsectest.hs, interpreted )

parsectest.hs:21:9:
Couldn't match type `[]'
  with `Text.Parsec.Prim.ParsecT
  String () Data.Functor.Identity.Identity'
Expected type: Text.Parsec.Prim.ParsecT
 String () Data.Functor.Identity.Identity Char
  Actual type: [Char]
In a stmt of a 'do' block: headTS1
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:22:18:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String ()
Data.Functor.Identity.Identity Float'
with actual type `GenTokenParser s0 u0 m0
  - Text.Parsec.Prim.ParsecT s0 u0 m0
Double'
In a stmt of a 'do' block: start - float
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:24:16:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String ()
Data.Functor.Identity.Identity Float'
with actual type `GenTokenParser s1 u1 m1
  - Text.Parsec.Prim.ParsecT s1 u1 m1
Double'
In a stmt of a 'do' block: end - float
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:26:9:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String ()
Data.Functor.Identity.Identity a0'
with actual type `GenTokenParser s2 u2 m2
  - Text.Parsec.Prim.ParsecT s2 u2 m2
Integer'
In a stmt of a 'do' block: integer
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }
Failed, modules loaded: none.

I'm sure I'm doing something really stupid here, but I need help to get
through this problem. I've used the predefined letter parser at other
places in the code, so I can't understand why float and integer does
not work.

/Fredrik

-- 
Life is like a trumpet - if you don't put anything into it, you don't get
anything out of it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Basic Parsec float integer parsing question

[David McBride]

Token parsers are specific to different languages.  Afterall, haskell
parses floats differently than C, which is different from java
(probably).  In order to use it in your code you have to tell it that,
like so:

haskelldef = makeTokenParser haskellDef

header :: Parser LabelFile
header = do
  string headTS1
  start - fmap double2Float $ float haskelldef
  string \nxmax = 
  end - fmap double2Float $ float haskelldef
  string \ntiers? exists\nsize = 
  integer haskelldef
  char '\n'
  return $ LabelFile start end

You'll need to import GHC.Float (double2Float) to get those parsed
values as floats.

On Fri, Jul 5, 2013 at 12:42 PM, Fredrik Karlsson dargo...@gmail.com wrote:
 Dear list,

 Sorry for asking a simple parsec question, but both Parsec and Haskell is
 new to me, so please be gentle :-)

 I have this code:

 
 import Text.ParserCombinators.Parsec
 import Text.Parsec.Token
 import Text.ParserCombinators.Parsec.Char


 data VariableLine = VariableLine String String deriving Show
 data TierType = IntervalTier | PointTier deriving Show

 data Tier = Tier TierType String Float Float Integer
 data Label = Interval Float Float String
 data LabelFile = LabelFile Float Float

 symbol :: Parser Char
 symbol = oneOf !#$%|*+-/:=?@^_~

 testString = intervals [1]:\nxmin = 0 \nxmax = 0.028192
 \ntext = \\
 headTS1 = File type = \ooTextFile\\nObject class = \TextGrid\\n\nxmin
 =

 header :: Parser LabelFile
 header = do
 headTS1
 start - float
 string \nxmax = 
 end - float
 string \ntiers? exists\nsize = 
 integer
 char '\n'
 return $ LabelFile start end

 

 Loading it into ghci I get :

 Prelude :l parsectest.hs
 [1 of 1] Compiling Main ( parsectest.hs, interpreted )

 parsectest.hs:21:9:
 Couldn't match type `[]'
   with `Text.Parsec.Prim.ParsecT
   String () Data.Functor.Identity.Identity'
 Expected type: Text.Parsec.Prim.ParsecT
  String () Data.Functor.Identity.Identity Char
   Actual type: [Char]
 In a stmt of a 'do' block: headTS1
 In the expression:
   do { headTS1;
start - float;
string
  \
  \xmax = ;
end - float;
 }
 In an equation for `header':
 header
   = do { headTS1;
  start - float;
  string
\
\xmax = ;
   }

 parsectest.hs:22:18:
 Couldn't match expected type `Text.Parsec.Prim.ParsecT
 String () Data.Functor.Identity.Identity
 Float'
 with actual type `GenTokenParser s0 u0 m0
   - Text.Parsec.Prim.ParsecT s0 u0 m0
 Double'
 In a stmt of a 'do' block: start - float
 In the expression:
   do { headTS1;
start - float;
string
  \
  \xmax = ;
end - float;
 }
 In an equation for `header':
 header
   = do { headTS1;
  start - float;
  string
\
\xmax = ;
   }

 parsectest.hs:24:16:
 Couldn't match expected type `Text.Parsec.Prim.ParsecT
 String () Data.Functor.Identity.Identity
 Float'
 with actual type `GenTokenParser s1 u1 m1
   - Text.Parsec.Prim.ParsecT s1 u1 m1
 Double'
 In a stmt of a 'do' block: end - float
 In the expression:
   do { headTS1;
start - float;
string
  \
  \xmax = ;
end - float;
 }
 In an equation for `header':
 header
   = do { headTS1;
  start - float;
  string
\
\xmax = ;
   }

 parsectest.hs:26:9:
 Couldn't match expected type `Text.Parsec.Prim.ParsecT
 String () Data.Functor.Identity.Identity
 a0'
 with actual type `GenTokenParser s2 u2 m2
   - Text.Parsec.Prim.ParsecT s2 u2 m2
 Integer'
 In a stmt of a 'do' block: integer
 In the expression:
   do { headTS1;
start - float;
string
  \
  \xmax = ;
end - float;
 }
 In an equation for `header':
 header
   = do { headTS1;
  start - float;
  string
\
\xmax = ;
   }
 Failed, modules loaded: none.

 I'm sure I'm doing something really stupid here, but I need help to get
 through this problem

[Haskell-cafe] Fwd: Basic Parsec float integer parsing question

[Antoine Latter]

Forwarding to the list.


-- Forwarded message --
From: Fredrik Karlsson dargo...@gmail.com
Date: Fri, Jul 5, 2013 at 11:42 AM
Subject: [Haskell-cafe] Basic Parsec float  integer parsing question
To: haskell-cafe@haskell.org


Dear list,

Sorry for asking a simple parsec question, but both Parsec and Haskell
is new to me, so please be gentle :-)

I have this code:


import Text.ParserCombinators.Parsec
import Text.Parsec.Token
import Text.ParserCombinators.Parsec.Char


data VariableLine = VariableLine String String deriving Show
data TierType = IntervalTier | PointTier deriving Show

data Tier = Tier TierType String Float Float Integer
data Label = Interval Float Float String
data LabelFile = LabelFile Float Float

symbol :: Parser Char
symbol = oneOf !#$%|*+-/:=?@^_~

testString = intervals [1]:\nxmin = 0 \nxmax =
0.028192 \ntext = \\
headTS1 = File type = \ooTextFile\\nObject class = \TextGrid\\n\nxmin =

header :: Parser LabelFile
header = do
headTS1
start - float
string \nxmax = 
end - float
string \ntiers? exists\nsize = 
integer
char '\n'
return $ LabelFile start end



Loading it into ghci I get :

Prelude :l parsectest.hs
[1 of 1] Compiling Main ( parsectest.hs, interpreted )

parsectest.hs:21:9:
Couldn't match type `[]'
  with `Text.Parsec.Prim.ParsecT
  String () Data.Functor.Identity.Identity'
Expected type: Text.Parsec.Prim.ParsecT
 String () Data.Functor.Identity.Identity Char
  Actual type: [Char]
In a stmt of a 'do' block: headTS1
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:22:18:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String ()
Data.Functor.Identity.Identity Float'
with actual type `GenTokenParser s0 u0 m0
  - Text.Parsec.Prim.ParsecT s0 u0 m0 Double'
In a stmt of a 'do' block: start - float
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:24:16:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String ()
Data.Functor.Identity.Identity Float'
with actual type `GenTokenParser s1 u1 m1
  - Text.Parsec.Prim.ParsecT s1 u1 m1 Double'
In a stmt of a 'do' block: end - float
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }

parsectest.hs:26:9:
Couldn't match expected type `Text.Parsec.Prim.ParsecT
String () Data.Functor.Identity.Identity a0'
with actual type `GenTokenParser s2 u2 m2
  - Text.Parsec.Prim.ParsecT s2 u2 m2 Integer'
In a stmt of a 'do' block: integer
In the expression:
  do { headTS1;
   start - float;
   string
 \
 \xmax = ;
   end - float;
    }
In an equation for `header':
header
  = do { headTS1;
 start - float;
 string
   \
   \xmax = ;
  }
Failed, modules loaded: none.

I'm sure I'm doing something really stupid here, but I need help to
get through this problem. I've used the predefined letter parser at
other places in the code, so I can't understand why float and
integer does not work.

/Fredrik

--
Life is like a trumpet - if you don't put anything into it, you don't
get anything out of it.

___
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] question about indentation conventions

[Tom Ellis]

On Mon, Jul 01, 2013 at 05:18:39PM +1200, Richard A. O'Keefe wrote:
 On 1/07/2013, at 1:04 PM, Richard Cobbe wrote:
  I should have been clearer in my original question: I'm curious about what
  to do when a multi-argument function application gets split across lines.
  That wiki page dicsusses how the layout rule interacts with various special
  forms (let, where, if, do, case), but it doesn't seem to address function
  applications, beyond implying that it's ok to indent the continuing lines
  of a function application.
 
 It looked pretty explicit to me:
 
   The golden rule of indentation
   ...
   you will do fairly well if you just remember a single rule:
   Code which is part of some expression should be indented 
   further in than the beginning of that expression (even if
   the expression is not the leftmost element of the line).
 
 This means for example that
   f (g x
   y
   z)
 is OK but
   f (g x
   y z)
 is not.

It seems to me that this means

f x1 x2
x3 x4

is not.  The OP was initially asking about this situation.

Tom


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question automatic indentation (and so on)

[Joachim Breitner]

Hi,

on a related note: At HaL8 I was wondering how well Haskell would be
suited for a workflow similar to what the go programmers do: Do not
worry about code layout, but let the computer handle it! For more
rationale and examples see
http://golang.org/doc/effective_go.html#formatting

While everyone has his own style and preferences, as soon as multiple
programmers work on the same code, a consistently enforced formatting
would probably help here a lot. Also, I would be happy to give up some
bikeshedding^Wformatting freedom for not having to worry about this
aspect.

I found https://github.com/jaspervdj/stylish-haskell/ (found via
http://stackoverflow.com/q/6870148/946226) which formats just some very
few aspects of Haskell. Does anyone have a more complete solution? Or is
interested in creating one?

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: m...@joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: nome...@joachim-breitner.de


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Johannes Waldmann]

   Code which is part of some expression should be indented 
   further in than the beginning of that expression [...]

Yes. Then the next question is how much further in.

My answer is: it does not matter, but make it consistent (like 4 spaces),
with the implication that indentation should *not* depend
on length of identifiers in the previous line(s)

Example (bad):

foo x = do bar
   baz

Example (good):

foo x = do
bar
baz

Reason: when refactoring later changes the name foo,
or the number or names of its arguments,
you'll have to re-indent code (in the bad version):
(a) this needs tool support and
(b) it creates noise in the diffs.

- J.W.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question automatic indentation (and so on)

[Richard Cobbe]

On Mon, Jul 01, 2013 at 09:48:42AM +0200, Joachim Breitner wrote:

SNIP

 I found https://github.com/jaspervdj/stylish-haskell/ (found via
 http://stackoverflow.com/q/6870148/946226) which formats just some very
 few aspects of Haskell. Does anyone have a more complete solution? Or is
 interested in creating one?

I'd love a fully-automatic indentation tool; it's one of the things about
the Lisp world that I miss.  But is this actually a solvable problem?  I
think that, to be fully correct, an indentation algorithm for Haskell would
have to know not only the syntactic structure of the program but also the
programmer's intent, in some cases.

Heh -- forgive the pun.  Nested CASE expressions are actually one of the
trickiest bits.  If the programmer doesn't put parens around the inner
expression (and doesn't use braces and semis), then only indentation serves
to indicate when the inner case ends and the next branch of the outer case
begins:

case x of
A - ...
B -
case y of
Just z - ...
Nothing - ...
C - ...

Similarly (tying this back to my original question), in a do block,
applications that span multiple lines are tricky:

do f x y z
   a b c

How does the indentation tool know if (a b c) is supposed to be the next
item in the do block, or merely a continuation of the previous application
of f?

Richard

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Richard Cobbe]

On Mon, Jul 01, 2013 at 05:18:39PM +1200, Richard A. O'Keefe wrote:

 It looked pretty explicit to me:

   The golden rule of indentation
   ...
   you will do fairly well if you just remember a single rule:
   Code which is part of some expression should be indented
   further in than the beginning of that expression (even if
   the expression is not the leftmost element of the line).

 This means for example that
   f (g x
   y
   z)
 is OK but
   f (g x
   y z)
 is not.


Sure.  So my first question boils down to which of the two alternatives
below does the community prefer?  (To be clear about the intended
semantics: this is the application of the function f to the arguments x, y,
and z.)

f x
y
z

or

f x
 y
 z

Both are correct, in most contexts.

And then there's the second question: if the second alternative is
preferable, is there a way to get haskell-mode to do it automatically?  As
it is, it refuses to indent y any farther to the right than in the first
alternative.  I can space it in by hand, and then haskell-mode puts z under
y, but that's annoying, and it gets in the way of reindenting large regions
of code automatically.

Richard

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question automatic indentation (and so on)

[Joachim Breitner]

Hi,

Am Montag, den 01.07.2013, 07:59 -0400 schrieb Richard Cobbe:
 How does the indentation tool know if (a b c) is supposed to be the next
 item in the do block, or merely a continuation of the previous application
 of f?

I would still expect the developer to write correctly intended Haskell,
so the the tool would have to employ a Haskell parser to get an AST
(with extra information on where comments were – probably the trickiest
part) and then pretty-prints it.

If it were not for comments, using haskell-src-exts would already
provide a first approximation to the problem, as shown in this script:
https://github.com/djv/small/blob/master/tidy.hs


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Sturdy, Ian]

I always preferred (I think going back to my lisp days)

foo x y
  z

indenting subsequent arguments to the same level as the first, but I have not 
convinced haskell-mode to do that for me. (The general rule here being that 
similar things should be at the same indent, which will always result in 
subexpressions being further indented, but is somewhat more specific.)

The case I never quite know what to do with is a series of expressions 
connected with operators, e.g.

foo
| bar
| baz

Leaving operators at the beginning of lines (rather than trailing the previous 
line) seems preferable, but does one (where the layout rules apply) align the 
operator or the function? (the alternative being, if your mail client does not 
make a mess of it with a variable-width font)

foo
| bar
| baz

~IRS

From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on 
behalf of Richard Cobbe [co...@ccs.neu.edu]
Sent: Monday, July 01, 2013 8:00 AM
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] question about indentation conventions

On Mon, Jul 01, 2013 at 05:18:39PM +1200, Richard A. O'Keefe wrote:

 It looked pretty explicit to me:

   The golden rule of indentation
   ...
   you will do fairly well if you just remember a single rule:
   Code which is part of some expression should be indented
   further in than the beginning of that expression (even if
   the expression is not the leftmost element of the line).

 This means for example that
   f (g x
   y
   z)
 is OK but
   f (g x
   y z)
 is not.


Sure.  So my first question boils down to which of the two alternatives
below does the community prefer?  (To be clear about the intended
semantics: this is the application of the function f to the arguments x, y,
and z.)

f x
y
z

or

f x
 y
 z

Both are correct, in most contexts.

And then there's the second question: if the second alternative is
preferable, is there a way to get haskell-mode to do it automatically?  As
it is, it refuses to indent y any farther to the right than in the first
alternative.  I can space it in by hand, and then haskell-mode puts z under
y, but that's annoying, and it gets in the way of reindenting large regions
of code automatically.

Richard

___
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] question about indentation conventions

[Brandon Allbery]

On Mon, Jul 1, 2013 at 3:43 AM, Tom Ellis 
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:

  is OK but
f (g x
y z)
  is not.

 It seems to me that this means

 f x1 x2
 x3 x4

 is not.  The OP was initially asking about this situation.


If you wrote that in a do, the compiler would insert a () between the two
lines.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Tikhon Jelvis]

My current approach is not to have one rule for every case but rather to
indent however seems best for the particular code. For example, for
Parsec's |, I try to make the code look like a BNF grammar rather than
adhering to normal indentation conventions. Perhaps as a carry-over from my
C-style programming days, I usually have the operators at the end of the
line, but I put | at the beginning, several steps *left* of where it
would normally be, to get everything aligned nicely.

Similarly, I try to align things to show the structure of the code. For
example, if I have two similar function calls on top of each other, I try
to highlight the parallelism:

foo (Just $ a + b) Nothing
foo Nothing  (Just $ a + b)

The main idea is that I try to format my code not based on what the *code*
is but based on what it *means*. I don't know if this is entirely
reasonable, but I like it.

I've thought about writing an automatic indenting tool for Haskell (or,
more accurately, a pretty-printer) for another project I have, and this is
the main thing that threw me off. While automatic indentation might make
sense for less expressive languages (Google Go being an extreme example), I
think it would be too constraining for Haskell. After all, in reasonable
code, chances are that similar constructs end up meaning wildly different
things (especially with the advent of pervasive embedded DSLs), so the code
itself is a poor indicator of its own structure.

So this is really something of an aside, but I do not think that a
gofmt-style tool would be quite as useful for Haskell, and it certainly
does not replace good taste.
**


On Mon, Jul 1, 2013 at 9:34 AM, Sturdy, Ian sturdy...@mail.wlu.edu wrote:

 I always preferred (I think going back to my lisp days)

 foo x y
   z

 indenting subsequent arguments to the same level as the first, but I have
 not convinced haskell-mode to do that for me. (The general rule here being
 that similar things should be at the same indent, which will always result
 in subexpressions being further indented, but is somewhat more specific.)

 The case I never quite know what to do with is a series of expressions
 connected with operators, e.g.

 foo
 | bar
 | baz

 Leaving operators at the beginning of lines (rather than trailing the
 previous line) seems preferable, but does one (where the layout rules
 apply) align the operator or the function? (the alternative being, if your
 mail client does not make a mess of it with a variable-width font)

 foo
 | bar
 | baz

 ~IRS
 
 From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org]
 on behalf of Richard Cobbe [co...@ccs.neu.edu]
 Sent: Monday, July 01, 2013 8:00 AM
 To: haskell-cafe@haskell.org
 Subject: Re: [Haskell-cafe] question about indentation conventions

 On Mon, Jul 01, 2013 at 05:18:39PM +1200, Richard A. O'Keefe wrote:
 
  It looked pretty explicit to me:
 
The golden rule of indentation
...
you will do fairly well if you just remember a single rule:
Code which is part of some expression should be indented
further in than the beginning of that expression (even if
the expression is not the leftmost element of the line).
 
  This means for example that
f (g x
y
z)
  is OK but
f (g x
y z)
  is not.
 

 Sure.  So my first question boils down to which of the two alternatives
 below does the community prefer?  (To be clear about the intended
 semantics: this is the application of the function f to the arguments x, y,
 and z.)

 f x
 y
 z

 or

 f x
  y
  z

 Both are correct, in most contexts.

 And then there's the second question: if the second alternative is
 preferable, is there a way to get haskell-mode to do it automatically?  As
 it is, it refuses to indent y any farther to the right than in the first
 alternative.  I can space it in by hand, and then haskell-mode puts z under
 y, but that's annoying, and it gets in the way of reindenting large regions
 of code automatically.

 Richard

 ___
 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

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Brandon Allbery]

On Mon, Jul 1, 2013 at 9:56 AM, Tikhon Jelvis tik...@jelv.is wrote:

 I've thought about writing an automatic indenting tool for Haskell (or,
 more accurately, a pretty-printer) for another project I have, and this is
 the main thing that threw me off. While automatic indentation might make
 sense for less expressive languages (Google Go being an extreme example), I
 think it would be too constraining for Haskell. After all, in reasonable
 code, chances are that similar constructs end up meaning wildly different
 things (especially with the advent of pervasive embedded DSLs), so the code
 itself is a poor indicator of its own structure.


One might look at the history of the indentation modules for Emacs
haskell-mode. Short version: they gave up, tab iterates through the
possibilities because it's quite impossible to know which one is correct
without a *semantic*, not just syntactic, understanding of the code.
(Which, when you think about it, is pretty much par for the Haskell
language definition. See also the literally impossible brace insertion rule
of Haskell98.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Tikhon Jelvis]

That's certainly true. As I mentioned, I was actually considering a
*pretty-printer* rather than an automatic indentation tool per se. The end
results are similar, but the pretty-printer is really only the latter part
of the problem: it's predicated on already having a valid AST.

My particular use case involved diffing and merging ASTs directly; this
means that I would have to somehow output the result in a human-readable
format. Moreover, the actual AST I was outputting could have been the
combination of two others, without any prior concrete syntax! I still
haven't worked out a good way to do this for Haskell (or, to be fair, any
other language).

But yeah, Haskell is pretty intractable as far as language grammars go. I
think this is a great compromise--I value language expressiveness over
tooling--but it certainly is a compromise.


On Mon, Jul 1, 2013 at 10:10 AM, Brandon Allbery allber...@gmail.comwrote:

 On Mon, Jul 1, 2013 at 9:56 AM, Tikhon Jelvis tik...@jelv.is wrote:

 I've thought about writing an automatic indenting tool for Haskell (or,
 more accurately, a pretty-printer) for another project I have, and this is
 the main thing that threw me off. While automatic indentation might make
 sense for less expressive languages (Google Go being an extreme example), I
 think it would be too constraining for Haskell. After all, in reasonable
 code, chances are that similar constructs end up meaning wildly different
 things (especially with the advent of pervasive embedded DSLs), so the code
 itself is a poor indicator of its own structure.


 One might look at the history of the indentation modules for Emacs
 haskell-mode. Short version: they gave up, tab iterates through the
 possibilities because it's quite impossible to know which one is correct
 without a *semantic*, not just syntactic, understanding of the code.
 (Which, when you think about it, is pretty much par for the Haskell
 language definition. See also the literally impossible brace insertion rule
 of Haskell98.)

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Richard A. O'Keefe]

On 2/07/2013, at 12:00 AM, Richard Cobbe wrote:

 Sure.  So my first question boils down to which of the two alternatives
 below does the community prefer?  (To be clear about the intended
 semantics: this is the application of the function f to the arguments x, y,
 and z.)
 
f x
y
z

This (a) clearly violates the Golden Rule of Indentation
 and (b) Goes out of its way to confuse human readers.
I do not know any indenting program that would tolerate
such a layout for C or Lisp.

 or
 
f x
 y
 z
 
 Both are correct, in most contexts.

What part of y and z are PARTS of f x y z and so SHOULD BE INDENTED
relative to the whole expression is hard to understand?

If by correct you mean will not confuse a Haskell parser,
you're right.  If you mean will not dangerously mislead human
readers, only the second form is acceptable.

I do not trust any program to do my indentation.
And let's face it, if your Haskell functions are big
enough that manual indentation is a big issue, they
are too big.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Richard Cobbe]

On Sun, Jun 30, 2013 at 07:53:08PM -0400, Richard Cobbe wrote:

 Two questions:

And what I've concluded by reading this thread:

 1) Are there wide-spread conventions in the Haskell community for how to
 indent an application expression that's split across multiple lines?

Well, there's general consensus in favor of indenting the continuing lines,
but not a lot of consensus on how much, etc.  Not surprising, and that's
OK.  Infix operators are more complicated.

 2) If there is such a convention, how do I make Emacs's haskell-mode do it?

Doesn't seem to be possible, unless you're in a do block.

To be clear: I wasn't asking how to make Emacs do all of my indentation
automatically, as it can in Lisp and C modes.  I realize that isn't
possible.

But since haskell-mode doesn't have very good support for the style I
personally prefer (which is, in fact, consistent with Richard O'Keefe's
favorite rule), I wondered if that might indicate that the community
prefers a different style.  Apparently not.

Thanks to all who responded; it's been an interesting (if occasionally
overly excited) discussion.

Richard

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Patrick Mylund Nielsen]

I prefer the other style--as do others, evidently (see the example in my
first reply.) I agree that this was a good discussion, but let's not
conclude so easily that the entire community is in favor of one thing or
the other.


On Mon, Jul 1, 2013 at 8:24 PM, Richard Cobbe co...@ccs.neu.edu wrote:

 On Sun, Jun 30, 2013 at 07:53:08PM -0400, Richard Cobbe wrote:

  Two questions:

 And what I've concluded by reading this thread:

  1) Are there wide-spread conventions in the Haskell community for how to
  indent an application expression that's split across multiple lines?

 Well, there's general consensus in favor of indenting the continuing lines,
 but not a lot of consensus on how much, etc.  Not surprising, and that's
 OK.  Infix operators are more complicated.

  2) If there is such a convention, how do I make Emacs's haskell-mode do
 it?

 Doesn't seem to be possible, unless you're in a do block.

 To be clear: I wasn't asking how to make Emacs do all of my indentation
 automatically, as it can in Lisp and C modes.  I realize that isn't
 possible.

 But since haskell-mode doesn't have very good support for the style I
 personally prefer (which is, in fact, consistent with Richard O'Keefe's
 favorite rule), I wondered if that might indicate that the community
 prefers a different style.  Apparently not.

 Thanks to all who responded; it's been an interesting (if occasionally
 overly excited) discussion.

 Richard

 ___
 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

[Haskell-cafe] question about indentation conventions

[Richard Cobbe]

I hope I'm not starting a holy war with this, but I'm curious about an
aspect of coding style that's been bugging me for a while, and I'm not
finding much discussion of this question on the web or in the mailing list
archives.

Two questions:

1) Are there wide-spread conventions in the Haskell community for how to
indent an application expression that's split across multiple lines?  For
how to indent an expression that uses infix operators?  Or does everyone
pretty much do their own thing?

2) If there is such a convention, how do I make Emacs's haskell-mode do it?

By default, in most cases Emacs's haskell-mode with
turn-on-haskell-indentation does

function firstArgument
(second argument)
thirdArgument

Personally, I'd prefer some indentation on the 2nd and 3rd lines to
indicate that they're continuing an expression begun on a previous line.

I can use parens around the entire application to force haskell-mode to
indent subsequent lines (and of course this is necessary in some contexts,
like a 'do' expression), but haskell-mode only indents that by a single
space:

do (function firstArgument
(second argument)
thirdArgument)
   nextAction

I'd find a larger indent---even just 2 spaces---to be more readable.

My inclination to indent the second and following lines of a multi-line
application expression is informed by my long experience in Scheme, Racket,
and Lisp, whose S-expressions lend themselves to fairly straightforward
(and automatable!) indentation conventions.  If the Haskell community does
things differently, though, I'm happy to adapt.

This is the sort of thing that one picks up from the community, as in other
languages.  I don't, however, have a whole lot of contact with that
community outside this list -- thus the post, despite the dangers inherent
in discussing subjective stuff like this that people often feel strongly
about.

Thanks,

Richard

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Darren Grant]

Hi Richard,

This page helped me when starting out:
http://en.wikibooks.org/wiki/Haskell/Indentation
On 2013-06-30 4:55 PM, Richard Cobbe co...@ccs.neu.edu wrote:

 I hope I'm not starting a holy war with this, but I'm curious about an
 aspect of coding style that's been bugging me for a while, and I'm not
 finding much discussion of this question on the web or in the mailing list
 archives.

 Two questions:

 1) Are there wide-spread conventions in the Haskell community for how to
 indent an application expression that's split across multiple lines?  For
 how to indent an expression that uses infix operators?  Or does everyone
 pretty much do their own thing?

 2) If there is such a convention, how do I make Emacs's haskell-mode do it?

 By default, in most cases Emacs's haskell-mode with
 turn-on-haskell-indentation does

 function firstArgument
 (second argument)
 thirdArgument

 Personally, I'd prefer some indentation on the 2nd and 3rd lines to
 indicate that they're continuing an expression begun on a previous line.

 I can use parens around the entire application to force haskell-mode to
 indent subsequent lines (and of course this is necessary in some contexts,
 like a 'do' expression), but haskell-mode only indents that by a single
 space:

 do (function firstArgument
 (second argument)
 thirdArgument)
nextAction

 I'd find a larger indent---even just 2 spaces---to be more readable.

 My inclination to indent the second and following lines of a multi-line
 application expression is informed by my long experience in Scheme, Racket,
 and Lisp, whose S-expressions lend themselves to fairly straightforward
 (and automatable!) indentation conventions.  If the Haskell community does
 things differently, though, I'm happy to adapt.

 This is the sort of thing that one picks up from the community, as in other
 languages.  I don't, however, have a whole lot of contact with that
 community outside this list -- thus the post, despite the dangers inherent
 in discussing subjective stuff like this that people often feel strongly
 about.

 Thanks,

 Richard

 ___
 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] question about indentation conventions

[Richard Cobbe]

On Sun, Jun 30, 2013 at 05:41:46PM -0700, Darren Grant wrote:
 Hi Richard,

 This page helped me when starting out:
 http://en.wikibooks.org/wiki/Haskell/Indentation
 On 2013-06-30 4:55 PM, Richard Cobbe co...@ccs.neu.edu wrote:

snip

  1) Are there wide-spread conventions in the Haskell community for how to
  indent an application expression that's split across multiple lines?  For
  how to indent an expression that uses infix operators?  Or does everyone
  pretty much do their own thing?

snip

Thanks for the pointer, Darren, and I did come across that page earlier.

I should have been clearer in my original question: I'm curious about what
to do when a multi-argument function application gets split across lines.
That wiki page dicsusses how the layout rule interacts with various special
forms (let, where, if, do, case), but it doesn't seem to address function
applications, beyond implying that it's ok to indent the continuing lines
of a function application.

Richard

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] question about indentation conventions

[Patrick Mylund Nielsen]

The Haskell Style Guide is quite popular:
https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md
(accompying
elisp module:
https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.el)

I am not sure what the verdict is on functions spanning multiple lines,
other than 80 columns being the max line length. Personally, I do what
haskell-mode + style-guide.el default to, which is to indent to the same
level like you said, e.g.:

fun a b c
d e f

Looking at some of the style guide author's code seems to suggest this is
what he does too:
https://github.com/tibbe/ekg/blob/master/System/Remote/Snap.hs#L155

Of course, you're free to do it whichever way you prefer--it only matters
if you are collaborating with others who don't share your preferences
(always a fun activity.)

It would be cool if there was a The One Formatting Tool for Haskell, a la
go fmt for Go, or an 'indent' without so many options that the tool is
moot.


On Sun, Jun 30, 2013 at 9:04 PM, Richard Cobbe co...@ccs.neu.edu wrote:

 On Sun, Jun 30, 2013 at 05:41:46PM -0700, Darren Grant wrote:
  Hi Richard,
 
  This page helped me when starting out:
  http://en.wikibooks.org/wiki/Haskell/Indentation
  On 2013-06-30 4:55 PM, Richard Cobbe co...@ccs.neu.edu wrote:

 snip

   1) Are there wide-spread conventions in the Haskell community for how
 to
   indent an application expression that's split across multiple lines?
  For
   how to indent an expression that uses infix operators?  Or does
 everyone
   pretty much do their own thing?

 snip

 Thanks for the pointer, Darren, and I did come across that page earlier.

 I should have been clearer in my original question: I'm curious about what
 to do when a multi-argument function application gets split across lines.
 That wiki page dicsusses how the layout rule interacts with various special
 forms (let, where, if, do, case), but it doesn't seem to address function
 applications, beyond implying that it's ok to indent the continuing lines
 of a function application.

 Richard

 ___
 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] question about indentation conventions

[Richard A. O'Keefe]

On 1/07/2013, at 1:04 PM, Richard Cobbe wrote:
 
 I should have been clearer in my original question: I'm curious about what
 to do when a multi-argument function application gets split across lines.
 That wiki page dicsusses how the layout rule interacts with various special
 forms (let, where, if, do, case), but it doesn't seem to address function
 applications, beyond implying that it's ok to indent the continuing lines
 of a function application.

It looked pretty explicit to me:

The golden rule of indentation
...
you will do fairly well if you just remember a single rule:
Code which is part of some expression should be indented 
further in than the beginning of that expression (even if
the expression is not the leftmost element of the line).

This means for example that
f (g x
y
z)
is OK but
f (g x
y z)
is not.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: ConstraintKinds feature suggestion and question about type family peculiarity

[Simon Peyton-Jones]

| This seems to works marvellously, but in writing it I ran into 2
| annoyances.
| 
| 1) The type errors produced by trying to use a function on a disallowed
| phantom type are rather unclear.
| 
| Could not deduce (Restrict Int ('[] *)) arising from a use of ‛foo
| 
| Which got me thinking, it would be really nice to have a vacuous
| Constraint that takes an error string as argument, i.e. a constraint
| that never holds and returns it's error string as type error. This would
| let you produce far nicer type errors when (ab)using ConstraintKinds and
| TypeFamilies by, for example, adding an extra Restrict instance
| Restrict x '[] = Vacuous Applying restricted function to disallowed
| type (or something to that effect), producing that message as error
| rather than the Could not deduce (Restrict Int ('[] *) which is a
| rather unhelpful error if you're not the person that wrote this code and
| are just using a function with such a Restrict constraint.

This is part of a more general question about how to generate better type error 
messages.  The Helium folk did some good work on this.  There's a very 
interesting PhD to be had here.

| 2) for some reason the type families syntax always requires a full
| argument list, which I find rather ugly. I would much prefer to use
| KindSignatures and write type family Restrict :: * - [*] -
| Constraint, but GHC does not allow this. Is there a specific reason for
| not allowing this syntax?

We need to fix the arity of a type family, because type families must always 
be fully applied.  If you write
type family F a :: * - *
then F *must* always be applied to one argument, and in a 'type instance' you 
can dispatch on one argument
type instance F Int = []
type instance F Bool = Maybe
If you instead write
type family F a b :: *
then you must always apply F to two arguments, and in a 'type instance' you can 
dispatch on two arguments.
type instance F Int Bool = Char

It is *unsatisfactory* that we get the clue about arity from the syntactic form 
of the 'type family' declaration. But it's a convenient hack; less clunky than, 
say
type family F [arity = 1] :: * - * - *  

Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users