Re: Remove eq and show from num class

[Sven Panne]

2017-09-08 10:43 GMT+02:00 Herbert Valerio Riedel :

> [...] Moreover, the CLC together with the Hackage Trustees also maintains
> the
> https://github.com/haskell/pvp specification which is integral to the
> way Hackage and the Cabal solver interact. [...]
>

Although I'm actively following quite a few Haskell-related mailing lists
and maintain various Haskell packages, this is the first time in my life
that I've heard of https://pvp.haskell.org/. It would be good to improve
communication about such central pieces of information... :-/ Don't get me
wrong: The page itself is great, as are other pages/repos/mailing lists,
but the overall organization of information leaves a lot to be desired IMHO.

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

Re: Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions

[Sven Panne]

2017-04-17 14:19 GMT+02:00 Adam Bergmark :

> I just wanted to say that there is no need to apologize for making a
> proposal!
>

+1 for that, and sorry if I sounded harsh, that wasn't my intention.
Proposals are important (we need more of them, not less), and so are
discussions about them. Nothing would be worse than a dead language nobody
cares about...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions

[Sven Panne]

2017-04-16 17:21 GMT+02:00 Vassil Ognyanov Keremidchiev :

> 1) It's not a problem, it's a improvement in syntax with lowering
> verbosity.
>

If it's not a real problem, it probably shouldn't be done: Every tiny
change in the syntax, even if it's somehow backwards compatible, has a high
cost in the whole ecosystem: The compiler has to be changed (probably by
far the easiest part), libraries for parsing/pretty-printing Haskell have
to be adapted, Editors/syntax highlighting rules have to be changed,
books/tutorials have to be rewritten and people have to be retrained (yes,
even if they don't use the new syntax: others might use it). To outweigh
this pain, there should be be a real gain, saving just 4 keystrokes isn't
worth it. And for me, and probably others, it's not an improvement in
syntax, it actually makes things worse by removing a syntactic cue.


> It's similar with the difference between Pascal and C syntax. One of the
> reasons we all love Haskell is because it's not so verbose.
>

I think it's actually not the non-verbosity which makes Haskell attractive,
it's its expressiveness. These are two quite different things.


> I have asked often why do-block is so different, than non-do-block.
>

Because it is fundamentally different from the rest, having a sequential
nature (for some meaning of "sequential" given by the underlying monad).


> Exchanging "x = foo" with "x <- foo" will result in error, so there is no
> problem that the difference is small.
>

Of course a machine will see the difference easily and immediately, the
question is: Will people do so, too?


> 2) you're right. May be lazyness could solve that? I'm not sure here.
>

So what are the desugaring rules for your proposal? I have the gut feeling
that they will be quite a bit more complicated and non-local than the
current ones. Remember the famous quote:

   "If you can't explain it to a six year old, you don't understand it
yourself."

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

Re: Multiple imports on a single line

[Sven Panne]

2017-02-01 22:39 GMT+01:00 Vassil Ognyanov Keremidchiev :

> Yes, but it could be a bit more denser without so much repetition of
> "import", like:
>
> import Data.Text, qualified Data.Map as M, qualified Vector as V hiding
> (Vector)
>
> i.e. the same as current situation, but allow for multiple imports for the
> same word "import" comma separated. What do you think? The difference in
> syntax is not so much different, than just allowing commas.
>

I think this is worse than separate imports, each on a separate line. The
Python people have even put something like this into a PEP:
https://www.python.org/dev/peps/pep-0008/#imports This is for a very good
reason: The one-liners have very few visual hints for the reader to
comprehend it quickly. So even if Haskell allowed this comma-separated
chain of imports, code containing it probably wouldn't survive a code
review in most companies, where maintainability is the prime goal.

I often see a confusion between greater expresiveness (good goal) and
having to type less (largely irrelevant goal). By all means make the module
system more expressive, but try to avoid "clever" things for convenience.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

[Sven Panne]

2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel :

> [...] That being said, as how to write your Monad instances today with GHC
> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
> *does* work (admittedly for an easy example, but this can be
> generalised):
>
>
> --8<---cut here---start->8---
> module MyMaybe where
>
> import Control.Applicative (Applicative(..))
> import Prelude (Functor(..), Monad(..), (.))
> -- or alternatively: `import qualified Prelude as P`
> [...]
> --8<---cut here---end--->8---
>
> This example above compiles -Wall-clean and satisfies all your 3 stated
> requirements afaics. I do admit this probably not what you had in mind.
>

