[augeas-devel] Lens debug messages (Was: [Interfaces] Draft lense)

[Raphaël Pinson]

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:

lenses/interfaces.aug:27.3-.

65:Failed to compile auto
> lenses/interfaces.aug:27.19-.63:exception: ambiguous concatenation
>       'auto\\\nA# A\n' can be split into
>      'auto\\\nA|=|# A\n'
>
>     and
>      'auto\\\nA# A|=|\n'
>
>     First lens: lenses/interfaces.aug:21.37-.100
>    Second lens: lenses/interfaces.aug:27.50-.62
>


it could say (or I'm guessing it could):


lens/interfaces.aug:27.3-.65:Failed to compile auto
lenses/interfaces.aug:27.19-.63:exception: ambiguous concatenation
    The string 'auto\\\nA# A\n' can be split into
    'auto\\\nA|=|# A\n' generating the tree
{ "auto"
   { "1" = "A"
      { "comment" = "A" } } }

   and
    'auto\\\nA# A|=|\n' generating the tree
          { "auto"
             { "1" = "A# A" } }
       First lens: lenses/interfaces.aug:21.37-.100
       Second lens: lenses/interfaces.aug:27.50-.62


This would make it much clearer already imo.


Raphael



On Tue, Aug 26, 2008 at 12:17 AM, Nate Foster <jnfoster at cis.upenn.edu>wrote:

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