gf-core icon indicating copy to clipboard operation
gf-core copied to clipboard

Publish the pure haskell PGF on Hackage

Open heatherleaf opened this issue 6 years ago • 9 comments

GF is on Hackage, which is great. But sometimes you don't need the full power of GF, but it's ok with the Haskell-only PGF runtime (subdir src/runtime/haskell). It even has a cabal file already (pgf.cabal), so I guess it should be fairly easy.

(To be clear: I don't want to remove GF from Hackage, but add another package "PGF")

heatherleaf avatar Jan 17 '19 08:01 heatherleaf

I second this!

odanoburu avatar Jan 17 '19 10:01 odanoburu

But is having a separate package which contains code duplicated from somewhere else really a good idea? If you know what you need then as you say everything is already there.

johnjcamilleri avatar Jan 17 '19 11:01 johnjcamilleri

my understanding is that pgf would become a dependency of gf, so that Haskell projects wouldn't need to specify the whole gf as a dependency in order to simply get pgf. is that what you meant too, @heatherleaf?

odanoburu avatar Jan 17 '19 11:01 odanoburu

Ah, that makes more sense. I discussed this with @Thomas-H and @krangelov not long ago, if I understood correctly there was actually a plan to do this but in the end it was harder than expected to separate the two completely. The dependency between them is not really one-directional, in the sense that a change to the PGF format requires both to be updated together. Correct me if I'm wrong.

johnjcamilleri avatar Jan 17 '19 12:01 johnjcamilleri

I did some work ~2015 to eliminate the mutual dependencies between the GF.* and the PGF.* modules, and as a result of that it was possible to create pgf.cabal, which contains only the PGF.* modules.

It would be a fairly easy to change gf.cabal to refer to the pgf package instead of enumerating the PGF.* modules. The reason I didn't make that change back then is that I didn't know of a covenient way to co-develop two packages (gf and pgf). I think that is easier nowadays, e.g. if you create cabal sandbox, you can build several packages with one 'cabal build' command. Cabal keeps track of the dependencies and rebuilds everything as needed.

So maybe for the next release, we should split out pgf from gf and make these packages available separately. This wouldn't make it harder to install GF, one command cabal install gf would still be enough download and install both packages from Hackage.

Thomas-H avatar Jan 17 '19 14:01 Thomas-H

my understanding is that pgf would become a dependency of gf, so that Haskell projects wouldn't need to specify the whole gf as a dependency in order to simply get pgf. is that what you meant too, @heatherleaf?

Well, that's not exactly what I meant, even though it would be nice if that could work. The main reason I want this is that if you develop a pure-Haskell program and have no interest in the compiled gf binary or anything else, then it's just unnecessary to have to wait for gf to compile. I have no problems with having the pgf source code duplicated on my computer.

So maybe for the next release, we should split out pgf from gf and make these packages available separately. This wouldn't make it harder to install GF, one command cabal install gf would still be enough download and install both packages from Hackage.

If that works, then it's of course the best solution.

heatherleaf avatar Jan 17 '19 15:01 heatherleaf

In the repo there is a branch called "c-runtime". There the compiler is completely separated from the runtime. That version of the runtime also has an API for creating new PGFs. This is all the magic that the compiler needs.

The other feature there is that the compiler can be build either entirely on top of the C runtime or on top of the Haskell runtime.

This is the direction that I would like to follow.

On Thu, 17 Jan 2019 at 13:02, John J. Camilleri [email protected] wrote:

Ah, that makes more sense. I discussed this with @Thomas-H https://github.com/Thomas-H and @krangelov https://github.com/krangelov not long ago, if I understood correctly there was actually a plan to do this but in the end it was harder than expected to separate the two completely. The dependency between them is not really one-directional, in the sense that a change to the PGF format requires both to be updated together. Correct me if I'm wrong.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GrammaticalFramework/gf-core/issues/32#issuecomment-455148316, or mute the thread https://github.com/notifications/unsubscribe-auth/ATBZZBKck_dEBhLzOG7W8Klu2AwN2r0vks5vEGZcgaJpZM4aEsvB .

krangelov avatar Jan 17 '19 17:01 krangelov

Do we have plans for doing this, e.g. for the next release?

inariksit avatar Dec 12 '19 13:12 inariksit

Using just PGF without GF is actually quite easy to do, and doesn't require publishing pgf to Hackage.

Cabal

Firstly, in your cabal file, specify pgf instead of gf:

build-depends:
  pgf

Installing pgf globally

To install the pgf Haskell library globally using cabal, do:

cd gf-core/src/runtime/haskell
cabal install

With Stack

If you are using Stack, you can specify it in this way:

From local source

extra-deps:
- /Users/john/repositories/GF/gf-core/src/runtime/haskell

From GitHub

extra-deps:
- git: https://github.com/GrammaticalFramework/gf-core
  commit: 3a27fa0d390b86cab3ecc68418e4116ea5c4f8ba
  subdirs:
    - src/runtime/haskell

The same applies to pgf2. In fact, I had uploaded PGF2 to Hackage, motivated by the same reasons as the OP. But after discovering this way of doing it, I realise it wasn't necessary after all.

This being said, it is admittedly strange that gf and pgf2 are on Hackage, but pgf isn't. Since it is not possible to delete packages from Hackage, the options are either:

  • Deprecate pgf2 on Hackage, and maintain only gf.
  • Also upload pgf to Hackage, as originally suggested, and maintain all three.

johnjcamilleri avatar Jul 06 '21 14:07 johnjcamilleri