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

[Joe Armstrong]

Manipulating nested records is a pain - how about this?

Assume we have three records

-record(top, {a::#one{},     b::#two{},  c::#three{}  }).
-record(one, {x::#foo{},  y::#bar{} })
-record(foo, {p,q,r}).
and I want to unpack the p field from a variable X containing a top
record.

I don't want to write

  #top{a=#one{x=#foo{p=P}}} = X

this is messy and error prone

This should do the job

    P = extract_from(X, top,p)

A compile transform could figure out the code to make. In this case the
tag p has a unique path from the top root. In the case where the required
tag is not unique, we'll need to "hint" the path.

We just give the parse transform enough hints to figure out
the path at compile time. We should get a error if the path does not
uniquely
specify the element.

Cheers

/Joe




On Fri, Jan 25, 2013 at 2:07 PM, Darach Ennis <darach@REDACTED> wrote:

> Hi guys,
>
> There is a problem here. Any reasonably sized or structured erlang
> application
> requires records, despite the grody record syntax. The alternative? Big
> hairy unstructured
> clods of tuple and lists and things? Worse. Unmaintainable in and of
> itself. Hard to pattern
> match. Had to manipulate. Hard for humans to grok whilst reading without
> squinting your
> brain hard and quizzically at the terminal ...
>
> Unlike the matrix, it's not blonde, brunette or a redhead ... It's
> something else! ;(
>
> So they're needed? Yes. Use by choice? No. And that's the problem.
>
> I secretly hope for for something better to come along. A big gnarly
> unstructured
> and frequently accessed tuple would be fine, for example, if there was
> some kind
> of tuple path expression language... like XML has XPath? Jackpot.
>
> So maybe frames aren't needed at all. Maybe frames would be nice. Perhaps
> we
> just want to reach out and touch the a subset of tuples of lists of tuples
> of lists of
> tuples of ... I'm pretty sure with or without frames that solves 80% of
> the need for me.
>
> The other 20%? -  Native support for Kaysian transforms and other natural
> conveniences
> for efficient slicing, dicing, filtering and merging.
>
> I'm not sure record or any other syntax is actually the problem.
>
> Also, the nice thing about adding something like an XPath like thing for
> tuples?
> It doesn't break existing applications. It's backward compatible. It's
> forward
> migratable. No new syntax because an expression can be a plain old list of
> binary (string).
>
> So, we maybe xmerl_xpath already has 99% of what's needed...
>
> Cheers,
>
> Darach.
>
>
>
> On Fri, Jan 25, 2013 at 12:25 PM, Loïc Hoguin <essen@REDACTED> wrote:
>
>> On 01/25/2013 12:10 PM, Loïc Hoguin wrote:
>>
>>> Let me tell you something about yourself.
>>>
>>
>> I have been told this bit can be considered offensive in English, it
>> isn't meant to be.
>>
>>
>> --
>> Loïc Hoguin
>> Erlang Cowboy
>> Nine Nines
>> http://ninenines.eu
>> ______________________________**_________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130125/b8a6c57f/attachment.htm>