Auto-referencing links

[pveber]

A item of the form Link (n, Item (File n)) or Link (n, Cons (Dir n, ...)) or Link (n, Link (n, ...)) should be detected and forbidden: this is a broken link and is better represented by Broken_link (n, [ n ]). In addition that makes the implementation of some cycle-safe function much easier (reify, for instance).

[pveber]

An additional comment is that Phat_path should maybe become private.

[agarwal]

this is a broken link

Our definition of "broken link" is a link whose target doesn't exist. Now we have to decide what "doesn't exist" means. Does it mean:

i. the path doesn't exist at all, or ii. it doesn't exist as the type of file object specified

If (i), then these examples are not necessarily broken links. If (ii), then the first two are broken: Link to a File, and Link to a Dir. The Link to Link is not broken, just cyclic.

I'm unclear what specific problem there is. When traversing a directory tree (whether for fold or reify), you already have to look for cycles and paths that are broken for any number of reasons. Does a self-reference pose any unique problem?

[pveber]

What's specific here is that you don't even need to look at a filesystem to see that the link is broken: it is broken because of never-ending resolution. So I think something specific should be done for them, which is indeed not sufficient when you want to implement fold of reify, alas...

[agarwal]

So we've got two kinds of broken paths:

• links whose targets don't exist
• paths that are constructed as a cyclic OCaml value, actually in this case it doesn't matter that it is a link

[agarwal]

Closing this issue as it has become a duplicate of #4.

[pveber]

For the sake of completeness, the second case referred to by @agarwal (cyclic ocaml values) is made impossible by 8f1749f.

[agarwal]

Summary of our discussion on 8f1749f1db2ab48685cd83e612ffed5afff81f93, which makes Item a private type.

Pros:

• Cyclic OCaml values are immediately detected. This is a minor benefit since this is unlikely to happen in practice. It has to be done rather deliberately by using let rec.
• Implementation of several functions such as resolve and typ_of is simplified. They no longer have to check for cyclic values. On the other hand, we could simply not do such a check due to point above, which is that cyclic values are unlikely to be created inadvertently anyway. This is common practice. There are plenty of functions in OCaml libraries that would loop infinitely if given a cyclic value. We are perhaps being over cautious here.

Con:

• Can't directly use the GADT constructors, but corresponding constructors that are provided are just as easy to use.

So the pros and cons are both minor. For now, let's stick with the private type to err on the side of providing extra safety.

[agarwal]

For the record, we reverted this in 55772965fe272562bbd68e980674dbfb8214e635. So now we again allow cyclic OCaml values and assume users won't provide such values.