profile
viewpoint

sliquister/batteries-included 1

Batteries Included project

sliquister/camlp4 0

Camlp4 tool

sliquister/dune 0

A composable build system for OCaml

sliquister/notty 0

Declarative terminal graphics for OCaml

sliquister/ocaml 0

The core OCaml system: compilers, runtime system, base libraries

sliquister/ocaml-compiler-libs 0

compiler libraries repackaged

sliquister/ocaml-inotify 0

OCaml bindings for inotify.

sliquister/regex 0

An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.

sliquister/utop 0

Universal toplevel for OCaml

issue commentjanestreet/ppx_fields_conv

Unused module Direct/Fields error

(closed because it is fixed at the tip of the repo)

copy

comment created time in a month

issue commentjanestreet/ppx_fields_conv

Does not build with ppxlib 0.14.0

Is this still a problem? I know little about how the versioning story here, but the code at the current tip of this repository does not have this type error.

glondu

comment created time in 2 months

PR closed janestreet/ppx_fields_conv

Upgrade to ppxlib 0.14.0 forwarded-to-js-devs

The next release of ppxlib will use the 4.10 AST internally. This PR makes ppx_fields_conv compatible with this new version. Probably worth waiting for the new release before merging this!

+3 -3

1 comment

2 changed files

NathanReb

pr closed time in 2 months

pull request commentjanestreet/ppx_fields_conv

Upgrade to ppxlib 0.14.0

Thanks for the pull request. The current tip of the repository apparently got fixed on August 10, with the same fix as your pull request (I'm guessing this new ppxlib version was imported internally, the tree was fixed, and then the fixes were exported to the various ppx repos), so nothing more to do here.

NathanReb

comment created time in 2 months

issue closedjanestreet/ppx_fields_conv

Feature request: custom module

Is it possible to have generated fields at custom module like:

module M = struct
  type a = { x : int; y : int }
  [@@deriving fields: GetA]

  type b = { x : int; y : int }
  [@@deriving fields: GetB]
end

let f : M.b = let f : M.a = { x = 42; y = 42 } in
  { M.b.x = [%fields_module M.a].x f
  ; M.b.y = [%fields_module M.a].y f }

closed time in 2 months

Pitometsu

issue commentjanestreet/ppx_fields_conv

Feature request: custom module

I'm going to close this, as this is old and it's not clear if the reporter still wants this and if so, why my suggestion wouldn't be enough.

That being said, the people that get notified when issues are reported are now more relevant and numerous, so new issues should be much more likely to be discussed/clarified at the time they get reported, instead of way later when the motivation may be gone.

Pitometsu

comment created time in 2 months

issue closedjanestreet/ppx_fields_conv

Custom name

Support custom names for fields?

closed time in 2 months

goodmind

issue commentjanestreet/ppx_fields_conv

Custom name

I'm going to close this, as this not really actionable given the lack of response (of course the lack of response is in large part due to the fact that we took forever to respond, but the people that get notified when issues are reported are now more relevant and numerous, so new issues will presumably not suffer such a fate).

goodmind

comment created time in 2 months

issue commentjanestreet/ppx_fields_conv

Feature request: custom module

This [%fields_module: ..] is not implementable, as it would be require deriving fields to be in the same file as [%fields_module: ..], and computing scoping which can't be done in a ppx.

Are you saying that, for:

type a = { x : int; y : int }
[@@deriving fields GetA]

ppx_fields_conv would generate

module GetA : sig
  val x : a -> int
  val y : a -> int
  module Fields_of_a : sig ... more things ... end
end

?

Technically, this would be easy, but the value seems marginal? Can't you just do this:

module M = struct
  module A = struct
    type t = { x : int; y : int }
    [@@deriving fields]
  end
  module B = struct
    type t = { x : int; y : int }
    [@@deriving fields]
  end
  type a = A.t
  type b = B.t
end

let f : M.b =
  let f : M.a = { x = 42; y = 42 } in
  { x = M.A.x f
  ; y = M.A.y f }
Pitometsu

comment created time in 2 months

issue commentjanestreet/ppx_fields_conv

Custom name

Are you talking about the Fields module, are you saying you want values generate for field a to not generate labels ~a but instead some other label?

Either way, what's the motivation for this? If the former, it's possible to simply write module Xyz = Fields after the @@deriving.

goodmind

comment created time in 2 months

issue commentjanestreet/ppx_fields_conv

Unused module Direct/Fields error

Hum, apparently we turn off warning 60, which explains why we don't see this. Without thinking too long about this, I think both suggestions make sense. We already silence all value level and type level warnings, we might as well silence the module ones too. For the second suggestion, we want a way to just get a subset of the values to reduce bloat anyway.

copy

comment created time in 2 months

issue commentjanestreet/ppx_fields_conv

Unable to only load ppx_fields_conv in top-level (utop)

Please include the actual errors when you report bugs. I'm seeing this, which may be what's being reported, but I can't be sure:

$ utop
...
utop # #require "ppx_fields_conv";;
No such package: ppx_deriving - required by `ppx_fields_conv'

We don't use ppx_deriving. It seems to come because the dune file says (kind ppx_deriver). I'll leave it to @xclerc or @jeremiedimino to look at this one, because it seems to be a problem with the exporting of code to opam or dune or this kind of operation being unsupported.

RogerTarani

comment created time in 2 months

more