PR# 15072 Unary operator (e.g. #) requires space (e.g. # s) instead of allowing #s

Problem Report Summary
Submitter: jsostroff
Category: C Compilation
Priority: Medium
Date: 2008/11/26
Class: Bug
Severity: Serious
Number: 15072
Release: 6.3 latest
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB5; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 3.5.21022)
Synopsis: Unary operator (e.g. #) requires space (e.g. # s) instead of allowing #s

Description
It seems that unary operator (e.g. #) require space (e.g. "# s") instead of allowing "#s" (which is reported as a syntax error by the compiler). 

Discussion from eiffel_software@yahoogroups.com below:

-----Original Message-----
From: eiffel_software@yahoogroups.com [mailto:eiffel_software@yahoogroups.com] On Behalf Of Helmut Brandl
Sent: Tuesday, November 25, 2008 10:09 PM
To: eiffel_software@yahoogroups.com
Subject: Re: [eiffel_software] Inavlid operator expressions?

Hello Jonathan,

the behaviour you described is a bug.

In early versions of Eiffel, letters were allowed within free operators. 
Previously you could define "#blabla#" to be a free operator. In order 
to scan/parse it correctly, blank have been required after free operators.

In ECMA Eiffel, letters and digits (i.e. anything which can create 
ambiguities with names) are forbidden within free operators. Free 
operator consist solely of operator symbols. So your declaration is ok, 
the compiler requiring a space is wrong.

Regards
Helmut

The Eiffel Compiler: http://tecomp.sourceforge.net
http://www.sourceforge.net/projects/tecomp

Jonathan S. Ostroff wrote:
> Suppose we define a unary alias
>
>  	count alias "#": INTEGER do Result := representation.count end
>
> in class SET[G], say.
>
> Then we should be able to write
>
> 	s: SET[G]
>
> 	#s
>
> for s.count. However the parser rejects this with a syntax error and
> requires
>
> # s
>
> (with a space).
>
> Likewise
>
> 2 = -s
>
> Is rejected with a VWOE invalid operator. 
>
> Am I missing something or is this a bug?
>
> Thanks
>
> JSO
>
>   
To Reproduce
See above
Problem Report Interactions