Open heatherleaf opened 5 years ago
I second this!
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.
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?
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.
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.
my understanding is that
pgf
would become a dependency ofgf
, so that Haskell projects wouldn't need to specify the wholegf
as a dependency in order to simply getpgf
. 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.
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 .
Do we have plans for doing this, e.g. for the next release?
Using just PGF without GF is actually quite easy to do, and doesn't require publishing pgf
to Hackage.
Firstly, in your cabal file, specify pgf
instead of gf
:
build-depends:
pgf
pgf
globallyTo install the pgf
Haskell library globally using cabal, do:
cd gf-core/src/runtime/haskell
cabal install
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:
pgf2
on Hackage, and maintain only gf
.pgf
to Hackage, as originally suggested, and maintain all three.
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")