From 6a15b464ebb6c19c961204a570db7035c3384fdf Mon Sep 17 00:00:00 2001 From: =?utf8?q?Kim=20Nguy=E1=BB=85n?= Date: Tue, 14 Apr 2015 01:07:46 +0200 Subject: [PATCH] . --- pres-esop15/01.xhtml | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/pres-esop15/01.xhtml b/pres-esop15/01.xhtml index 6a41862..6d2dee3 100644 --- a/pres-esop15/01.xhtml +++ b/pres-esop15/01.xhtml @@ -571,18 +571,6 @@ which is not a type.

  • Provided the operators are sound, the whole language remains type-safe
    • -
    -

    From zippers to XPath

    -

    We use regular expressions over basic &left;/&right; zippers to encode XPath

    - [ [ - [] - [] - [ [] ] - ] - ]]]> -ex_ntree
    -

    rb_tree

    -

    Downward XPath axes

         self :: t ≡    (ẋ & t | _ )&ztop;                                (Init(ẋ) = [], Op(ẋ) = snoc)
@@ -641,6 +629,19 @@ which is not a type.
    
 
 -->
    +
    +

    Binary-tree encoding

    +

    We use regular expressions over basic &left;/&right; zippers to encode upward XPath

    + [ [ + [] + [] + [ [] ] + ] + ]]]> +ex_ntree
    +

    rb_tree

    +
    +

    Upward XPath axes

    @@ -662,7 +663,7 @@ which is not a type.

    ⬆ ⬆ ⬆ ⬆ - parent + parent @@ -681,8 +682,7 @@ which is not a type.

    • Adding path expressions to a functional language such as &cduce; is possible
    • Semantic subtyping and regular expression types play nicely with zippers
      • -
    • In terms of language design, exposing directly zippers patterns to the programmer is a big no-no
      • -
    • Can also be applied to XSLT
      • +
    • In terms of language design, exposing directly zippers to the programmer (still need work at the syntax level)
    • Implementation on-going (including a &cduce; to javascript backend)
    • Extend the approach to Json (google ``path language for json''), i.e. generalise from products to extensible records
    -- 2.17.1