Conditional compilation based on inferred types?

Learning
1

I haven’t followed the evolutions of the macro system nor plugins recently, and I’m wondering if there is anything available these days that would make it possible to select at compilation time a bloc or code or another based on the inferred type of some variable.

I’m thinking of something along the lines of:

let length x =
#match type_of(x) with
# | _ list ->
    List.length x
# | _ string ->
    String.length x
# | _ -> type_error

That would come handy for some lightweight metaprogramming.

2

I don’t think this is possible at the moment. You can implement something like your function using a GADT:

type _ ty = List : 'a list ty | String : string ty 

let length : type a. a ty -> a -> int = fun ty x ->
  match ty with
  | List -> List.length x
  | String -> String.length x

so that you can do length String "hola" and length List [1; 2], but the type argument needs to be explicitly passed, it is not inferred.

Cheers,
Nicolás

2 Likes
3

Jun Furuse did something like this in typpx. I came across it based on a discussion here, and noticed that the project seemed abandoned, so I brought it up-to-date with ocaml 4.10.0 a while back. Jun might have updates to the original project, too. In any case, https://github.com/chetmurthy/typpx

1 Like
4

He did revive it a while ago, you can find it here Files · master · Jun Furuse / typpx · GitLab

5

Just had a look, I guess you meant more specifically the type_of ppx in examples/ppx_type_of · master · Jun Furuse / typpx · GitLab.

Unfortunately, this produces the type (as a string) in the runtime. But to be able to dispatch on the type of some input there must be a preprocessor that selects the appropriate code. Otherwise, I can’t think of any useful specialisation one could implement with that, given the code still has to manipulate the variable which type has been “revealed” by type_of in a generic way only.
Or at least that’s my understanding based on the READMEs.

But maybe you meant that one could use TyPPX as a guide to implement such a preprocessor.
Well, that may well be true, but I’ve dipped my toes in PPX once and I’m not in a hurry to get back into it…

6

Yes, this is what I meant. My original purpose in getting TyPPX working again, was to try to do this. But it seemed like there was a large hill to climb in dealing with typed terms, and I didn’t have the proper tooling to do it well, so I put it off. Specifically, they’re an entire different language (set of AST types) than untyped terms, and I think that any viable approach will have to translate back to untyped terms, annotated with types (which would require an entirely new design). But then there are “environments” and such, and this starts to get out-of-control pretty quickly. So, yeah, I decided it was too much to bite off in one go. I have vague ideas of using attributed-trees and hash-consing as a way of making this viable, but that’s just a vague handwaving mumble.

I don’t see PPX as a significant barrier, personally, but then, I write PPX rewriters all the time, so obviously YMMV.

In any case, I agree with you, that it’s a hard nut to crack.