Re: type (++) = (<>)

[Vassil Ognyanov Keremidchiev]

"plus" symbol is natural denoting joining two pieces in almost all
languages. That is why I would like not to get rid of it, but to be a bit
more general. So in new code that will use the new prelude to be able to
use it on broader range of containers (monoids/semigroups).

I really mean:
(++) :: Semigroup s => s -> s -> s

About the fixity, it could retain it's original fixity.

2017-07-04 3:24 GMT+03:00 Edward Kmett <ekm...@gmail.com>:

> Note: I realize nobody is directly saying that we should use (++) instead
> of (<>) in this conversation just yet, but I want to clear a few things up.
>
> One of the early options when the operator (<>) was coined was to try to
> say we should just generalize the type of (++) instead to make it mappend.
> (Note: it originally was mplus, in a Haskell version long long ago, so it
> keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact
> that the primary libraries using the (<>) notation at the time (pretty
> printing libraries) also mixed it heavily with (++), exploiting the
> different fixities involved. (Finding a decent fixity for (<>) was a huge
> chunk of the conversation at the time.)
>
> There is a deliberate fixity difference between (++) and (<>), a good
> chunk of code out there mixes them that deals with pretty printing that
> would break pretty horribly if we just outright removed (++), and trying to
> do a visual search and replace for (++) with (<>) in light of them having
> different fixities is a very error prone process, so we aren't currently
> planning on deprecating the existing (++) operator any time soon. At least,
> nobody has put a proposal to the core libraries committee to that end.
>
> Since the call was made to make (<>) become the new operator, we
> ultimately decided to leave (++) untouched, even though it could be
> generalized to match (<>), for much the same reason that map still exists,
> despite there being a more general fmap: Ultimately, there isn't a
> reasonable migration plan to make (++) or map become the way you define the
> instance involved, and at least this way the name duplication can be
> leveraged by the folks who want a less polymorphic combinator.
>
> Would the world be a little tidier without map or (++) hanging about?
> Sure. But the hate mail levels in my inbox would skyrocket commensurately.
> ;)
>
> -Edward
>
> On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <mle...@mega-nerd.com>
> wrote:
>
>> Vassil Ognyanov Keremidchiev wrote:
>>
>> > What do you think of making (++) the same as (<>) so we could use ++ as
>> > concatenation of any monoid, not just lists in Haskell 2020?
>> > This will be more intuitive for beginners, too.
>>
>> Two symbolic operators that are synonymous seems a bit of a waste. I would
>> much rather see (++) be deprecated in favour of (<>). At work we have a
>> custom prelude which already does this.
>>
>> Erik
>> --
>> --
>> Erik de Castro Lopo
>> http://www.mega-nerd.com/
>> ___
>> 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
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

type (++) = (<>)

[Vassil Ognyanov Keremidchiev]

Hello!

What do you think of making (++) the same as (<>) so we could use ++ as
concatenation of any monoid, not just lists in Haskell 2020?
This will be more intuitive for beginners, too.

Best regards,
Vassil Keremidchiev
___
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

[Vassil Ognyanov Keremidchiev]

It's just helping clean up a bit words that doesn't have much meaning.
Currently GHCi in GHC 8 is supporting this, so you could write both:

x = 10
x <- return 10

Which is great!

2017-04-17 17:03 GMT+03:00 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

[Vassil Ognyanov Keremidchiev]

They are confused about when one should put "let x = ..." or "x <- ..."
mostly before they learn what is monad.

2017-04-16 21:15 GMT+03:00 Francesco Ariis <fa...@ariis.it>:

> On Sun, Apr 16, 2017 at 08:21:43PM +0300, Vassil Ognyanov Keremidchiev
> wrote:
> > Okay, sorry for taking your time about those propositions. I'm just
> > thinking of ways for improving future Haskell. My feedback is mostly from
> > talking with people and trying to teach them in Haskell.
>
> As others, I am not convinced with the proposal (given the amount of
> boxes marked "Translation" in the Haskell report, I wish we had a
> standard way to handling syntactic rewrites; it could come handy in
> yours and many more cases).
>
> But I am interested in newcomers and their introduction to the language:
> did they get confused by `let` or just pointed it out as superfluous?
>
> ___
> 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: Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions

[Vassil Ognyanov Keremidchiev]

Okay, sorry for taking your time about those propositions. I'm just
thinking of ways for improving future Haskell. My feedback is mostly from
talking with people and trying to teach them in Haskell.

2017-04-16 20:04 GMT+03:00 Sven Panne <svenpa...@gmail.com>:

> 2017-04-16 17:21 GMT+02:00 Vassil Ognyanov Keremidchiev <var...@gmail.com>
> :
>
>> 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

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

[Vassil Ognyanov Keremidchiev]

Hello!

A small proposition for the next standard.
1) It is to lower verbosity with omitting 'let' keyword in do-notation and
use only (=) for describing let/pure blocks.
Example:

currently:

main = do
 let x = expression1...
 let y = expression2...
 z <- action1
 putStrLn (x ++ y ++ z)

It could be made less verbose currently with putting x and y in the same
'let' block:

main = do
 let x = expression1...
 y = expression2...
 z <- action1
 putStrLn (x ++ y ++ z)

But what if we use (=) for describing different expressions in do-block.

main = do
 x = expression1...
 y = expression2...
 z <- action1
 putStrLn (x ++ y ++ z)

So pure 'let' expressions to use (=) for assignment and monadic actions use
(<-) for execution/chaining. If 'let' is optional - this proposition will
be backward compatible.

2) Second proposition is every pure expression ('let') in do-block to have
visibility in whole block, just like top-level function is visible in whole
module. Currently there is difference in visibility depending on that if a
function is in do-block or is outside it.
Example:

main = do
 z <- action x
 x = expression1 y
 y = expression2

 putStrLn (x ++ y ++ z)

Best regards,
Vassil Keremidchiev
___
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

[Vassil Ognyanov Keremidchiev]

So it's O(N) -> O(1) where N is a number of lines/imports.

But you're right for the readiness. I'm convinced!

2017-02-02 16:52 GMT+02:00 Doug McIlroy :

> > 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.
>
> To expand upon this principle a bit, syntactic sugar that promises to save
> O(1)
> typing in an n-line module is suspect; that which might save O(n) is more
> promising.
>
> Doug
>
>
> ___
> 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: Multiple imports on a single line

[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.

2017-02-01 23:23 GMT+02:00 Malcolm Wallace <malcolm.wall...@me.com>:

> You can already write this, with only a tiny bit of syntax:
>
> module MyApp where
> import Data.Text;  import Data.Foldable;  import Control.Concurrent
>
> Whether it is good style is another matter, but all compilers will
> certainly accept it.
>
> Regards,
>     Malcolm
>
>
> On 1 Feb 2017, at 14:18, Vassil Ognyanov Keremidchiev wrote:
>
> Hello!
>
> What do you think about an idea to have multiple imports on a single line,
> like:
>
> module MyApp where
> import Data.Text, Data.Foldable, Control.Concurrent
> ...
>
>
> That way we could write more concise and short code as Haskell promises.
> This will be useful for small programs like scripts, small tools,
> tutorials, examples, etc.
>
> Best regards,
> Vassil Keremidchiev
> ___
> 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

Multiple imports on a single line

[Vassil Ognyanov Keremidchiev]

Hello!

What do you think about an idea to have multiple imports on a single line,
like:

module MyApp where
import Data.Text, Data.Foldable, Control.Concurrent
...


That way we could write more concise and short code as Haskell promises.
This will be useful for small programs like scripts, small tools,
tutorials, examples, etc.

Best regards,
Vassil Keremidchiev
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime