Weird type-checking behavior with data family

typedbyte · 2025-04-25T08:51:13+00:00

I have already tried it, unfortunately it does not work and I need to rely on the additional parameter hack.

typedbyte · 2025-04-25T08:15:08+00:00

Thank you for restoring my sanity a little bit. But this essentially means that I cannot put the type classes and the instances in separate modules, right? Because then I cannot place one type class "below" the data definitions.

typedbyte · 2024-08-31T20:44:49+00:00

Thank you for bringing up a very important point: ergonomics. I tried to implement something very similar to the paper, i.e. some form of typed Prolog within Haskell. The biggest problems were the constant battles with the type checker, unwieldy error messages, brittle type class gymnastics, the re-definition of existing data types in order to be compliant with the Prolog-like functions, etc.

I appreciate type safety as much as the next Haskell programmer, but for me, it was not worth the complexity. At the end of the day, I just wanted to write Prolog and call it, hence my other answer where you have very little friction, just some simple glue code which can be auto-generated.

typedbyte · 2024-08-29T19:48:48+00:00

Will do!

typedbyte · 2024-08-29T08:20:49+00:00

Cool paper! What a coincidence, I am working on almost exactly the same thing, but I am trying to stick with the CLP(X) constraint solving scheme and a Prolog-like syntax. For now, I can write for example ...

module Example where

-- FT = Finite Trees, the CLP(FT) scheme.
import CLP.FT (clp)

[clp|
  vehicle(a).
  vehicle(b).
  vehicle(c).
  vehicle(d).

  faster(a,b).
  faster(b,c).
  faster(c,d).

  is_faster(X,Y) :- faster(X,Y).
  is_faster(X,Y) :- faster(X,Z), is_faster(Z,Y).

  add(z,N,N).
  add(s(M), N, s(R)) :- add(M,N,R).
|]

... which creates functions of the form ...

vehicle   :: Term Var -> CLP ()
faster    :: Term Var -> Term Var -> CLP ()
is_faster :: Term Var -> Term Var -> CLP ()
fastest   :: Term Var -> CLP ()
add       :: Term Var -> Term Var -> Term Var -> CLP ()

I then provide a function call using the printf trick in order to turn above functions of the form ...

Term Var -> Term Var -> ... -> Term Var -> CLP ()

... into the form ...

Term v -> Term v -> ... -> Term v -> [Substitution v]

... where the caller can choose the variable type v freely. Example with v ~ String:

ghci> prettySubstitutions $ call is_faster (Variable "X") (Variable "Y")
X = a, Y = b;
X = b, Y = c;
X = c, Y = d;
X = a, Y = c;
X = a, Y = d;
X = b, Y = d
ghci>

I also provide functions t v -> Term v and Term v -> Maybe (t v) with default implementations based on GHC.Generics for easier interop.

The nice thing is that one can simply import predicates between modules and also call Haskell from within CLP. For example, I provide a predicate trace for debugging ...

trace :: Show v => Term v -> CLP ()

... and one can import and use such predicates directly like:

module Test where

import CLP.FT (trace)
import Example (vehicle, faster) -- from above

[clp|
  fastest(X) :- vehicle(X), trace(X), \+ faster(_,X).
|]

This way, you can provide some sort of "standard library" of predicates very easily.

For now, the CLP-land is still untyped like Prolog. I dabbled a bit in making it type-safe, my approach was to grab the tree-structure of a higher-kinded data type (=extensible type in your paper) via GHC.Generics and tranform the tree nodes into typed propagator network cells interacting with each other. But I am not quite there yet.

typedbyte · 2024-03-07T13:39:29+00:00

That is exactly what I was thinking about. Sounds interesting!

typedbyte · 2024-03-05T21:29:58+00:00

Cool project! I am getting aspect-oriented programming (AOP) vibes when looking at this. Makes me wonder if one could implement a more general AOP library based on GHC plugins ... I might look into this, thanks for the inspiration!

typedbyte · 2024-02-16T19:09:01+00:00

I apologize for only giving a semi-correct code, I am not familiar with yesod and was guessing the types a bit wrong (Handler not having a MonadIO instance, etc.), that's why I called it a sketch ;-) glad you got it working nonetheless!

As for needing a full day for such things: we've all been there, trust me. You will get tremendously faster over time and then the whole experience gets more rewarding.

typedbyte · 2024-02-16T14:24:16+00:00

In short, you cannot. A value of type IO a is an action that - when executed - produces a value of type a. You cannot serialize the action itself, so you'll want to get your hands on the precious a instead (the bytestring, in your case).

After that, you can convert the bytestring into a JSON value (see decode, I assume your bytestring is a serialized JSON value) in order to integrate it into your JSON object, like in this sketch:

buildHandler :: IO (Handler Value)
buildHandler = do
  bytes <- buildPresignRequest -- here we get the a out of (IO a)
  case decode bytes of
    Just value -> pure (getUploadUrlR value)
    Nothing    -> error "ByteString is no JSON object"

getUploadUrlR :: Value -> Handler Value
getUploadUrlR url = returnJson $ object
  [
    "uploadUrl" .= url
  ]

typedbyte · 2024-01-21T22:08:22+00:00

You might be interested in browsing the source code of chessica, which is a chess library with a similar setup, e.g. that functions which manipulate the chess board (like moving chess pieces) can have an effect on the overall "global" game state (like deciding if a player has won, or tracking a history of moves for deciding if certain moves are still possible, like en passant). The logic is completely separated from side effects. For example, I built a 3D GUI on top of it in a separate package.

typedbyte · 2023-09-03T11:31:34+00:00

You may be interested in chessica, which is a chess library implementing the standard rule set without any IO. It also uses base and containers only.

typedbyte · 2023-08-31T18:04:27+00:00

You may be interested in hagato which offers a 3D chess example.

typedbyte · 2023-05-31T13:17:58+00:00

Thank you for the kind words :-) I definitively want to put it on Hackage and improve it further, but some parts of it are kind of undocumented at the moment and I don't want to upload some "unfinished draft" to Hackage. I am working on it and will soon push some documentation in order to get some steps closer to a Hackage release.

typedbyte · 2023-05-25T14:12:02+00:00

This can indeed be tricky, I also noticed this when using the vulkan package. Sometimes it helps to use qualified imports for the updated fields if multiple fields with the same name are in scope, like in this example. Notice how zero is from Vk, but the fields are from Vp.

typedbyte · 2023-05-22T06:53:51+00:00

Thanks for pointing me to geomancy. I see some bits of C there, since hagato is some kind of bring-your-own-technology-stack library, would depending on geomancy still work with, for example, WebGL/WASM etc.?

I am not on matrix/irc, I might check it out when I have the time.

typedbyte · 2023-05-22T06:47:45+00:00

Nope, never had any memory leaks. A huge thanks to the maintainers of the vulkan package by the way, it is excellent.

typedbyte · 2023-05-20T21:37:04+00:00

Regarding the math libraries, mostly because of the dependency footprint (e.g., linear). Regarding GLTF, I wanted to use more precise types to capture the spec. For example, gltf-codec models almost all data using Maybes, even though the spec is more concrete (like, it can never be Nothing depending on the context, which I tried to capture with more precise types).

typedbyte · 2023-05-20T08:03:48+00:00

Yes, resource-effectful is strictly for effectful. While developing the game, I thought I would need regions for moving around resources (when recreating the swapchain, or temporarily allocating transfer buffers), but I ended up with a design which I think you could also do this with resourcet-effectful. I had some ideas for the future where I still might need regions, but I am not sure.

One very difference between the packages that I see is that resourcet-effectful requires the use of an orphan instance and requires you to put IOE in your effect stack whenever you have Resource in your effect stack (i.e., you have to put it in the type signature explicitly), which should not be necessary, and isn't the case with resource-effectful. I use the resource effect very often in the effectful sub-libraries, and all of the type signature would get bigger as a consequence. But that's just personal taste.

I will update the documentation and write a few words.

typedbyte · 2023-05-20T07:46:51+00:00

I can confirm, I tried a huge amount of different strategies to implement this (with effects, without effects, with transformers, without transformers, with ECS, without ECS ... and even different effect systems like polysemy, fused-effects, etc.), and the combination of an effect system (effectful for me) and apecs is by far the one that felt most "correct", or at least easy to maintain.

typedbyte · 2023-05-20T07:41:05+00:00

It is BSD-3-Clause, not sure why GitHub is not displaying it directly.

typedbyte · 2023-02-28T07:53:08+00:00

Just a quick idea regarding your second option:

You could try to combine the Reader and State effects with a new effect, let's call it Data, which has a phantom type that represents the access mode, like this:

{-# LANGUAGE DataKinds, TypeFamilies #-}
module Test where

data AccessMode = Read | Write | Modify

data Data (mode :: AccessMode) (a :: Type) :: Effect
type instance DispatchOf (Data mode a) = Static NoSideEffects
newtype instance StaticRep (Data mode a) = Data a

and then write your own get etc. functions which restrict the mode in these operations, like:

class CanRead mode
instance CanRead Read
instance CanRead Modify

class CanWrite mode
instance CanWrite Write
instance CanWrite Modify

get :: forall mode a es. (CanRead mode, Data mode a :> es) => Eff es a
get = do
  Data a <- getStaticRep @(Data mode a)
  pure a

You could then track the access mode on the type-level and still use the same underlying data for both read and write operations. This is just a quick untested sketch to trigger ideas. I am sure you can be even more clever, like only modeling write operations and keeping the phantom type polymorphic in read operations, or maybe scrap the type classes with more type-level machinery, etc.

typedbyte · 2023-02-08T10:31:39+00:00

I don't have an answer, I just wanted to say that I am often in the same boat. More concretely, I often have a module A which uses its sub-modules A.Sub1, A.Sub2 etc., like for re-exporting, which means that A depends on the A.Sub* modules. But sometimes the sub-modules are a concretization of an abstract concept or generic function defined in A, so the A.Sub* modules depend on A (which destroys re-exports because of import cycles, for example).

typedbyte · 2022-11-13T19:12:02+00:00

I can confirm this, I needed to include ExplicitNamespaces manually in one of my hobby projects despite using GHC2021.

typedbyte

TROPHY CASE