Erlang/OTP R10B-10 has been released

Richard A. O'Keefe <>
Sun Mar 12 22:46:03 CET 2006


Bjorn Gustavsson <> 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.



More information about the erlang-questions mailing list