Marco Manfredini wrote:

> Steven T. Hatton wrote:
>=20
>> Is it fundamentally possible to support an operator that tells the
>> compiler the subsequent symbol is to be treated as an infix operator?
>=20
> Theoretically yes. Many functional/CAE Languages have it to support the
> terse syntax computer scientists and mathematicans seem to love. But I
> don't think that the C++ community sees neccesity to set the programmer
> into the position to make the code unreadable with user defined infix
> operators of uncertain precedence, associativity and appearance. The
> current syntax is worse enough.
>=20
> There is a kludge in C++:
>=20
> 0) Make a disclaimer note:
> /*
>  Disclaimer: This is a stupid hack and shouldn't be considered at all.
>  <put fake author/email here, so that nobody can blame you>
> */
>=20
[impressive...]

I will point out that `c=3D a *dotProduct* b;' translated to `a
[bold]dotProduct[/bold] b' in in my usenet client, KNode.  IOW, it looked
very much like `a dotProduct b', as I would ideally want an infix operato=
r
to look.

Your hack is certainly inventive.  It does seem to lack the precedence
features I would want with infix operators.  I might even be inclined to
investigate this further using diadic matrices.  The place where I would =
be
inclined to use this type of notation is in 3D programming. Within a
specialized context where the symbols behave according to the established
rules of the field, I believe it may not be that big of a problem to have
user defined operators, with user defined precedences.=20

I don't really understand the concept of compositors as mentioned in =A72=
2.4.7
of TC++PL(SE), but I have a slight inclination to believe it may be
possible to build them dynamically using this kind of approach.

hacker n. 1) *original or MIT definition*: A person who loves computers a=
nd
writes code for enjoyment more than financial gain - especially code with
Lots of Indented Silly Parentheses, and often specifically (X)Emacs code.=
=20
2) A person, often unschooled, who writes less than ideal - though often
inventive - code. 3)  *media definition*: A person who breaks into
computers either for sport, or with malicious intent. 4) A person who
drives a taxi cab.
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-08-09 17:09, Marco Manfredini wrote:
> Steven T. Hatton wrote:
>
>> Is it fundamentally possible to support an operator that tells the
>> compiler the subsequent symbol is to be treated as an infix operator?
:
> There is a kludge in C++:
:
> Vector a,b;
> // This means: (a*dotProduct)*b;
> c= a *dotProduct* b;

Some time ago I suggested using the syntax

   c = a <op> b;     // really (a < op) > b

(i.e. using operator < and operator >) which has a somewhat more
idiomatic feel to it.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nospam@phoyd.net (Marco Manfredini) wrote:
> 4) use it:

  4a) give it the desired appearance:
  #define X *dotProduct*

  4b) acutally use it:
  Vector a, b;
  c = a X b;

(well, this is not necessarily the correct notation for "dotProduct").
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> Is it fundamentally possible to support an operator that tells the compiler
> the subsequent symbol is to be treated as an infix operator?

Take a look at the FC++ library:

    http://www.cc.gatech.edu/~yannis/fc++/

and, in particular:

    http://www.cc.gatech.edu/~yannis/fc++/New1.5/infix.html

fres

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Kuehl wrote:

> nospam@phoyd.net (Marco Manfredini) wrote:
>> 4) use it:
>
>   4a) give it the desired appearance:
>   #define X *dotProduct*
>
>   4b) acutally use it:
>   Vector a, b;
>   c = a X b;
>
> (well, this is not necessarily the correct notation for "dotProduct").

The preprocessor is evil. I will probably be living with it for a long time
due to its extensive use by Trolltech, but that doesn't mean I have to
inherit the sinfulness along with the sins.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Is it fundamentally possible to support an operator that tells the compiler
the subsequent symbol is to be treated as an infix operator? For example:

Vector3f v1, v2; // 3-component vectors of float

Cross X; // binary_function taking Vector3f arguments, returning Vector3f

I would like to write:

Vector3f v3 = v1 @X v2;

with the obvious result.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> schrieb im Newsbeitrag news:KOWdnUD9jtmDJIncRVn-vw@speakeasy.net...
> Is it fundamentally possible to support an operator that tells the compiler
> the subsequent symbol is to be treated as an infix operator?

Fundamentally yes, in C++ no.

Other languages did try that approach, but they were too far ahead of their time. Have a look at Algol 68, Simula or other languages of that time and you may find many features that have found their way into languages like C++ (function overloading, the heap, operators, just to name a few) and many missing in wide spread languages. But also take a look at the complexity of their grammer and their compilers,

> For example:
>
> Vector3f v1, v2; // 3-component vectors of float
>
> Cross X; // binary_function taking Vector3f arguments, returning Vector3f

What about 'Vector3f operator X(Vector3f const&, Vector3f const&)'

> I would like to write:
>
> Vector3f v3 = v1 @X v2;

If I had a choice, I would prefer 'v1 X v2'.

> with the obvious result.

The what? What's the priority of the new operator? What's its associativity(sp?)? Just look at Algol 68's grammer. C++ is simple compared to that, and they didn't even have classes...

Regards
    Heinz


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Heinz Ozwirk wrote:

> ""Steven T. Hatton"" <hattons@globalsymmetry.com> schrieb im Newsbeitrag
> news:KOWdnUD9jtmDJIncRVn-vw@speakeasy.net...
>> Is it fundamentally possible to support an operator that tells the
>> compiler the subsequent symbol is to be treated as an infix operator?
>
> Fundamentally yes, in C++ no.
>
> Other languages did try that approach, but they were too far ahead of
> their time. Have a look at Algol 68, Simula or other languages of that
> time and you may find many features that have found their way into
> languages like C++ (function overloading, the heap, operators, just to
> name a few) and many missing in wide spread languages. But also take a
> look at the complexity of their grammer and their compilers,

Mathematica, I am almost certain, supports the definition of new infix
operators.  I've never seen a grammar for Mathematica.  It may actually be
fairly simple. I don't know.  It's a bit hard to identify what elements of
the language are fundamental. I suspect Wolfram knows.

>> For example:
>>
>> Vector3f v1, v2; // 3-component vectors of float
>>
>> Cross X; // binary_function taking Vector3f arguments, returning Vector3f
>
> What about 'Vector3f operator X(Vector3f const&, Vector3f const&)'
>
>> I would like to write:
>>
>> Vector3f v3 = v1 @X v2;
>
> If I had a choice, I would prefer 'v1 X v2'.

Well, yes, that would be my first choice.  The proposed infixer operator was
intended as a means of demonstrating the feasibility of the idea.  If we
assume a fixed order of precedence for all user defined operators, the
mechanism becomes a simple alias for the prefix(_,_,_) form of the
operator.  It could be converted to the prefix form rather easily before
further processing.

The compiler would have to be smarter if it is required to determine if a
token is an operator by examining the context of the statement in which it
appears.

>> with the obvious result.
>
> The what? What's the priority of the new operator? What's its
> associativity(sp?)? Just look at Algol 68's grammer. C++ is simple
> compared to that, and they didn't even have classes...

I've written a simple parser for a toy language that handled associativity.
You simply assign a priority to the token and parse accordingly.  Once you
get the basic algorithm down, the rest is a piece-o-cake.

I'd say the idea should be considered first with the assumption that there
will be an infixer operator.  If other's who have more knowledge of
compiler design are convinced the proposal can be reasonably implemented,
then it might be worth considering the use of the 'Vector3f operator
X(Vector3f const&, Vector3f const&)' form you suggested.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> Is it fundamentally possible to support an operator that tells the
> compiler the subsequent symbol is to be treated as an infix operator?

Theoretically yes. Many functional/CAE Languages have it to support the
terse syntax computer scientists and mathematicans seem to love. But I
don't think that the C++ community sees neccesity to set the programmer
into the position to make the code unreadable with user defined infix
operators of uncertain precedence, associativity and appearance. The
current syntax is worse enough.

There is a kludge in C++:

0) Make a disclaimer note:
/*
 Disclaimer: This is a stupid hack and shouldn't be considered at all.
 <put fake author/email here, so that nobody can blame you>
*/
1) define a class as "tag"
struct DotProductTag
{
};

and another one to hold an argument
struct DotProductLeftPart
{
        const Vector &v;
        DotProductLeftPart(const Vector &_v) : v(_v) {}
};

2) Have a constant of the tag class
const DotProductTag dotProduct=DotProductTag();

3) define operators
// collect the left argument.
DotProductLeftPart operator * (const Vector &v, const DotProductTag &)
{
        return DotProductLeftPart(v);
};
// take a left part and a right argument, compute dot_product
double operator * (const DotProductLeftPart& p, const Vector &v)
{
        return dot_product(p.v,v); // the "real" dot product
}

4) use it:

Vector a,b;
// This means: (a*dotProduct)*b;
c= a *dotProduct* b;

With some luck, the compiler can inline everything into a raw
dot_product(..) call. If you're determined, you can write a
preprocessor that replaces the entities from the unicode math or
linear-b page with an associated "meaning" (i.e. \dot=>*dotProduct*) to
study the effects this has on the intelligibility of your code.

Regards
Rowan E. Snackenplunder



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat,  7 Aug 2004 21:07:52 GMT, hattons@globalsymmetry.com ("Steven
T. Hatton") wrote:

>Is it fundamentally possible to support an operator that tells the compiler
>the subsequent symbol is to be treated as an infix operator? For example:
>
>Vector3f v1, v2; // 3-component vectors of float
>
>Cross X; // binary_function taking Vector3f arguments, returning Vector3f
>
>I would like to write:
>
>Vector3f v3 = v1 @X v2;
>
>with the obvious result.
>

Why not just overload one of the built-in operators? If operator*()
isn't an option, something like operator^() probably is.


--
Bob Hairgrove
NoSpamPlease@Home.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]