bug or feature?

[Richard A. O'Keefe]

I wrote that the way to handle "extensive" prefix matching at run time
was to CONSTRUCT A FUNCTION AT RUN TIME, and in my previous message
showed (using source code syntax) what that function would look like.

Serge Aleynikov <serge@REDACTED> replied:
	Well, this all seems clear indeed if you know the exact values of 
	Prefixes at compile-time, ...
	Perhaps I am missing your point, but if you have to obtain the prefix 
	list from an external source at run-time, such as:
	then the only way to use your recommendation would be to construct a 
	string, ...
	and then use erl_parse module to parse this string into a fun callable 
	at run-time.  Correct?
	
There are other alternatives, such as writing it out to a file and then
compiling and loading as usual, but yes.

	It seems though that the "fun(Prefix++Suffix, Prefix)" notation
	would be a little bit less obscure, though, admittedly less efficient.
	
If you only have one clause with
    f(Prefix, Prefix++Suffix) -> Suffix;	 % currently illegal
    f(_,              String) -> String.
and you have LOTS of prefixes, then you have to call that function LOTS
of times.  So we are not talking about a _little_ bit "less efficient",
but "STUNNINGLY INEFFICIENT".  It is so inefficient compared with the
code generation version that
(a) the difference between the version using the novel form of ++
    and the current pure Erlang version I gave is invisible to the
    naked eye, by comparison, and
(b) *interpreting* a trie is likely to be faster than running the
    compiled Prefix++Suffix code.
If I had to match oodles of prefixes and for some reason was shy of
generating code at run time, I would use a ternary search tree.  A simple
data structure which is just about perfect for this job.

The technique of generating code at run time is a GENERAL technique with
many uses.  So far, we have only one known use for Prefix++Suffix with
Prefix known at run time but not compile time.  It seems to me that it
is this highly specialised use of ++ which is obscure.  I mean, with the
run-time code generation version, you really cannot help noticing what
is happening.

I note that there are tools around to let you generate code at run time
in C and Java...