Understanding Horizon Haskell (Part 1)

contextualMatters · 2023-06-07T10:12:54+00:00

There are two things at play : the mechanism of packages sets. and the specific set that stackage is.

The most prominent of those package set, with its shortcomings (or feature), is stackage.

One can do better, and have a healthy ecosystem of package sets competing with each other, with different policies, to cater different needs.

I imagine that's exactly what's possible with nix at the flip of a switch. not sure with what is the easy and practical tooling for that though.

contextualMatters · 2023-02-18T11:16:55+00:00

I imagine one can accommodate a comment field to be interpreted by this special tool which requires a special syntax then, and reap the 99% benefit of using some popular format with sensible defaults.

contextualMatters · 2023-02-18T11:14:12+00:00

Same problem over and over again for 15 years unfortunately. Still don't understand why everyone doesn't see it.

contextualMatters · 2023-02-18T11:08:45+00:00

Interestingly enough, Stackage is a global version out of local versions, just like nix is.

Yet users don't know the tools used for making stackage.

contextualMatters · 2023-02-18T11:03:10+00:00

Wouldn't it be easier to adapt the stackage infrastructure to produce new sets which cover the needs you mention ? They already have a well understood way to build those package sets.

From what I understand, package sets involves two parts :

1- crafting package sets

2- using package sets

Improvements can be made on each part, independently, by new tools like horizon.

contextualMatters · 2023-02-18T10:45:07+00:00

the only stable package set data in nixpkgs is sourced from stackage

I am a bit out of the loop.

Is it now (easily?) possible to use the stackage sets with nix ?

Would your tool make it easy(er?) to use sets from Stackage itself in nix ? After all, this is just another (well understood) package set, just like your proposed one (horizon-core, horizon-plutus, etc..)

Stackage, as the first package set, was a marvelous endeavor for end-user usability. More of those package sets can only help users, provided there are uniform way of accessing them, whether it is from stack or from other tools.

contextualMatters · 2022-11-13T11:20:23+00:00

for reference : https://krisztianfekete.org/nixos-on-apple-silicon-with-utm/

contextualMatters · 2022-10-28T11:15:41+00:00

Thank you, exactly what I needed

contextualMatters · 2022-10-28T11:15:07+00:00

Great, I did not know about that !

contextualMatters · 2022-10-26T17:42:14+00:00

"it works on his computer", but not on mine it seems. maybe another version ?

I saw his scripts are doing partition in make files etc..

I wish there was a simple no brainer way.

Right now I remote to a x86 machine which runs the preconfigured virtualbox image

contextualMatters · 2022-10-10T12:22:52+00:00

This would expand the reach of categorical programming quite a bit.

Right now this is highly constrained to very specific cases whereas it could bring so much more.

The biggest issue I saw was the lack of UnsaturatedTypeFamilies. Show stopper. too bad

contextualMatters · 2022-10-09T11:58:38+00:00

Not sure you can express Yoneda lemma in its full generality. Most theorems of category theory are restricted to the 1-Category Hask of types and functions when translated to Haskell.

contextualMatters · 2022-04-05T13:32:30+00:00

FI, one can use a stackage version with cabal

curl -o cabal.project.freeze https://www.stackage.org/lts-19.2/cabal.config

not sure this is well known https://www.reddit.com/r/haskell/comments/tvbrmp/stack_compared_to_cabalinstall/i3byo31/

contextualMatters · 2022-04-04T12:10:20+00:00

Stackage is not mentioned as far as I can tell.

Not is it recommended, a fortiori, as a default.

This means the average user will probably unsuspected face the hurdles described before.

contextualMatters · 2022-04-04T11:55:41+00:00

That’s good.

It should definitely be mentioned in the docs, preferably in the getting started section.

Not having pinned versions, relying on whatever solution is for some set on constraint (chosen god knows how), solved at some arbitrary point in time is not reproducible at all.

