Abstract patterns

[Sean Hinde]

On 13 Mar 2006, at 14:08, Bjorn Gustavsson wrote:

> If you tell me where I can find the latest version of the paper,
> I'll have another look at it.
>
> What I meant by the phrase "implement efficiently" is that performance
> should be comparable to that of records. If that indeed would be  
> possible
> to achive without inlining, we would be more interested in  
> implementing
> abstract patterns.

I thought the idea was as much about providing a nice interface into  
all kind of abstract data types, not just as a record replacement. It  
opens the door to things like a queue data structure that allows test  
for empty queue in a function header without having to break the data  
abstraction.

One reservation is around the syntax for adding and extracting  
multiple entries to/from an abstract pattern. It is a bit cumbersome  
(as noted in the version of the paper posted on the mailing list some  
time back):

<quote>
     L2 = L#log{blocked_by = none, status = ok}

which is arguably prettier than

     L2 = L#log_blocked_by(none)#log_status(ok)
</quote>

<quote>
     #log{status == S, users = N} = L

which is arguably prettier than

    #log_status(S) = #log_users(N) = L
</quote>

In any case I am very much in favour of this initiative.

Sean


>
> /Bjorn
>
> "Richard A. O'Keefe" <ok@REDACTED> writes:
>
>> Bjorn Gustavsson <bjorn@REDACTED> wrote:
>> 	Abstract patterns is tricky to implement efficiently as it would
>> 	require inlining across module boundaries.
>>
>> Sorry, but as the inventor of abstract patterns, I can tell you
>> that this is QUITE UNTRUE.  Abstract patterns were designed so that
>> they can be implemented *either* by inline code *or* by out-of-line
>> code.  At least one version of the paper explained how to do this.
>>
>> What's more, records *also* require inlining across module  
>> boundaries,
>> it's just that the modules involved as called ".hrl files" and the
>> inlining is done by the preprocessor.
>>
>> 	Inlining across modules boundaries with retained semantics for
>> 	code change is possible to implement, but tricky.
>>
>> I repeat, you are ALREADY doing this for records and macros; the only
>> difference is that with records and macros you didn't even TRY to get
>> the semantics for code change right.
>>
>> Several years ago I proposed splitting -import into -import and
>> -import_early, where importing a module early would create a recorded
>> dependency between the two modules so that if the imported module  
>> were
>> reloaded the corresponding version of the importing module would need
>> reloading too.  This would permit inlining of stuff declared in
>> -import_early modules.  Wouldn't this be a problem in practice?  No,
>> it would be a step forward because this one-way dependency ALREADY
>> exists between .hrl files and the .erl files that include them.  So
>> telling the system what the xxxx is going on would create no worse
>> dependency problem that already exists and would actually make life
>> easier by enabling the system to tell you when you tried to make an
>> inconsistent reload.
>>
>> Not that this matters, because ABSTRACT PATTERNS DO NOT NEED  
>> INLINING.
>> They were consciously and explicitly designed *not* to have the same
>> problems as records.
>>
>> 	Currently, we have no plans to implement abstract patterns.
>>
>> I would be happy to discuss this particular or any other apparent
>> obstacle to implementing them.
>>
>
> -- 
> Björn Gustavsson, Erlang/OTP, Ericsson AB