⌨️ No way to generate spans for input strings at an interactive prompt

[favonia]

Yet another great question/suggestion from @mikeshulman. The library is expecting a file_path in a position, but there's no "file" at interactive prompts. While the internal code is highly modularized and file I/O is isolated, the current external API bundles the file I/O. Here are some concrete fixes I can think of:

1. Rename Position.file_path to Position.source and make its type polymorphic (so that we will have 'source Span.t). Downsides: too many type variables can reduce usability.
2. Still rename Position.file_path to Position.source but fix its type to the following:

   type source = [`File of string | `String of string | `Uri of string ]

In either way, a more generic backend which can handle strings from interactive prompts should be made available. This can be as simple as taking yet another optional argument to handle URIs (if we want to allow them).

[mikeshulman]

I would probably go for (2) myself. Although instead of

type source = [`File of string | `String of string | `Uri of string ]

I would have been inclined to write

type source = File of string | String of string | Uri of string

Is there a reason to use polymorphic variants here?

[favonia]

I would have been inclined to write

type source = File of string | String of string | Uri of string

Is there a reason to use polymorphic variants here?

My main hesitation consists of two parts:

1. Having very generic constructors such as File and String might pollute the constructor namespace. OCaml has type-directed disambiguation, which means it will consider all constructors in scope and others indicated by the types (this might not be accurate because I didn't check its algorithm). Polymorphic variants can stop OCaml from insisting on pinning down the "correct" type. I also think that if an implementer (the one who is building the application) wants to declare such generic constructors, so be it. They can pollute their own constructor namespace. But I tend to be more cautious when designing a library (that might pollute the namespace in all the applications using it).
2. The API should have provided enough helper functions to hide such nasty details in common cases. Perhaps a reasonable design will emerge after we resolve the issue 🧮 Helper functions to recover byte offsets? #88. If this is the case, the burden will be invisible to implementers.

[mikeshulman]

Interesting, thanks. I was not consciously aware of that issue with non-polymorphic variants, although I have been annoyed sometimes at OCaml getting confused when I have constructors in different datatypes with the same name, so maybe I should use polymorphic variants more.