bug or feature?

[Richard Carlsson]

Serge Aleynikov wrote:
> Could anyone explain why matches #5 and #6 below fail?  I didn't find in 
> documentation a limitation of not being able to specify a variable as 
> the first argument of the '++' transform.
> 
> Eshell V5.4.13  (abort with ^G)
> (a@REDACTED)5> Prefix ++ "100" = "200100".
> ** 1: illegal pattern **
> (a@REDACTED)6> Prefix ++ Suffix = "200100".
> ** 1: illegal pattern **

A pattern "fred" ++ Suffix is equivalent to [$f, $r, $e, $d | Suffix],
which is easy to match on. For a pattern Prefix ++ Suffix, when Prefix
is previously bound to some value (unknown at compile time), you could
imagine the compiler generating code to perform the match as a loop
(much like you'd match String = "foo" for a previously bound String)
but there are some complications: what does it mean if Prefix turns out
to be a non-list, or if it is not nil-terminated? Then, the pattern
itself is illegal (just like the *expression* Prefix ++ Suffix). Should
you get a "badarg" error instead of just a nonmatch? And if the pattern
occurs in the second clause of a case, but the first clause matches,
should you still get a badarg or not? The current limitation makes
sure that patterns are always legal regardless of the runtime values.

(I'm not saying that it would not be convenient to have that kind of
matching available, along with general regexps - it would, but it is
not obvious that it can be made to fit in with the semantics of clause
matching in Erlang, which has the advantage of predictability.)

	/Richard