[erlang-questions] If you are homesick for object.selector

[Fred Hebert]

On 01/27, Loïc Hoguin wrote:
> On 01/27/2013 06:31 AM, Fred Hebert wrote:
> > In the mean time, enjoy an implementation of it:
> >
> > https://github.com/ferd/hubble
> 
> You're not fixing the issue, it still has no language support. In
> short it means:
> 
>  *  Can't pattern match
>  *  Can't use values with function clause guards
>  *  Can't modify values at different depths in one go
> 
> Seems it's also quite verbose and you have to repeat paths all the
> time, similar to how you have to repeat the record name all the
> time.

You indeed:

* Can't pattern match
* Can't use value with function clause guards

If these are 100% necessary and vital, there isn't much to do, although
there could be some forms of pattern matching (see below).

You can modify values at different depths in one go. It would also be
easy to support nested operations where you pretty much draw the tree,
nearly trivial too, so that:

ups(H, [stats, strength, 1],
       [stats, wisdom, 2],
       [bio, age, 329])

Becomes:

ups(H, [stats, [strength, 1]
               [wisdom, 2]],
       [bio, age, 329])

This means you can no longer use lists (or strings) as keys, though,
because you couldn't know whether they're nested levels or keys;
another syntax could be found possibly. I don't know when that would
become too cumbersome or not cumbersome enough for your own tastes.

It would maybe be possible to do the deconstruction on the left-hand
side of the match operator. Find the desired fields, shove them in a
tuple, and match on the final values or whatever.

A transformation that targets making a call similar to:

{X,5,Z} = {hubble:get(Hubble,[stats,strength]),
           hubble:get(Hubble,[stats,wisdom]),
           hubble:get(Hubble,[bio,parent,father])}

would possibly allow a declaration like (I think they'll be allowed this
far down the compilation, but I haven't checked):

match([stats, [strength, X]
              [wisdom, 5]],
      [bio, parent, father, Z]) = Hubble

That's a far cry from native language support with function heads and
guards. I don't know if you'd still consider this far too cumbersome, if
it's somehow still worse than your aversion to the current record
format:

#character{stats=#stats{strength=X,
                        wisdom=5},
           bio=#bio{parent=#parent{father=Z}}} = Hubble

If there's a common translation accepted of match(Hubble) -> Tuple,
or match(Hubble) -> List, then you could allow the transformation of the
match/1 function as a general rule and be able to pass it to cases and
guards. I'm not sure how reliable that thing would be, and it could not
work with function heads.

It's stuff that can be explored right away, though, without needing
language support, if the need for such a structure or the hate of
records make this really pressing. If it's not that urgent, then oh
well.

> 
> >And it lets you use any damn term you please for the path, not just yet
> >another overloaded bunch of strings with encodings to worry about.
> 
> No idea what this means.
> 

When XPath was mentioned, I assumed it would be something string-based
like the real XPath libraries use:

"people//author[first-name][3]"

This means whatever your key is, it needs to be a string or an atom,
hope that they use the same encoding, escape values that could have been
used, etc.

I feel it's generally more interesting to be able to have mixed-type
keys for some operations on dict-like data structures. Say I have a
gen_event with registered handlers {make_ref(), Name}. Using these for
keys becomes impossible with a string matching syntax.

Maybe most people wouldn't care about that, though, and xPathing could
be interesting. I'm not sure how you could use that to pattern match
while binding values though.


Regards,
Fred.