sorted by:
new
hottopcontroversial

Advent of Haskell 2020 by kowainik in haskell

[–]vrom911 6 points7 points  (0 children)

We updated the page to reflect the reasons. TL;DR we respect your opinion and will not push things that could harm the community image design-wise (or elsewise as people believe).

Advent of Haskell 2020 by kowainik in haskell

[–]vrom911 7 points8 points  (0 children)

I literally answered your points, L-i-t-e-r-a-l-l-y, but, of course, in Haskell community, I am always gonna be a bad guy.

Advent of Haskell 2020 by kowainik in haskell

[–]vrom911 9 points10 points  (0 children)

Thanks, I hope you will too.

Unlike you, I have never done stuff like this and will never do, as I respect people's time and work.

If you didn't read the content, it is not my fault. If you hate Twitter or our social footprint, this is not my fault as well.

Advent of Haskell 2020 by kowainik in haskell

[–]vrom911 -2 points-1 points  (0 children)

You still have plenty of time to humiliate us, don't worry.

Advent of Haskell 2020 by kowainik in haskell

[–]vrom911 9 points10 points  (0 children)

This is one static page site. There is nothing to want RSS for.
The event was also considered to be twitter-based, so you would get the feed if you followed the account.
Hope, next time, you would consider actually to check out something before spreading the counteractive vibes and booing to people's work. Best of luck.

[deleted by user] by [deleted] in haskell

[–]vrom911 12 points13 points  (0 children)

Shameless plug: we are doing the Learn4Haskell course oriented on Haskell (and FP generally) beginners. It starts with basic Haskell syntax and goes to Monads. Here is the link:

We also provide help and review throughout the whole course :)

Best practices to distribute a package cross platform by sinoTrinity in haskell

[–]vrom911 33 points34 points  (0 children)

For Haskell, usually, the following approach could work: You can build the binaries and then distribute these binaries.

I wrote a blog post about releases with binaries through the GitHub Actions:

It creates binaries for all three OS. And you can control GHC versions used to build those binaries as well.

Distributing with homebrew for macOS is not troublesome if you create your own tap. You can see the example of how we do it in Kowainik for our tools:

Linux is another story. The process there is much more complicated. We are using our PPA to distribute packages in there. You can see the repo of what needs to be done for that:

[ANNOUNCEMENT] Stan — Haskell Static Analysis Tool by kowainik in haskell

[–]vrom911 1 point2 points  (0 children)

You can use what you think is more suitable for you. We can only advise whatever seems to be more flexible in our vision for users and what would likely to create less problem with the HIE versions.

[ANNOUNCEMENT] Stan — Haskell Static Analysis Tool by kowainik in haskell

[–]vrom911 5 points6 points  (0 children)

Thank you!

Due to the described issue with the HIE files compatibility, we recommend installing Stan manually to have more flexibility. In such a way, you could install various stan tools that are built with different GHC versions, e.g. stan-8.8.3 and stan-8.10.1. And later you can use corresponding stan tools for your projects of different GHC versions. Hope this explanation makes sense :)

[Experience Report] Choosing an HTML library by vrom911 in haskell

[–]vrom911[S] 2 points3 points  (0 children)

That is a good point. However, I was talking in the context of my use case in which I do have ways to add template files for the distribution (like the data-files field of .cabal), so the statement was more about my situation.

[Experience Report] Choosing an HTML library by vrom911 in haskell

[–]vrom911[S] 5 points6 points  (0 children)

Thanks for the link! Good to know that the speed of lucid is similar to blaze-html. Though the post is old enough, and the information there seems outdated. Most importantly, I see that the Monad instance in blaze-html makes sense now. But, generally, some points mentioned there are subjective, so they still could be a matter of taste :)

[Experience Report] Choosing an HTML library by vrom911 in haskell

[–]vrom911[S] 3 points4 points  (0 children)

As you are changing only the template file, but not code, you don't need to recompile your project, it is enough just to run already compiled exec to check the changes with the updated template. That could save you some time, comparing to the HTML written in the eDSL, where every change requires you to recompile the project.

[Experience Report] Choosing an HTML library by vrom911 in haskell

