Choking on Syntactic Sugar

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Choking on Syntactic Sugar

Hakan Stenholm
>From the documentation on Erlang Extensions since 4.4:
>
>  7.8 Literal string prefix in patterns
>  
>       This extension was added in Erlang 4.8 (OTP R5A).
>  
>       A new construction is allowed in patterns, namely a literal
>       string as the first operand of the ++ operator. Example:
>
>             f("prefix" ++ L) -> ...
>
>       This is syntactic sugar for the equivalent, but harder to read
>
>             f([$p,$r,$e,$f,$i,$x | L]) -> ...
>
>
>No other non-constant uses of `++' are allowed.

This is not quite true, any non-negative integer (not just 0-255) appears to
work just fine and in this case it should be possible to check at compile time.
I wrote a littel test program (OTP r7b01) to show this:

-module(test).

-export([
         test/1
        ]).

%% call test:test(String) to see that pattern match is done properly
test("foo" ++ R) -> ok;
test([101,101] ++ R) -> ok;    % "ee"
test([400,400] ++ R) -> ok;

%% test([a,b,c] ++ R) -> ok;     -> compile error
%% test([{1,2,3}] ++ R) -> ok;   -> compile error
%% test([_,_] ++ R) -> ok;       -> compile error
%% test([4.0,4.0] ++ R) -> ok;   -> compile error
%% test([-1,-1] ++ R) -> ok;     -> compile error

test([999999999999999999999999999999999] ++ R) -> ok;
test(_) -> not_ok.



Wouldn't it also be reasonable to generalize this by alowing the string argument
to be any kind of list of patterns (that might contain varibles and _) that is
known at compile time ?
Then again we don't gain anything from this (from what I can see) so there is no
apprent reason to do this ?!



Reply | Threaded
Open this post in threaded view
|

Choking on Syntactic Sugar

Richard Carlsson-4

On Wed, 14 Mar 2001, Hakan Stenholm wrote:

> >       A new construction is allowed in patterns, namely a literal
> >       string as the first operand of the ++ operator. Example:
> >
> >             f("prefix" ++ L) -> ...
> >
> >       This is syntactic sugar for the equivalent, but harder to read
> >
> >             f([$p,$r,$e,$f,$i,$x | L]) -> ...
> >
> >No other non-constant uses of `++' are allowed.
>
> This is not quite true, any non-negative integer (not just 0-255)
> appears to work just fine and in this case it should be possible to
> check at compile time.
> [...]
> Wouldn't it also be reasonable to generalize this by alowing the
> string argument to be any kind of list of patterns (that might
> contain varibles and _) that is known at compile time ? Then again
> we don't gain anything from this (from what I can see) so there is
> no apprent reason to do this ?!

It would certainly be possible. My guess is that `[Int1, Int2,...] ++
Tail' is currently accepted as a special case only because it would be
odd if `"abc" ++ Tail' was legal, but `[$a, $b, $c] ++ Tail' was not.

Generalising this is simple, and might even be useful in some cases. You
could write stuff like:

        foo(?xx_prefix(X, Y, Z) ++ Tail, ...) -> {X, Y, Z, Tail}.

which is clearer than including the tail in the macro call:

        foo(?xx_pattern(X, Y, Z, Tail), ...) -> {X, Y, Z, Tail}.

    /Richard



Richard Carlsson (richardc)   (This space intentionally left blank.)
E-mail: Richard.Carlsson WWW: http://www.csd.uu.se/~richardc/