search

GrammaticalFramework / gf-core

Grammatical Framework core: compiler, shell & runtimes
https://www.grammaticalframework.org
Other
129 stars 35 forks source link

Publish the pure haskell PGF on Hackage #32

Open heatherleaf opened 5 years ago

heatherleaf commented 5 years ago

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")

odanoburu commented 5 years ago

I second this!

johnjcamilleri commented 5 years ago

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.

odanoburu commented 5 years ago

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?

johnjcamilleri commented 5 years ago

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.

Thomas-H commented 5 years ago

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.

heatherleaf commented 5 years ago

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.

krangelov commented 5 years ago

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 notifications@github.com 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 .

inariksit commented 4 years ago

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

johnjcamilleri commented 3 years ago

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: