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

Show HN: Fuse – statically typed functional programming language

fuselang.org

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Show HN: Fuse – statically typed functional programming language

#31

Post by codebje »

thesz wrote: post #25

Nice to see a pretty advanced language at frontpage of HN! From what I understand, GRIN does some parts of supercompilation [1] during optimization process. Supercompilation can prove equivalence of functional programs [2] modulo termination. So you can have something interesting and useful in almost no time. ;) [1] https://themonadreader.wordpress.com/wp-content/uploads/2014/04/super-final.pdf [2] https://www.resear…

Can you expand on your understanding of GRIN doing parts of supercompilation? As I understand it, GRIN doesn't do any supercompilation; it's a structural transformation optimiser built for functional languages, analyzing program flow across function calls for the whole program at once.

As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution traces. The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.

What value would Fuse get from equivalence of terms, do you think?

Re: Show HN: Fuse – statically typed functional programming language

#32

Post by Philpax »

Vedor wrote: post #26
deepsun wrote: post #20

Off topic: what is the most convenient statically typed language that don't require compilation/transpilation? To run instead of bash or Python, but types are mandatory (not just hints like python). I know jShell has been here like 10 years, but I'm not sure it's convenient to quickly write to a file, query a url, etc. .ksh for Kotlin? Typescript (through Deno)? Lua?

OCaml has both compilator and interpreter. Lua isn't statically typed, and while there is Teal – a statically typed variant of Lua – it requires separate build step.

Luau is statically typed and interpreted/JIT'd: https://luau.org/

Re: Show HN: Fuse – statically typed functional programming language

#35

Post by lilbigdoot »

helix278 wrote: post #11

Superficially, I find the syntax very untuitive to read. Most languages opt to use for typevariables. Is there a specific reason you chose to deviate from that and use []?

Scala and a few others use `[]` (the compiler itself is written in Scala)

Re: Show HN: Fuse – statically typed functional programming language

#36

Post by Twey »

the_unproven wrote: post #18
Twey wrote: post #7

Love to see a real-world example of GRIN! trait Functor[A]: fun map[B](self, f: A -> B) -> Self[B]; This looks a little wacky to me. I see that you can write HKTs in their η-long form and refer to them unapplied (`Functor`). But I don't understand how I would use this syntax to attach something to the trait that _doesn't_ depend on `A`. For (a silly) example, trait SizedFunctor[A]: Functor[A]: type Size; fun size(sel…

`Self` isn't the applied type (`List[A]`), rather it's the type constructor of kind `* -> *` constrained by `Functor`. In the map example it gets desugared into: fun map[Self: Functor, A, B](self: Self[A], f: A -> B) -> Self[B]; Since `Self` is the unapplied constructor, `Self[B]` just means `Functor[B]` e.g. `List[B]` not `List[A][B]`. The example you've shown with `SizedFunctor` is not currently supported, as suppo…

Right, I got the notion — but syntactically I expect `Self` to refer to the thing named at the top of the block, which is a `Functor[A]`.

I think what both I and the sibling comment are getting at is that there is a difference between `Functor : (Self : * → *) → Class` and `Functor : (Self : * → *) → (A : *) → Class`/preapplied `Functor : (Self : *) → Class` and the syntax seems to merge the two (using syntax for the latter that is automatically abstracted to the former). But it's not clear to me that you can do that without losing the ability to express some things. The associated type is a pointed example because the unwanted dependence breaks type equality, but consider also an associated function that should _not_ be parameterized by `A`.

Re: Show HN: Fuse – statically typed functional programming language

#37

Post by n_plus_1_acc »

deepsun wrote: post #20

Off topic: what is the most convenient statically typed language that don't require compilation/transpilation? To run instead of bash or Python, but types are mandatory (not just hints like python). I know jShell has been here like 10 years, but I'm not sure it's convenient to quickly write to a file, query a url, etc. .ksh for Kotlin? Typescript (through Deno)? Lua?

https://scala-cli.virtuslab.org/scripting/

Re: Show HN: Fuse – statically typed functional programming language

#38

Post by thesz »

codebje wrote: post #31
thesz wrote: post #25

Nice to see a pretty advanced language at frontpage of HN! From what I understand, GRIN does some parts of supercompilation [1] during optimization process. Supercompilation can prove equivalence of functional programs [2] modulo termination. So you can have something interesting and useful in almost no time. ;) [1] https://themonadreader.wordpress.com/wp-content/uploads/2014/04/super-final.pdf [2] https://www.resear…

Can you expand on your understanding of GRIN doing parts of supercompilation? As I understand it, GRIN doesn't do any supercompilation; it's a structural transformation optimiser built for functional languages, analyzing program flow across function calls for the whole program at once. As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution tra…

> Can you expand on your understanding of GRIN doing parts of supercompilation?

GRIN, if I am not mistaken, performs partial evaluation. For example, it constrains, for each eval site, a set of tags and set of heaps allocations an eval site can receive. This is close to a partial evaluation step of a supercompilation. GRIN does not perform unification, though, it is not described in the original thesis, but data flow graph matching would be close to unification, reducing code size.

> The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.

This can be constrained. Supercompilation usually gets ran to a fixed point, where no partial evaluation steps can be performed that are not unifiable with previously encountered evaluation steps. But supercompilation can be stopped at any point.

I believe you can read on that in Simon Peyton-Jones works, I am unable to find a link to that paper right now, I have troubles with the internet connection.

EDIT: here it is: https://simon.peytonjones.org/improving-supercompilation/

EDIT: Note "tag-bags," it rhymes with the tag sets of GRIN.

> What value would Fuse get from equivalence of terms, do you think?

I think that equivalence of terms is an efficient way to verify properties of programs. Myself, I am looking at consensus protocol implementation verification.

Re: Show HN: Fuse – statically typed functional programming language

#39

Post by Vedor »

Philpax wrote: post #32
Vedor wrote: post #26

Earlier quoted context omitted.

OCaml has both compilator and interpreter. Lua isn't statically typed, and while there is Teal – a statically typed variant of Lua – it requires separate build step.

Luau is statically typed and interpreted/JIT'd: https://luau.org/

Oh, nice, I didn't know - I always thought that Luau has only type annotations and is not statically typed per se. But yeah, looked into the documentation and you can set !strict mode per script, which will cause interpreter to assert the types. Looks promising.

Can you tell me how well it works in practice?

Re: Show HN: Fuse – statically typed functional programming language

#40

Post by codebje »

thesz wrote: post #38
codebje wrote: post #31

Earlier quoted context omitted.

Can you expand on your understanding of GRIN doing parts of supercompilation? As I understand it, GRIN doesn't do any supercompilation; it's a structural transformation optimiser built for functional languages, analyzing program flow across function calls for the whole program at once. As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution tra…

> Can you expand on your understanding of GRIN doing parts of supercompilation? GRIN, if I am not mistaken, performs partial evaluation. For example, it constrains, for each eval site, a set of tags and set of heaps allocations an eval site can receive. This is close to a partial evaluation step of a supercompilation. GRIN does not perform unification, though, it is not described in the original thesis, but data flow…

Thanks for the link to SPJ's notes, I'll read that tomorrow.

Equivalence of terms is an efficient tool for verification; I suspect that isn't really in the set of goals for Fuse, though.

Post reply on HN