user-defined operators

[Eric Newhuis]

I agree with Martin.

And what I WOULD like from Erlang are more standard operators that make 
it easier to capture common Erlang coding idioms.

For example, Erlang's "foreach" idiom is too verbose.  One spends more 
time looking at code structure rather than intentions.

Consider the following Erlang code:

	lists:foreach (F, SomeList).

When I see that my eyes are drawn to the lists:foreach part of the 
expression rather than the things that matter (F and SomeList).

Operators that looked like this would be easier to read and would allow 
nesting without confusion:

	F each SomeList

Studying the APL language would be a good place to start to ponder 
these special operators.  The K language is another good place to 
start.  Those languages are superior to Erlang in terms of operators 
and expressive power.

As an example here is something that calls a binary function over two 
vectors in K:

{x+y}'[XList; YList]

The quote operator ' is equivalent to the lists:foreach and the 
brackets expand the valence of the function from a function of one 
variable x to a function of two variables x and y.  To read that code 
one pronounces "each" when one sees the quote operator.  So reading the 
above one would say "x plus y for each XList YList".

Don't hate me.  I love Erlang.  But I love K's operators more.  Erlang 
+ K operators would be pure bliss.

Erlang needs more powerful operators.  I don't think it needs operator 
overloading.  HOWEVER if there were a way to put Erlang into an 
operator defining mode for experimenting such that a community of 
experts could play with various potential STANDARD operators prior to 
introducing them to the larger community then THAT would be a great 
excuse to have Erlang operator overloading.

I'd like to see unary, binary, tertiary, and even n-ary operators.  I 
don't think one should assume that all operators act on just one or two 
variables.  Operators could be overloaded for monadic, dyadic, etc.  
They should act on scalars as well as vectors and each form should have 
a corresponding distinct implementation.

Example:  What is the meaning of X 'operator' Y if X and Y are scalars? 
  What if X and Y are vectors?  What if one is a Matrix and the other is 
another Matrix of different dimension?  Are operators overloaded based 
on type?  I'd hope any new standard operators would be so overloaded 
but retain a common theme throughout the overloading.




On Mar 25, 2004, at 10:38 AM, Martin J. Logan wrote:

> I think that the overloading of operators is a nifty idea and I can
> think of a few places where it would make my life easier. I must state
> in the face of my previous statement that my take on operator
> overloading and defining ones own operators is that it should not be
> done. Operators should be defined by a central body responsible for the
> language syntax and semantics. In this way a modicum of consistency in
> the language is ensured. With functions, because they are typically
> spelled out with letters, at least one is nudged in the direction of
> intentionality. With operators they can be anything $_ $# @# @_. I 
> hated
> reading c++ code where some operator was overloaded to do something
> completely unintuitive. This is inevitable when you give control of
> these things to anyone.
>
>
> Example:
> wasting_your_time_trying_to_read_this() -.
>    %% Here I append strings with the "string <- enters other
>    %% string" operator. At the end I use the "'}{' Convert integer to
>    %% string and  append" operator to append an integer to the string.
>    BigString = "I " <- "write " <- "crappy " <- "code + " '}{' Integer
> <- "   ",
>
>    %% Here I want to to take my string and use the case operator '.]'
>    %% which takes a string and an atom either 'upcase' or 'downcase' to
>    %% alter the case of chars in a string. I then operate on it with 
> the
>    %% 's+' string operator with the argument 'chop' which will remove
>    %% any trailing space.
>    Cased = (BigString '.]' upcase)'s+'chop.
>
> I am sure that I will be subjected to erlang code of this type if 
> people
> are allowed to create their own operators. An objection that could be
> raised is well the Haskell code I have seen does not suffer from that.
> The answer to that question is that as soon as the user base grows it
> will.
>
> Cheers,
> Martin
>
>
>
>
> On Sun, 2004-03-21 at 11:06, Thomas Lindgren wrote:
>> Some time ago there was interest in extending Erlang
>> with your own operators, e.g., !!. So why not provide
>> them?
>>
>> Here is a code sketch for extending Erlang to permit
>> simple user-defined infix operators `op`. The idea is
>> basically taken from Haskell and seems fairly clean. I
>> used backquotes around the operator because Haskell
>> did so.
>>
>> I modified the erlang parser and scanner to support
>> this notation; it seems to work, though I haven't used
>> it very extensively.
>>
>> f(X, Y) -> X `foo` Y.   %% note: foo is "backquoted"
>>
>> is parsed as if:
>>
>> f(X,Y) -> 'foo'(X,Y).   %% call function foo/2
>>
>> The operator `op` has the same precedence as
>> andalso/orelse. You can also write `mod:func` to
>> invoke mod:func(X,Y), e.g.,
>>
>>    Port `erlang:port_command` Data
>>
>> Both the module and the function have to be non-empty
>> atoms. Thus, the following are considered errors,
>> where foo is any atom:
>> `:foo`
>> `foo:`
>> `:`
>> ``
>>
>> I haven't tested how the scanner behaves with extreme
>> quoting in the infix operator. The error return value
>> in the scanner does not have a format_error. Finally,
>> the code could probably be improved by someone more
>> familiar with erl_scan/erl_parse.
>>
>> Example use:
>> ==========
>> 1> {ok, Ts, _} = erl_scan2:string("f(X,Y) -> X `op`
>> Y.").
>> ...
>> 2> erl2:parse_form(Ts).
>> ...
>>
>> Best,
>> Thomas
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Finance Tax Center - File online. File on time.
>> http://taxes.yahoo.com/filing.html
>> This communication is confidential and intended solely for the 
>> addressee(s). Any unauthorized review, use, disclosure or 
>> distribution is prohibited. If you believe this message has been sent 
>> to you in error, please notify the sender by replying to this 
>> transmission and delete the message without disclosing it. Thank you.
>>
>> E-mail including attachments is susceptible to data corruption, 
>> interruption, unauthorized amendment, tampering and viruses, and we 
>> only send and receive e-mails on the basis that we are not liable for 
>> any such corruption, interception, amendment, tampering or viruses or 
>> any consequences thereof.
>>
>