OK, so the trick is that you're effectively hiding Applicative from the
Prelude (which might be a no-op). This "works" somehow, but is not
satisfactory IMHO for several reasons:

   * If you explicitly import all entities from Prelude, your import list
will typically get *very* long and unreadable. Furthermore, if that's the
suggested technique, what's the point of having a Prelude at all?

   * Some people see qualified imports as the holy grail, but having to
prefix tons of things with "P." is IMHO very ugly. Things are even worse
for operators: The whole notion of operators in itself is totally useless
and superfluous *except* for a single reason: Readability. And exactly that
gets destroyed when you have to qualify them, so I would (sadly) prefer
some #ifdef hell, if that gives me readable code elsewhere.

   * With the current trend of moving things to the Prelude, I can envision
a not-so-distant future where the whole Control.Applicative module will be
deprecated. As it is now, it's mostly superfluous and/or contains only
stuff which might better live somewhere else.


> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
> across multiple GHC versions is not considered a show-stopper.
>

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
seen too many projects where neglecting warning over an extended period of
time made fixing them basically impossible at the end. Anyway, I think that
a sane ecosystem should allow *both* POVs, the sloppy one and the strict
one.


> [...] Beyond what Ben already suggested in another post, there was also the
> more general suggestion to implicitly suppress warnings when you
> explicitly name an import. E.g.
>
>   import Control.Applicative (Applicative(..))
>
> would suppress the redundant-import warning for Applicative via Prelude,
> because we specifically requested Applicative, so we don't mind that
> Prelude re-exports the same symbol. [...]
>

Uh, oh... That would be bad, because one normally wants to see redundant
imports. Without the compiler telling me, how should I find out which are
redundant? Manually trying to remove them step by step? :-/

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

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Sven Panne]

2015-10-05 17:09 GMT+02:00 Gershom B :

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (b...@serpentine.com)
> wrote:
> [...] As for libraries, it has been pointed out, I believe, that without
> CPP one can write instances compatible with AMP, and also with AMP + MRP.
> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
now part of the Prelude, you can't simply import some compatibility module,
because GHC might tell you (rightfully) that that import is redundant,
because (<$>) is already visible through the Prelude. So you'll have to use
CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
Control.Applicative or some compat-* module. And you'll have to use CPP in
each and every module using <$> then, unless I miss something obvious.
AFAICT all transitioning guides ignore -Wall and friends...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Sven Panne]

2015-10-05 11:59 GMT+02:00 Simon Thompson :

> [...] It’s really interesting to have this discussion, which pulls in all
> sorts of well-made points about orthogonality, teaching, the evolution of
> the language and so on, but it simply goes to show that the process of
> evolving Haskell is profoundly broken. [...]
>

I wouldn't necessarily call the process "broken", but it's a bit annoying:
Because of the constant flux of minor changes in the language and the
libraries, I've reached the stage where I'm totally unable to tell if my
code will work for the whole GHC 7.x series. The only way I see is doing
heavy testing on Travis CI and littering the code with #ifdefs after
compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
conjunction with -Wall. Bonus points for keeping the #ifdefs centralized.
No clue how to do that...) This is less than satisfactory IMHO, and I would
really prefer some other mode for introducing such changes: Perhaps these
should be bundled and released e.g. every 2 years as Haskell2016,
Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
kicking out return, etc.) comes in slightly larger, but more sensible
chunks.

Don't get me wrong: Most of the proposed changes in itself are OK and
should be done, it's only the way they are introduced should be improved...
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: PROPOSAL: Literate haskell and module file names

[Sven Panne]

2014-03-17 14:22 GMT+01:00 Brandon Allbery allber...@gmail.com:
 On Mon, Mar 17, 2014 at 9:08 AM, Edward Kmett ekm...@gmail.com wrote:

 Foo+rst.lhs does nicely dodge the collision with jhc.


 Is this legal on Windows?

According to 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
it is, although I can't test this at the moment.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime