6 ms·

Agreed, XSLT 3.0 is amazing... and XQuery provides a more palatable syntax, with similar semantics. Kinda ironic that given the problem definition no solution

Agreed, XSLT 3.0 is amazing... and XQuery provides a more palatable syntax, with similar semantics. Kinda ironic that given the problem definition no solution has been provided on XQuery or XSLT yet, the widely used domain specific languages that better suit the problem :-). I believe there's a lot of inspiration to be had from the X-family of languages. The "secret sauce" is XPath. We need a new language drawing inspiration from the tree processing of X* languages but with more modern syntax and less with a less byzantine type system (read: anything but XML Schema :-). Less angle brackets would help too! --- Bonus points: add tuples and prolog like queries to such language (thinking of SPARQL) ... now that would be something really powerful.

bmn__ 6y ago
> We need a new language drawing inspiration This exists (optics/lenses), but most programmers don't know about it. I expect this to hit mainstream programming languages a few years later. I don't know of a simple, jargon-free explanation of the concepts. WP is useless, sadly. http://enwp.org/Bidirectional_transformation http://enwp.org/Bidirectional_transformation Also see: https://news.ycombinator.com/item?id=24710565 https://news.ycombinator.com/item?id=24710565
- josevalim 6y ago
  Thanks for sharing! Solutions to this problem in the vein of jq and optics were precisely why I started the repo above.
- bradrn 6y ago
  > This exists (optics/lenses), but most programmers don't know about it. … I don't know of a simple, jargon-free explanation of the concepts. Let me have a go! I’d explain optics/lenses as giving field access as a data structure. That is, a lens is an object which describes how to access an element from a ‘larger’ value. For example, you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b (Using Haskell syntax here as that’s what I know best, though I’ve simplified the types slightly.) The great advantage of having these as first-class values is that you can now manipulate them. Of course, the main things you’ll want to do with these are get and set things: > (1,2) ^. _1 1 > (1,2) & _1 .~ 3 (3,2) More interestingly, you can also use a function to modify the value to which a lens is pointing: > (1,2) & _1 %~ negate (-1,2) Most usefully, you can also compose lenses. For instance, to get the second element of the first element of a nested tuple, you can compose _2 and _1 using dot notation: _1._2 :: Lens' ((a,b),c) b Or, for a more realistic example, here’s a lens which accesses the ‘numSeen’ field of the value corresponding to key "keyToIncrement": (ix "keyToIncrement")._numSeen :: Lens' (Map String MyStructure) Int (Well, strictly speaking, this is actually a traversal or a prism or something, because "keyToIncrement" might not exist, but let’s ignore that for this really simple example…) And now that you have it, you can use this new lens to do anything you want with this value: you can get it, set it, increment it, decrement it, print it, etc. Additionally, you don’t have to restrict yourself to just lenses. For example, ‘traversals’ are a generalisation of lenses which allow you to access 0, 1 or more elements, rather than restricting access to just one element at a time. For instance, you can use ‘both’ to transform, well, both elements of a tuple: > (1,2) & both 5~ negate (-1,-2) Or you can use ‘traversed’ to access each element of, say, a list: > [1,2,3,4,5] & traversed .~ 0 [0,0,0,0,0] Of course, there are other ways of doing each of these. If you happen to be working with mutable values, you can sometimes use dot notation to access deeply nested fields. Some usecases of ‘traversed’ can be replaced by a map. However, there really is no comparable substitute for lenses when working with deeply nested immutable structures, especially ones of unknown shape.
  - alehander42 6y ago
    thanks! i think i now understood the idea
  - gugagore 6y ago
    > you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b From the looks of it, this is to access the first and second element specifically of a 2-tuple. I suppose if you had to generalize it, you would actually get a traversal or a prism or something, because those elements might not exist.
    - bradrn 6y ago
      > From the looks of it, this is to access the first and second element specifically of a 2-tuple. Yes, this is correct. (I don’t know about other languages, but it’s worth noting that in Haskell, tuples are of fixed size — 2-tuples, 3-tuples etc. are considered completely different types. A result of this is that ‘tuple of any length’ is not a valid concept in Haskell; you have to write a separate definition for each tuple size.) > I suppose if you had to generalize it, you would actually get a traversal or a prism or something, because those elements might not exist. Well, it depends how you generalise it. Haskell lens libraries, for instance, use a more general type which allows _1 and _2 to work with 2-tuples and larger, _3 to work with 3-tuples and larger, _4 to work with 4-tuples and larger, and so on. Thus these remain lenses, as they always access exactly one value. Another generalisation is to define a lens allowing access of an arbitrary element of a list. This may not return a value, and thus is indeed a traversal.
  - alehander42 6y ago
    however: why those instead of iterators or functions? how is a `lens` not a function in general (or a yielding iterator) which return some kind of views?
    - Twisol 6y ago
      In the face of mutation and dynamic typing, yes, an iterator providing mutable references to the focused piece of the subject would give you something basically like a traversal (a generalization of a lens over list-like things). However, consider the case of a struct with five fields, each of a different type -- you can't just for-each over those. And you don't quite have the black-box composability benefits of lenses, since you need a value to iterate over. A lens is a (1) functional (2) bi-directional (3) first-class and (4) composable generalization of (5) struct field names in most traditional languages. 1) "Functional" meaning we eschew mutation and implicit context. Mutation is a very powerful feature of a language, and much can be encoded using it. When we remove mutation as an option, many of the things we would have just used mutation for separate into distinct and rich solution spaces. 2) "Bi-directional" meaning we can use the same widget for both accessing a sub-part of a whole, and for replacing that sub-part within a whole. I personally call these operations "extract" and "replace", since "get" and "set" feel like they raise the specter of mutability. 3) "First-class" means that the lenses themselves are manipulable constructs within the language. In a language like C or Java, I can have "obj.a.b.c", but I cannot have ".a.b.c" itself on its own. Even if you consider method references (like "Obj::a" in Java), you've only obtained the ability to extract the "a" field from an Obj -- any particular method or function is only going to go in one direction. 4) "Composable" means that you can take two lenses and fit them together to get a new lens. Conceptually, I think this is understood -- we intuitively understand how to navigate an object graph when writing down an expression like "obj.a.b.c" -- but having a composable first-class abstraction lets us do the same thing programmatically. (It need not even be at "runtime" -- imagine a compile-time macro system that programmatically generates nested accesses from some base rules you define. I think you've got the rudiments of a dependency injection system here.) 5) "Struct field" means that for the given type, the field is always accessible. "List element" (or "tree leaf", ...) would give you traversals instead of lenses, and "tagged union variant" / "subclass" would give you prisms. As for potential applications of the approach, there's the approach dependency injection graphs outlined above. I've also used ideas from lenses/prisms in serialization/deserialization and web service middleware. (Middleware compose really well as functional optics!) With profunctor optics, you can even construct self-describing operations. For instance, imagine a JSON parser that can be directly interrogated to obtain the schema it accepts, or a middleware stack that can be interrogated to determine which headers it looks at, and which routes it accepts. Personally, this is the area I'm most excited about with functional optics.
- emmanueloga_ 6y ago
  optics/lenses solve this problem in a framework that is jargon-heavy and difficult to understand, and most implementations I've seen use languages with very strict type system. The XSLT+XPath approach is more dynamic, easier to grasp (imho) and can probably be learned in an afternoon. Tradeoffs, tradeoffs... I wouldn't want to write most programs in Haskell but you could write pretty much any program in, say, JavaScript ... :-)

bmn__ 6y ago

> We need a new language drawing inspiration This exists (optics/lenses), but most programmers don't know about it. I expect this to hit mainstream programming languages a few years later. I don't know of a simple, jargon-free explanation of the concepts. WP is useless, sadly. http://enwp.org/Bidirectional_transformation http://enwp.org/Bidirectional_transformation Also see: https://news.ycombinator.com/item?id=24710565 https://news.ycombinator.com/item?id=24710565

josevalim 6y ago
Thanks for sharing! Solutions to this problem in the vein of jq and optics were precisely why I started the repo above.
bradrn 6y ago
> This exists (optics/lenses), but most programmers don't know about it. … I don't know of a simple, jargon-free explanation of the concepts. Let me have a go! I’d explain optics/lenses as giving field access as a data structure. That is, a lens is an object which describes how to access an element from a ‘larger’ value. For example, you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b (Using Haskell syntax here as that’s what I know best, though I’ve simplified the types slightly.) The great advantage of having these as first-class values is that you can now manipulate them. Of course, the main things you’ll want to do with these are get and set things: > (1,2) ^. _1 1 > (1,2) & _1 .~ 3 (3,2) More interestingly, you can also use a function to modify the value to which a lens is pointing: > (1,2) & _1 %~ negate (-1,2) Most usefully, you can also compose lenses. For instance, to get the second element of the first element of a nested tuple, you can compose _2 and _1 using dot notation: _1._2 :: Lens' ((a,b),c) b Or, for a more realistic example, here’s a lens which accesses the ‘numSeen’ field of the value corresponding to key "keyToIncrement": (ix "keyToIncrement")._numSeen :: Lens' (Map String MyStructure) Int (Well, strictly speaking, this is actually a traversal or a prism or something, because "keyToIncrement" might not exist, but let’s ignore that for this really simple example…) And now that you have it, you can use this new lens to do anything you want with this value: you can get it, set it, increment it, decrement it, print it, etc. Additionally, you don’t have to restrict yourself to just lenses. For example, ‘traversals’ are a generalisation of lenses which allow you to access 0, 1 or more elements, rather than restricting access to just one element at a time. For instance, you can use ‘both’ to transform, well, both elements of a tuple: > (1,2) & both 5~ negate (-1,-2) Or you can use ‘traversed’ to access each element of, say, a list: > [1,2,3,4,5] & traversed .~ 0 [0,0,0,0,0] Of course, there are other ways of doing each of these. If you happen to be working with mutable values, you can sometimes use dot notation to access deeply nested fields. Some usecases of ‘traversed’ can be replaced by a map. However, there really is no comparable substitute for lenses when working with deeply nested immutable structures, especially ones of unknown shape.
- alehander42 6y ago
  thanks! i think i now understood the idea