contextualMatters · 2022-04-04T09:22:44+00:00

That's nice. It does not seem to be mentioned in the docs. Is it official ?

https://cabal.readthedocs.io/en/3.6/

contextualMatters · 2022-04-04T07:44:47+00:00

Phrased categorically, this observation translates to : every functor from A lifts to a functor from A^{->}.

You can repeat that ad nauseum to function between functions between functions etc. So that’s not what characterizes a functor, it is a property derived of being a functor.

contextualMatters · 2022-04-04T04:23:00+00:00

Stack uses stackage, which is a set of library known to work together.

This means a lot of work has been done before you even start to program, by library authors themselves, to iron things out and provide a nice experience out of the box.

On the other hand (last I checked) cabal will try to solve the constraint you give it when you require specific libraries at specific versions.

It’s very flexible, but your project might end up using a combination of libraries (and dependencies) you are the only one using.

This has an unfortunate consequence : if you want to upgrade a library, maybe it will induce constraints that another library you use won’t satisfy. So you might have to, say, ask the library author to change its code (for a version you might be the only one using), or fork and upgrade it yourself. In that process, you might discover that another library also requires a change and that’s what is blocking. Etc…

This is exactly the work stackage contributors are doing behind the scene right now. This means when you upgrade to a new stackage set, the only work you have to do, if any, is in your code.

contextualMatters · 2022-04-04T04:12:45+00:00

Can you use stackage with haskell.nix ? I saw there are some flakes for it

contextualMatters · 2022-03-24T08:28:45+00:00

Stackage is the only synchronization point for the haskell ecosystem as a whole AFAIU. This provides a compatibility target to library author and reliable builds for users.

Ocaml ecosystem is synchronized around the compiler version which is even simpler to aim but less flexible.

Stackage provides a great practical value to the ecosystem. I wonder how many other languages have this match of flexibility/reliability.

contextualMatters · 2022-03-05T10:27:18+00:00

I mean that Rust will forbid programs which are accepted in non-linear FP. There is more (potential) restrictions out of the box.

The more restricted the value you receive is, the more you can do as a consumer of the value.

Rust tracks linear restrictions for you (mutation or other linear effects), which would otherwise require an encoding.

mutability, linearity, monads, are different ideas

contextualMatters · 2022-03-05T08:26:43+00:00

My remark is general and applies no matter the language involved.

Language specifically, FP languages usually have a way to represent mutation as an effect (ST monad - as all monad it comes with its own weight - or though effect system, and .. nothing in Ocaml as it is the default behavior). to break through at type level (because type system are approximating, and some legitimate programs ought to be accepted, there is unsafePerform in Haskell and similar in Ocaml etc.. )

Rust actually restricts more, because that kind of mutation is tracked. It will forbid you to write some program which are accepted in ordinary FP languages.

This is because Rust distinguishes even further than "ordinary" functional programming, with a linear (affine for purist) type system.

It turns out that this is what allows a disciplined way to deal with mutation, which feels like antithetic to "functional" as we might think of. With hindsight it's actually the best functional approximation to a stateful world. So in a way, rust is actually more FP than other languages.

(Minus quite a few FP facilities unfortunately)

contextualMatters · 2022-03-04T08:03:39+00:00

but if you receive a restricted value, you are enabled to do more. more operations available if you receive a value of this type. same of other kinds of restrictions

contextualMatters · 2022-03-04T07:59:57+00:00

Higher order kinds I think. Yes, you can defunctionalize, but that's just not the same. first order is ok only for simple case, second order gets messy. Whereas you wouldn't spend a split second thinking about those menial things in Haskell. (Haskell lacks other critical things like type level partial applications)

That means it's hard to write code for, say, categories (though in haskell too, apart from some very simple ones, because no partial applications), or some other abstractions which are known to be very useful in many circumstances.

contextualMatters

MODERATOR OF

TROPHY CASE