<div dir="ltr"><div>I suggested a way to improve lens debug earlier in this thread. I think it would be very useful if the debug message included the trees generated in the various situations. For example with the error given by Free earlier:<br>
<br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">lenses/interfaces.aug:27.3-.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
65:Failed to compile auto<br>
lenses/interfaces.aug:27.19-.63:exception: ambiguous concatenation<br>
<div>      'auto\\\nA# A\n' can be split into<br>
      'auto\\\nA|=|# A\n'<br>
<br>
     and<br>
      'auto\\\nA# A|=|\n'<br>
<br>
</div>    First lens: lenses/interfaces.aug:21.37-.100<br>
    Second lens: lenses/interfaces.aug:27.50-.62<br>
</blockquote><br><br>it could say (or I'm guessing it could):<br><br><br>lens/interfaces.aug:27.3-.65:Failed to compile auto<br>lenses/interfaces.aug:27.19-.63:exception: ambiguous concatenation<br>    The string 'auto\\\nA# A\n' can be split into<br>
    'auto\\\nA|=|# A\n' generating the tree<br><div style="margin-left: 40px;">{ "auto"<br>   { "1" = "A"<br>      { "comment" = "A" } } }<br>
</div>    <br>   and<br>    'auto\\\nA# A|=|\n' generating the tree<br>          { "auto"<br>             { "1" = "A# A" } }<br>       First lens: lenses/interfaces.aug:21.37-.100<br>
       Second lens: lenses/interfaces.aug:27.50-.62<br>

<br><br><div>This would make it much clearer already imo.<br><br></div><br>Raphael<br><br><br><br><div class="gmail_quote">On Tue, Aug 26, 2008 at 12:17 AM, Nate Foster <span dir="ltr"><<a href="mailto:jnfoster@cis.upenn.edu">jnfoster@cis.upenn.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> That's a very nice idea .. typing wise I assume the result of probe is a<br>

> lens, i.e. probe is a function string -> lens -> lens ?<br>
<br>
</div>Exactly. I've found probe most useful for debugging lenses built up<br>
using sequential composition, but as I said it's also handy for<br>
zooming in on a part of a big concatenation, one arm of a union, etc.<br>
<br>
Something else we've been working on (but this is a bigger task) is<br>
enhancing the surface language with full-blown dependent and<br>
refinement types. So we write functions like this:<br>
<br>
  let f (l1 : lens in S1 <-> V1) (l2 : lens where splittable S1 (ctype<br>
l2)) : lens = ...<br>
<br>
The interpreter checks that when you call f, you have to pass it<br>
lenses satisfying the precise conditions in the type. This gives<br>
programmers a way to express the conditions that are actually needed<br>
to typecheck the body of the function (something they have to<br>
calculate manually) which can with error messages since the finger<br>
gets pointed at the actual problem.<br>
<br>
Nothing is written down in paper form yet, but the slides from<br>
Benjamin Pierce's MFPS talk from May, "Types considered harmful", has<br>
a few details.<br>
<font color="#888888"><br>
Nate<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
augeas-devel mailing list<br>
<a href="mailto:augeas-devel@redhat.com">augeas-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/augeas-devel" target="_blank">https://www.redhat.com/mailman/listinfo/augeas-devel</a><br>
</div></div></blockquote></div><br></div>