Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

github.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#41

Post by aviaviavi »

m-j-fox wrote: post #33
eutectic wrote: post #30

Earlier quoted context omitted.

It is an equality assertion: https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_gui...

Thanks, but I still don't get it. So SpockState m equals BlockChainState? So getState's type is m BlockChainState? (BlockChainState chain _ _) But it has to be anyway so, I guess I'm still confused. Is the squiggle for extra documentation or is it a hint to help the type inference? Why would type inference need help? Does it have to do with some of the extensions that are applied in the source (but appear to be other…

Also, unless I'm mistaken, TypeFamilies are the relevant GHC extension here. I'm not exactly sure how this would be written differently without that

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#42

Post by solidsnack9000 »

aabaker99 wrote: post #21
solidsnack9000 wrote: post #18

Earlier quoted context omitted.

I think it's too bad we don't have module interoperability. There's never going to be just one programming language. The situation on the JVM -- where Scala, Java and Kotlin can use one another's modules -- is a positive example. Clang modules and Swift's auto-magic import of them is another.

I'm pretty uninformed about libffi but can it help with kind of module interoperability? I've used it to get Ruby to call C functions. I would guess that it could be used for other dynamic languages to call compiled functions such as JS to Haskell like the OP seems to be desiring. Is this true?

I think the problem is more around signatures, actually. If we can find the code, we know how to call it (libffi makes that easy) but how do we expose the library interface?

Clang modules takes some steps towards that for native code. On the JVM, everything is a Java class in the end, with Java type signatures for its methods (which can point to other Java classes, and so on) so rich cross language interfaces are a solved problem.

Other posters have raised concerns about garbage collection or "losing all of the nice features of whatever languages you're using" but I have some doubts:

* Interface definition languages like Protobuf or Cap'N'Proto actually show us just how much commonality there is across languages. They provide for many features that are fancy relative to C but not really relative to anything else; and the interfaces are definitely useful.

* Many languages with sophisticated type systems work by compiling object code and then appending an interface file to capture the type information. Haskell, Rust, OCaml and many others do this, essentially treating every module as foreign code with additional type information.

A good cross language module system would need those features that make sense across languages -- parameterized array and map types among them -- and this does mean, not every piece of Python (for example) would make sense as a Rust library. Consider the interface of the linked project, though -- only `mineBlockFrom` needs to be rethought to be typable in a way that makes sense across many languages.

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#43

Post by KirinDave »

aviaviavi wrote: post #40
KirinDave wrote: post #38

I'm tempted to just make a youtube video going over this code line by line. It's a really great introduction to a non-trivial bit of Haskell.

That would be awesome! Hopefully over time I (or anyone contributing) can spend a little more time making it as idiomatic as possible and beefing up the docs a little bit. Please let me know if you end up doing that!

Okay.

And your code is just very clean and approachable and doesn't try to do popular gymnastics. I'll ping you via GitHub.

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#46

Post by aviaviavi »

seanparsons wrote: post #45
KirinDave wrote: post #38

I'm tempted to just make a youtube video going over this code line by line. It's a really great introduction to a non-trivial bit of Haskell.

Would it make sense to make the code Literate Haskell?

I'm not familiar with Literate Haskell, what would that involve?

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#47

Post by m-j-fox »

aviaviavi wrote: post #39
m-j-fox wrote: post #33

Earlier quoted context omitted.

Thanks, but I still don't get it. So SpockState m equals BlockChainState? So getState's type is m BlockChainState? (BlockChainState chain _ _) But it has to be anyway so, I guess I'm still confused. Is the squiggle for extra documentation or is it a hint to help the type inference? Why would type inference need help? Does it have to do with some of the extensions that are applied in the source (but appear to be other…

Yeah, it's for the compiler, otherwise it can't figure out that a BlockChainState is actually a SpockState m. I'm not really sure how it could otherwise, since the definition is completely decoupled from Spock. It should be noted that it's entirely possible there's a less confusing way to write that type signature. I'm far from an expert in Haskell.

I'm farther from an expert than you. I tried (and failed) to find a less confusing way...

One thing I see people doing when they have real gnarly type signature is to concentrate the horror in one place and paint a veneer of simplicity elsewhere:

    type Get stateType returnType
      = forall monad.
      (SpockState monad ~ stateType, MonadIO monad, HasSpock monad)
      => monad returnType
Then elsewhere:

    getBlockChain :: Get BlockChainState [Block]
    getLatestBlock :: Get BlockChainState Block
This may only help superficially as type errors will still be hard-to-understand.

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#48

Post by aviaviavi »

m-j-fox wrote: post #47
aviaviavi wrote: post #39

Earlier quoted context omitted.

Yeah, it's for the compiler, otherwise it can't figure out that a BlockChainState is actually a SpockState m. I'm not really sure how it could otherwise, since the definition is completely decoupled from Spock. It should be noted that it's entirely possible there's a less confusing way to write that type signature. I'm far from an expert in Haskell.

I'm farther from an expert than you. I tried (and failed) to find a less confusing way... One thing I see people doing when they have real gnarly type signature is to concentrate the horror in one place and paint a veneer of simplicity elsewhere: type Get stateType returnType = forall monad. (SpockState monad ~ stateType, MonadIO monad, HasSpock monad) => monad returnType Then elsewhere: getBlockChain :: Get BlockCha…

Ah, I think this is a better though! If you got this working, feel free to open up a PR. Or I can look into it when I get time.

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#49

Post by KirinDave »

aviaviavi wrote: post #46
seanparsons wrote: post #45

Earlier quoted context omitted.

Would it make sense to make the code Literate Haskell?

I'm not familiar with Literate Haskell, what would that involve?

It's just where the majority of the file is a comment instead of a minority.

Re: Show HN: Legion, an as-simple-as-possible blockchain server written in Haskell

#50

Post by elviejo »

seanparsons wrote: post #45
KirinDave wrote: post #38

I'm tempted to just make a youtube video going over this code line by line. It's a really great introduction to a non-trivial bit of Haskell.

Would it make sense to make the code Literate Haskell?

A literate blockchain implementation?? YES please!!!
Post reply on HN