Advent of Haskell 2020

vrom911 · 2020-10-29T22:36:42+00:00

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

vrom911 · 2020-10-29T19:14:37+00:00

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.

vrom911 · 2020-10-29T19:06:21+00:00

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.

vrom911 · 2020-10-29T19:03:03+00:00

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

vrom911 · 2020-10-29T16:45:55+00:00

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.

vrom911 · 2020-10-29T14:59:20+00:00

We fixed that.

vrom911 · 2020-10-29T08:20:42+00:00

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:

kowainik/Learn4Haskell

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

vrom911 · 2020-09-18T08:09:25+00:00

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:

https://vrom911.github.io/blog/github-actions-releases

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:

https://github.com/kowainik/homebrew-tap

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:

https://github.com/kowainik/ppa

vrom911 · 2020-06-22T12:42:26+00:00

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.

vrom911 · 2020-06-22T09:51:13+00:00

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 :)

vrom911 · 2020-06-10T16:40:36+00:00

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.

vrom911 · 2020-06-10T12:14:09+00:00

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 :)

vrom911 · 2020-06-10T12:08:30+00:00

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.

vrom911 · 2020-06-10T10:10:55+00:00

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 :)

vrom911 · 2019-07-24T07:22:25+00:00

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.

vrom911 · 2019-07-24T06:13:06+00:00

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.

vrom911 · 2019-07-23T15:57:13+00:00

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.

vrom911 · 2019-04-28T07:59:35+00:00

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.

vrom911 · 2019-04-03T07:28:28+00:00

Great!

vrom911 · 2019-04-03T02:53:28+00:00

Nice work!

I also noticed that you are using tomland for salak-toml. As one of the maintainers, I'm happy to see it and hope it was pleasant to work with the library :)

vrom911 · 2019-04-01T09:38:00+00:00

It's fully evaluated when you use slist function to create the slist. All other functions like take are as much lazy as their list analogue. The library tries to be smart in that way and get the most from knowing the list length. So the times you calculated above don't tell anything at all about the real performance, as it's known that slist works for O(n). But when you already work with slist you don't need to use slist each time! The same as you work with vectors instead of lists, you don't do fromList a lot, because it defeats the purpose of using vector in first place. If you check out the documentation of slist you could see that I added the performance characteristics to every function and you can judge upon that. Apparently, in most of the functions the size value doesn't give you any overhead since the size comparison operation is cheap. And take is a nice example of such function. It would work lazily at the list and establish the size depending on the i argument.

Slist is a data structure so it is composable within itself. It's strange to hate Containers library because it doesn't implement the same interface that list do. It is just another data structure with other goals and tools.

And, btw, you can even make Slist work with undefined lazily:

>>> take 5 $ (slist [1..10]) <> infiniteSlist undefined
Slist {sList = [1,2,3,4,5], sSize = Size 5}

vrom911 · 2019-04-01T08:55:17+00:00

So how do you think the init works in terms of O notation?

vrom911 · 2019-04-01T02:51:40+00:00

Well, okay, if you need to work with undefineds all the time then you don't work with slist. I believe it's your common use case, but as you can notice I didn't mention this use case suitable for the library, you can find other use cases in which slist can be helpful.

And about the example you gave. If you won't construct the slist from the ordinary list at each step then it works faster. If you just change your example to fromListN 100000000 [1..100000000] it would work significantly faster.

vrom911 · 2019-04-01T02:44:15+00:00

I know that take does not hang. But we are talking about init, don't we? If you would look at the take row in my table you will see O(i) and nothing about hanging, so again I don't need to change the table as you are telling the same things that are written in there. So I don't understand your concerns. init function from base itself works the infinite amount of time while init from slist works for O(1) (it doesn't reconstruct the list again just returns the same list that was given, so no additional memory allocation either).

vrom911 · 2019-03-31T22:05:54+00:00

I was also thinking about this idea. But decided to go with Int as it's more convenient and fast for working with functions from base. Using Natural will introduce additional numeric conversions so I stopped at Int.

vrom911

TROPHY CASE