MicroHs and Hackage

Announcements
42

It seems that there is an interest in developing a staged programming system in MicroHS with the introduction of a means to perform compile time evaluation.

Distinguishing a staged system from "Template Haskell” metaprogramming sounds quite important.

  • Staged Programming: Ability to separate a program into different stages, where prior stages generate later stages.
  • “Template Haskell” metaprogramming: The ability to perform intensional syntax analysis and construction.

If MicroHS supported staged evaluation then it could support programming in a typed template haskell style (without access to the introspection features, which I think is what Lennart dislikes?).

This would provide additional motivation to disentangle the untyped and typed template haskell extensions from each other rather than just lumped together in “TemplateHaskell”.

11 Likes
43

If you decide to continue down this route, I would highly recommend building in a static list of overridden packages somehow. Otherwise, if it’s a dynamic check, it becomes way too easy for an attacker to inject nasty code into somebody’s project. They would simply pick some commonly-used package that doesn’t have an “override” yet (let’s imagine containers-mhs), then create the package with a nasty payload.

Cleaning that up in the future would probably be a lot harder than avoiding the situation in the present. :slight_smile:

1 Like
44

There is a static list. It’s compiled into MicroCabal.

I’m hoping there will only be a few -mhs packages, but that depends on package maintainers.

3 Likes
45

I used to hear that people wanted to make an outright replacement for template haskell, like a more elegant version that could deprecate current TH. I wonder if that sentiment still rings true

46

It’s not easy to design such a thing.

2 Likes
47

For sure , writing some sort of TH2 would have been a lot of work, but If people have had the time to burn for the complex task of implementing it, it likely would have been a welcome change.
I gather TH had a lot of deficiencies, more than it has now. Like for the longest time TH blocked cross compilation and such ( which is why it just became compatible with the wasm backend ) .

So now that people are talking about implementing some subset of TH , i wonder if the haskell community still thinks TH should be replaced, or whether all of its issues are on its way to be progressively addressed

48

i sort of knew that the biggest hurdles are:

  1. internal ghc changes affect th api
  2. unrestricted io makes compile time code more difficult to “make available” (interpreter needed, platform specifics creep in?)

happy to be corrected by someone more knowledgeable :slight_smile:

1 Like