- gugagore 6y ago
  > you can define _1 and _2 as lenses for accessing the first and second element respectively of a tuple: _1 :: Lens' (a,b) a _2 :: Lens' (a,b) b From the looks of it, this is to access the first and second element specifically of a 2-tuple. I suppose if you had to generalize it, you would actually get a traversal or a prism or something, because those elements might not exist.
  - bradrn 6y ago
    > From the looks of it, this is to access the first and second element specifically of a 2-tuple. Yes, this is correct. (I don’t know about other languages, but it’s worth noting that in Haskell, tuples are of fixed size — 2-tuples, 3-tuples etc. are considered completely different types. A result of this is that ‘tuple of any length’ is not a valid concept in Haskell; you have to write a separate definition for each tuple size.) > I suppose if you had to generalize it, you would actually get a traversal or a prism or something, because those elements might not exist. Well, it depends how you generalise it. Haskell lens libraries, for instance, use a more general type which allows _1 and _2 to work with 2-tuples and larger, _3 to work with 3-tuples and larger, _4 to work with 4-tuples and larger, and so on. Thus these remain lenses, as they always access exactly one value. Another generalisation is to define a lens allowing access of an arbitrary element of a list. This may not return a value, and thus is indeed a traversal.
- alehander42 6y ago
  however: why those instead of iterators or functions? how is a `lens` not a function in general (or a yielding iterator) which return some kind of views?
  - Twisol 6y ago
    In the face of mutation and dynamic typing, yes, an iterator providing mutable references to the focused piece of the subject would give you something basically like a traversal (a generalization of a lens over list-like things). However, consider the case of a struct with five fields, each of a different type -- you can't just for-each over those. And you don't quite have the black-box composability benefits of lenses, since you need a value to iterate over. A lens is a (1) functional (2) bi-directional (3) first-class and (4) composable generalization of (5) struct field names in most traditional languages. 1) "Functional" meaning we eschew mutation and implicit context. Mutation is a very powerful feature of a language, and much can be encoded using it. When we remove mutation as an option, many of the things we would have just used mutation for separate into distinct and rich solution spaces. 2) "Bi-directional" meaning we can use the same widget for both accessing a sub-part of a whole, and for replacing that sub-part within a whole. I personally call these operations "extract" and "replace", since "get" and "set" feel like they raise the specter of mutability. 3) "First-class" means that the lenses themselves are manipulable constructs within the language. In a language like C or Java, I can have "obj.a.b.c", but I cannot have ".a.b.c" itself on its own. Even if you consider method references (like "Obj::a" in Java), you've only obtained the ability to extract the "a" field from an Obj -- any particular method or function is only going to go in one direction. 4) "Composable" means that you can take two lenses and fit them together to get a new lens. Conceptually, I think this is understood -- we intuitively understand how to navigate an object graph when writing down an expression like "obj.a.b.c" -- but having a composable first-class abstraction lets us do the same thing programmatically. (It need not even be at "runtime" -- imagine a compile-time macro system that programmatically generates nested accesses from some base rules you define. I think you've got the rudiments of a dependency injection system here.) 5) "Struct field" means that for the given type, the field is always accessible. "List element" (or "tree leaf", ...) would give you traversals instead of lenses, and "tagged union variant" / "subclass" would give you prisms. As for potential applications of the approach, there's the approach dependency injection graphs outlined above. I've also used ideas from lenses/prisms in serialization/deserialization and web service middleware. (Middleware compose really well as functional optics!) With profunctor optics, you can even construct self-describing operations. For instance, imagine a JSON parser that can be directly interrogated to obtain the schema it accepts, or a middleware stack that can be interrogated to determine which headers it looks at, and which routes it accepts. Personally, this is the area I'm most excited about with functional optics.
emmanueloga_ 6y ago
optics/lenses solve this problem in a framework that is jargon-heavy and difficult to understand, and most implementations I've seen use languages with very strict type system. The XSLT+XPath approach is more dynamic, easier to grasp (imho) and can probably be learned in an afternoon. Tradeoffs, tradeoffs... I wouldn't want to write most programs in Haskell but you could write pretty much any program in, say, JavaScript ... :-)