bug or feature?
Richard A. O'Keefe
Mon Apr 24 07:13:19 CEST 2006
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
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
I note that there are tools around to let you generate code at run time
in C and Java...
More information about the erlang-questions