These are chat archives for got-lambda/expression

2nd
Nov 2018
Jean-Louis Giordano
@Jell
Nov 02 2018 09:03
@Zalastax if I wanted to build a full-stack TypeScript application, would you have some recommendations on how to go about it?
Marco Zocca
@ocramz
Nov 02 2018 11:16
@/all if you have time and are interested, consider taking the Haskell community questionnaire: https://airtable.com/shr8G4RBPD9T6tnDf
jolod
@jolod
Nov 02 2018 13:08
A question to the Haskellers: I'm looking at miso and if I look at the WebSocketClose constructor at https://haddocks.haskell-miso.org/Miso-Subscription-WebSocket.html the signature is WebSocketClose CloseCode WasClean Reason.
CloseCode is a simple enum so no question there, but WasClean is a newtype over Bool, and Reason is a newtype over MisoString.
These newtypes, are those there to provide names only? If Haskell had PureScript's records, would you just instead do WebSocketClose { code :: CloseCode, wasClean :: Bool, reason :: MisoString }?
Marco Zocca
@ocramz
Nov 02 2018 13:35
I believe so. But it's not only a matter of structuring nested records, you can give additional typeclass instances to your newtypes. In fact this is the most common rationale for introducing them
I mean in the general case, haven't looked closely at the Miso code (great choice btw)
ok in this particular case, it's just about naming. WasClean and Reason only have Eq and Show
for example if you wanted to give your types Arbitrary instances for quickcheck, or what have you
jolod
@jolod
Nov 02 2018 13:55
Yeah OK, didn't think about quick check. In this case, I think I would write a quick check instance on the WebSocket type instead though. Would you?
jolod
@jolod
Nov 02 2018 14:01
I have an idea for a future meetup. A Haskell getting started session. What's the current approach of doing things, both language wise and for tooling.
I installed GHC, and that also installed stack, and when I first ran "stack build" it downloaded GHC...
It seems I could've just downloaded stack and not bothered with GHC. Or are there other reasons?
... for having a "global" GHC installation I mean.
Marco Zocca
@ocramz
Nov 02 2018 14:09
you shouldn't need a global GHC install
unless you want to hack on the compiler itself
so get rid of that and have a stack in your /usr/local/bin
jolod
@jolod
Nov 02 2018 14:10
Also, I'm on Windows, which doesn't seem to be ideal.
The stack output is littered with what I assume is color control codes.
Marco Zocca
@ocramz
Nov 02 2018 14:11
ah uhm
BTW yes, super up for the Haskell getting started tutorial
jolod
@jolod
Nov 02 2018 14:19
So the stack I got with GHC was version 1.7.1 instead of 1.9.1 which is the latest. I'm uninstalling everything and installing only stack 1.9.1 now.
Pierre Krafft
@Zalastax
Nov 02 2018 14:21
@Jell I prefer to pick up components as I need them so I would go for create-react-app (or a fork if that's needed for TS support out of the box). Server side: any routing framework with TS support that tickles your fancy.
Marco Zocca
@ocramz
Nov 02 2018 14:22
yess. Sorry you fell into this installer trap. Some petty internal politics have prevented settling on a single "blessed" way of installing GHC
Pierre Krafft
@Zalastax
Nov 02 2018 14:22
@Jell my friend recommends next.js
Most choices are fairly sane so it's hard to say what's the best one. Look for good documentation
jolod
@jolod
Nov 02 2018 14:28
@ocramz How are modules handled in Haskell. If a module Foo uses module A internally, and no types from A are present in the exported API from Foo, can a module Bar use a different version of A internally?
Pierre Krafft
@Zalastax
Nov 02 2018 14:30
@Jell what are your needs? A static site? SPA? Server side rendering? GraphQL? What DB?
Marco Zocca
@ocramz
Nov 02 2018 14:31
@jolod different version?
jolod
@jolod
Nov 02 2018 14:31
Yes.
Marco Zocca
@ocramz
Nov 02 2018 14:32
what do you mean with "different version". You mean that two modules X and Y re-export bits of A in different ways, and Foo and Bar use X and Y respectively?
jolod
@jolod
Nov 02 2018 14:32
No, neither re-exports or exposes anything from A. It's completely internal.
Module Foo uses module A version 1. Module Bar uses module A version 2. My program uses modules Foo and Bar, but don't care about A.
Marco Zocca
@ocramz
Nov 02 2018 14:34
how are these versions declared, this I don't get
either they are the same module or they aren't
you mean from different versions of a package?
jolod
@jolod
Nov 02 2018 14:35
Yes, sorry.
Marco Zocca
@ocramz
Nov 02 2018 14:35
oh, ok
no, this shouldn't happen
jolod
@jolod
Nov 02 2018 14:35
What do you mean shouldn't happen?
Marco Zocca
@ocramz
Nov 02 2018 14:36
cabal pins the exact dependency versions once and for all for your project. Every module sees the same version of the dependency
jolod
@jolod
Nov 02 2018 14:36
That's unfortunate.
Marco Zocca
@ocramz
Nov 02 2018 14:36
I think it would be crazy otherwise
jolod
@jolod
Nov 02 2018 14:36
No. It's completely not crazy.
The point is that there's no problem with foo and bar depending on different versions as long as it's just internal.
Marco Zocca
@ocramz
Nov 02 2018 14:37
I cannot think of a fitting use case for this feature. Could you give one?
why should your program see an inconsistent interface? libraries have a version number for a reason
jolod
@jolod
Nov 02 2018 14:39
Because it's different modules, and its only internal. My program sees no inconsistencies.
It's happened to me multiple times. I want to upgrade a module, but some dependency is using a lower version. I now cannot use that dependency, even if that is just internal use. To continue from the meetup examples, I used a graph modules that had a shortest path algorithm, and that used Data.PQueue (priority queue) only for use in that function.
But I couldn't upgrade Data.PQueue because whatever dependency reason, I don't remember why.
I ended up adding the source for the graph library to my project and removed that algorithm because I didn't need it and removed the import of Data.PQueue and then I didn't have a transitive dependency on Data.PQueue anymore and then I could go on with my life.
Marco Zocca
@ocramz
Nov 02 2018 14:44
hmmm. Yeah I see now. It just so happens that the unit of upgrade is the package, and I think there are more advantages than disadvantages to this
for GHC in particular, there are a bunch of breaking changes every so often that are easy to fix, but make maintaining across many compiler versions quite tricky (e.g. force one to compile conditionally via CPP directives etc.)
jolod
@jolod
Nov 02 2018 14:46
What downsides are there to allowing different versions as dependencies for internal implementations?
Jean-Louis Giordano
@Jell
Nov 02 2018 14:46
@Zalastax I'm considering playing around to build a demo shop at Zimpler, so it would probably need to store some state (I guess either postgres or redis), I could go for a relatively dumb front-end. I was a bit curious to play with TypeScript in the backend + front-end, and since TypeScript is still basically JavaScript it might be a good language to write reference implementations of stuff (i.e. if we want to open source that code as an example of how to integrate with Zimpler)
as fun as it might be to write a reference implementation in Clojure(Script) or PureScript, I don't think it would be very useful to the majority of people integrating with us :p So I'm currently toying with the idea
jolod
@jolod
Nov 02 2018 14:48
@ocramz AFAIU, npm uses this system. And if I'm not mistaken, nix uses a similar principle (but I don't know nix at all).
@Jell Are you saying that cljs and PS are niche languages?!? ;-)
Jean-Louis Giordano
@Jell
Nov 02 2018 14:49
@jolod I'm afraid so :p
jolod
@jolod
Nov 02 2018 14:50
You have shattered my FP bubble!
Jean-Louis Giordano
@Jell
Nov 02 2018 14:50
:D
Pierre Krafft
@Zalastax
Nov 02 2018 14:51
@Jell sounds like a great idea! I suspect you want the focus to be your business code so I'd go for a "complete" solution like next.js. I know there should be a good DB abstraction for Postgres in TS as well.
Jean-Louis Giordano
@Jell
Nov 02 2018 14:52
yes exactly! ok thanks for the tip @Zalastax I'm gonna have a look
Marco Zocca
@ocramz
Nov 02 2018 14:52
@jolod ok say you have modules Foo and Bar in your project, importing A@v1 and A@v2 respectively. Let's say the build system doesn't let you re-export A from your project, but what's to block you from importing both A@v1 and A@v2 in one same module?
ok, perhaps there could be additional checks
I don;t know it sounds like a big complication
jolod
@jolod
Nov 02 2018 14:53
Well, it isn't. :-)
It's annoying if you're the developer of the package system, but not from a user perspective.
Marco Zocca
@ocramz
Nov 02 2018 14:54
I always think as a maintainer :)
Pierre Krafft
@Zalastax
Nov 02 2018 14:54
@Jell @jolod good TS design still leans on FP culture. You just need to squint a lot.
jolod
@jolod
Nov 02 2018 14:54
@ocramz Same here, which is why I don't want implementation details to break my program.
Marco Zocca
@ocramz
Nov 02 2018 14:55
hey, I don't make the rules. Open an issue on the Cabal bugtracker if you think it should be added
jolod
@jolod
Nov 02 2018 14:55
@ocramz The concept of a pure function that you can rewrite it whatever way as long as it returns the same output from the same input, breaks when you allow module versions to break such a refactoring.
No one cares about package management. :-(
It's always an after thought, but IMHO it's one of the most important pieces of a programming "language system".
In PS I believe this is never going to be fixed based on how PS compiles to JavaScript--it's completely flattened. But I was hoping that Haskell would've fixed it by now.
Marco Zocca
@ocramz
Nov 02 2018 14:58
the package version number is a meta-linguistic annotation, even if A.glob@v1 and A.glob@v2 have the same name, they are not the same function
and shouldn't be relied upon to be the same
jolod
@jolod
Nov 02 2018 14:58
A.glob@v1, is that legal syntax somewhere? Or is that just your notation?
Marco Zocca
@ocramz
Nov 02 2018 14:59
my notation. Ok sorry I'm re-assessing what I just said
jolod
@jolod
Nov 02 2018 14:59
@ocramz OK. Yeah, of course they are different.
That's why they need to be able to coexist.
Marco Zocca
@ocramz
Nov 02 2018 15:00
but let me understand what was the problem exactly? Did the type change, or the runtime behaviour?
jolod
@jolod
Nov 02 2018 15:02
One package I wanted to use required version 2.0.0 of a dependency and another package required version 1.0.0 of that dependency. Nothing have to change for this scenario to happen. It's just that I can now not use both packages in my program.
Marco Zocca
@ocramz
Nov 02 2018 15:03
So they were specified as equality bounds? Like == 2.0.0 etc.? not as inequalities? This is bad practice
but yeah, nobody prevents from using this
jolod
@jolod
Nov 02 2018 15:03
No, 2.0.0 is incompatible with 1.0.0. That's the meaning of semver.
I think both used the ^ notation or whatever it is.
Marco Zocca
@ocramz
Nov 02 2018 15:04
ah
it's a new-ish cabal feature.
Honestly, I never encountered such a problem. What's the dependency? I've got to investigate
jolod
@jolod
Nov 02 2018 15:04
This is PureScript btw, but exactly the same situation would arise in Haskell if the dependencies are flattened an "global" to the program.
Marco Zocca
@ocramz
Nov 02 2018 15:05
yeah.
jolod
@jolod
Nov 02 2018 15:05
I'm surprised you haven't hit this issue.
I think that npm uses isolated dependencies for good reason.
You can mix and match. You can even re-export and return objects from version 1 in the same function as you have version 2 objects, because you wouldn't have any type name collisions.
Marco Zocca
@ocramz
Nov 02 2018 15:07
and how are names discriminated?
jolod
@jolod
Nov 02 2018 15:07
In npmjs?
Marco Zocca
@ocramz
Nov 02 2018 15:07
btw there's a lengthy discussion on Haskell package versioning here: https://pvp.haskell.org/faq/
jolod
@jolod
Nov 02 2018 15:08
In JavaScript you don't have to discriminate between names. A package can only specify one dependency directly, but any dependencies can do the same and those versions can be whatever.
When a dependency is built, it uses its dependencies and the version it specified.
It's not flattened.
Marco Zocca
@ocramz
Nov 02 2018 15:10
I'm not qualified to make a broad statement on the relative merits of the two systems. Can only tell you how Cabal/Haskell work right now
jolod
@jolod
Nov 02 2018 15:10
(I'm not expert on how npm does things.)
From what I've heard, it's a bit of a program in the Haskell community that people do breaking changes to their modules. Has this not been your experience?
Btw, as long as we don't have good package support for our languages, I think it's a bad idea to bump the major version on any release. It should be a new release instead. That's annoying, because you don't find that you have a new version automatically, but it prevents a lot of bit rot.
With "new release" I mean a new package. Could even have the name "oldPackage2".
where oldPackage is replaced by the old package name.