A Pythonista's Impressions of Erlang

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]
> Sent: den 12 januari 2005 15:30
> To: erlang-questions@REDACTED
> Subject: RE: A Pythonista's Impressions of Erlang
> 
> 
> 
> >  To do it this way involves a quick hack to the
> > compiler
> > of a rather simple parse_transform to change the
> > semantics of
> > the compiler.
> > 
> >  Actually I see no reason why patterns like Var ++
> > StringLiteral should not
> > be compiled, especially since StringLiteral ++ Var
> > *is* allowed - and therefore
> > disallowing Var ++ StringLiteral violates the
> > principle of least astonishment.
> 
> Some objections:
> 
> X ++ "string" would compile into string searching
> (linear time), rather than pattern matching (constant
> time).
> 
> There might be multiple matches, what to do about
> those? (May I suggest backtracking? :-)

Or forwardtracking even

> What about nested patterns, e.g., 
>    "foo:" ++ X ++ "=" ++ Y? 
> Will your simple parse transform really be all that
> simple once we consider all the cases? (Perhaps the
> best solution is to write it and see.)
> 

Ooohhh 

> However, I'll agree that more generally it might be
> nice to have some sort of regexp patterns, especially
> when doing the string processing tasks that tend to
> pop up. (Parsing text based protocols, say?)
> 
> Also, regexps/string operations on binaries might be
> more familar to people used to "strings as arrays".
> 

Indeed yes, so if <<~R~>> means match the RegExp R 
we could write things like ...

  foo(<<~"[.?!][]\"')}]*\\($\\| $\\|\t\\|  \\)[ \t\n]*"~>>) ->
	...

BTW my last posting had some non-smiley-tagged-jokes as does this
(possibly)


> Best,
> Thomas
> 

  Thomas ! hello

  /Joe