A plea for help from Erlang gurus

Ulf Wiger ulf.wiger@REDACTED
Thu Dec 18 14:19:06 CET 2003

Given your proposed syntax, you will have to change the
grammar. There are several good reasons to avoid this.


1> erl_scan:string("A@REDACTED = foo. ").

This can be interpreted in two ways:

- your syntax is (almost) legal erlang code, which is a good
   thing, because you don't really have to hack erl_scan.

- it's (almost) legal erlang code, which is a bad thing, because
   your patterns may conflict with existing code. (:

(BTW, the syntax highlighter in Emacs doesn't expect @ in variable
names, and stops highlighting the variable name before the @.)

The (almost) legal part is because you introduce new variable names
in the guards, which is disallowed by the existing grammar. Thus,
your code, as written, doesn't compile.

I would propose the following (assuming you still want to go through
with your idea ;):

Change the syntax slightly so that it becomes really legal erlang:

important_event(Arg@REDACTED="linkDown") when Arg@REDACTED > 0 and
                                                 Arg@REDACTED < 8 ->

could instead become:

important_event([event_type="linkDown", time=T] = Arg@@) when T > 0 and
                                                               T < 8 ->
    [{importance, 'not so important event'}|Arg];
    %% I decided to peel off the @@ from the variable name.
    %% This might be a really bad idea. Feel free to rant about it.

and then, using a parse_transform, changed into:

important_event(Arg) ->
    case proplists:lookup(event_type, Arg) of
       {_, "linkDown"} ->
          case proplists:lookup(time, Arg) of
             {_, T} when T > 0 and T < 8 ->
                [{importance, 'not so important event'}|Arg];
             _ ->
       none ->
          ... % exit(function_clause) or continue with other
              % clauses.

I would not allow a "destructive update" construct like
    Arg@REDACTED = 'not so important event',

As I couldn't think of an update construct that would be
legal code and still intuitive, I propose simply leaking the
representation of the proplist and prepending the new property
to original list. The thing to make convenient was the decomposition,
right? Updating property lists is already really easy.


On Thu, 18 Dec 2003 13:35:55 +0200 (EET), Taavi Talvik <taavi@REDACTED> 

> I have system, which tries to classify events based on
> their properties. And I am trying to simplify writing
> some special code for acting on property lists.
> I would like to write modules/rules in fashion of:
> Arg = [{key,value}, {key, value}, ...]
> %
> % Add {importance,'not so important'} when event is at night
> %
> important_event(Arg@REDACTED="linkDown") when Arg@REDACTED > 0 and
> 					        Arg@REDACTED < 8 ->
> 	Arg@REDACTED = 'not so important event',
> 	Arg;
> %
> % Add {importance,'very important'} to property list
> % when there is {event_type, "linkDown"} in passed in property list
> %
> important_event(Arg@REDACTED="linkDown") ->
> 	Arg@REDACTED = 'very important event',
> 	Arg.
> This is basicly to extend pattern matching and guard tests
> to property list(assocative arrays) and add easy way to access
> those properties.
> What is best way to proceed:
> 	extend erl_scan and erl_parse
> 	generate extended parse tree
> 	analyze parse tree with help of syntax_tools
> 	find "array accesses"
> 	replace them with access functions or case statements
> 	in pattern matching and test guards
> 	output new code..
> Any pointers to papers, code examples doing something similiar,
> ideas how erlang 'guru' will handle above are very much appreciated.
> What is reasonable way to start with this?
> best regards,
> taavi
> PS. I have never done anything like this before except classical
> exercise to write simple calculator with lex and yacc.

Ulf Wiger, Senior System Architect

More information about the erlang-questions mailing list