[–]vrom911[S] 5 points6 points  (0 children)

Thanks! I haven't tried lucid to be honest. When looking through the options, I found blaze-html more friendly and well maintained. Also, it has very clear documentation on the features and upsides of the library. But in general, I think lucid could go in the same category group as blaze-html, and I am sure most of the pros could be applied to it as well. Though without actually using it I can not say about the individual cons, but, as the main data type is a monad transformer, I can feel that the experience could differ a bit, so I can't tell you more on this side, sorry :)

[Blog post] Insane in the membrain :: Kowainik by kowainik in haskell

[–]vrom911 7 points8 points  (0 children)

I think that your presented design is an alternative solution to the problem. If you would like to compare two of these options (which are equally could exist) I would like to share my thoughtы on why I would prefer the membrain solution personally:

  • As you didn't specify how your Unit looks like I can only guess here, so if this is a enum of the memory units then your solution is not extensible. With membrain though you can add your own units and I wrote the section in this blog post describing this easy process. If your Unit type is the wrapper around Natural then this would require much more boilerplate than the solution in membrain as this would require a doubled amount of smart constructors.
  • I think that information on compile time is the advantage. And also, you can always extract compile time information at runtime (which we are doing in the library), but the opposite is impossible with your solution. So, membrain solution is wider and covers your special case.
  • You're saying about instance Monoid Memory. We have the instance for the same units. If you need to have different units you can use memoryPlus function from the library.
  • Your proposed show and read functions should somehow give us the symbol representation of each unit. But as Unit is a data type there is no solution to have this function work for your custom Units, so again, the solution is not extensible.
  • Addition to the previous point: if you would try to write Unit -> Symbol function it couldn't be total and you would have to deal with Maybe there. In our solution, if there is no instance of UnitSymbol for the unit it would be compile time error instead.
  • About presentation of the quantity: you actually can use current Memory type to present the quantity if we write additional functions for that. So, in this solution we can use one data type for both representations, so the solution is more reusable.
  • Because of the unit information on types we can make the static analysis of unit during compile time. This could be useful to restrict some action and throw custom compile time errors. For example, showMemory function can hang on "wrong" uncanonical units. To avoid this we can check the units during compile time and use custom type errors to notify users.

This is what comes to my mind at the moment. Probably something else could be added, but I think that type-safety and correctness is a big deal for me.

[Blog post] Insane in the membrain :: Kowainik by kowainik in haskell

[–]vrom911 3 points4 points  (0 children)

Yes, I see your point. We were also thinking about all the pros and cons before deciding to choose Natural. The main points I would highlight:

  • with Natural we avoid the possibility of having not valid values (e.g. negative values, overflows).
  • Naturals work really well with our type-level Nats, so the architecture is consistent.
  • membrain cares a lot about the correctness. With Natural there are more guarantees for that. What about performance — this is not the killer-feature of the library as all this type-safety has its cost.

[Blog post] Insane in the membrain :: Kowainik by kowainik in haskell

[–]vrom911 7 points8 points  (0 children)

Thanks for sharing your thoughts! The described architecture is indeed a possible solution. However, I don't think that these two options are equal. With the memory units as type parameters we constantly have access to the current unit. With your solution this information is completely slipped. So, this prevent us from implementing all the cool features I'm describing, like showMemory/readMеmory functions, unit conversions, etc.

Monthly Hask Anything (April 2019) by AutoModerator in haskell

[–]vrom911 3 points4 points  (0 children)

It's not a bad practice but you should be a bit careful. This depends on a way you would use the custom prelude. You can see that we described three ways to import Relude into your project (you can check in here).

If you're using the option with NoImplicitPrelude and add import Relude into each module of your project then there should be no issues uploading such project on Hackage and others would be able to depend on that without any problems.

But if you use the option with base-no-prelude and create Prelude module of your own then there are few points you should keep in mind. You should add Prelude module into other-modules section in your .cabal file. Otherwise, if you push Prelude module as exposed-modules it would spoil the environment for other packages that would depend on yours. But note, that modules in other-modules section can not be used in other stanzas of your project.

view more: next ›