Path: g2news2.google.com!postnews.google.com!32g2000yqj.googlegroups.com!not-for-mail
From: tm <thomas.mer...@gmx.at>
Newsgroups: comp.lang.misc
Subject: Re: Syntax for user-defined infix operators
Date: Fri, 28 Aug 2009 14:01:34 -0700 (PDT)
Organization: http://groups.google.com
Lines: 243
Message-ID: <fcfc0ea8-b87b-40ed-9a46-e4d963fad8ed@32g2000yqj.googlegroups.com>
References: <a20767c7-b537-4e6b-9caa-b8db7746e14a@o32g2000yqm.googlegroups.com> 
	<abc638dd-0e9f-4b85-955b-ccfe55ed119e@32g2000yqj.googlegroups.com> 
	<1kkz3t83k3e00.dnxvgjppieas.dlg@40tude.net> <f0aef234-fa42-4e1a-8e13-9854c94672df@k30g2000yqf.googlegroups.com> 
	<172g1mrvxbcdm$.q6ueunif1cic.dlg@40tude.net> <85957bb7-1932-4990-8cb5-1f552568383a@e27g2000yqm.googlegroups.com> 
	<1r02x0ytissyv.cxh1eowv0yj7.dlg@40tude.net> <879d5251-ffdc-4e07-8145-52cbb8883bba@n11g2000yqb.googlegroups.com> 
	<u1w2zjklnzd8.ozmcl6nc3omr$.dlg@40tude.net> <d25dcdfc-1baf-44c3-bfeb-c7e31216c268@v36g2000yqv.googlegroups.com> 
	<1hzai5to4uxx2.cw2vmoy2q10n$.dlg@40tude.net> <982283d2-4181-4986-8f18-cf068050fb81@v20g2000yqm.googlegroups.com> 
	<t2fcvlxovn7n$.a7uzq0lpmujv.dlg@40tude.net> <f181b203-a04c-4032-b4ad-5ca23bf7b378@s31g2000yqs.googlegroups.com> 
	<1ptjlnl7q253b$.16yvfc7gny9oe.dlg@40tude.net>
NNTP-Posting-Host: 84.112.82.23
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1251493294 17893 127.0.0.1 (28 Aug 2009 21:01:34 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 28 Aug 2009 21:01:34 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: 32g2000yqj.googlegroups.com; posting-host=84.112.82.23; 
	posting-account=269_QwoAAADSifhJt6OVa6bEjZR2ZMUB
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.13) 
	Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13,gzip(gfe),gzip(gfe)

On 28 Aug., 18:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 28 Aug 2009 06:20:45 -0700 (PDT), tm wrote:
> > On 28 Aug., 10:09, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 27 Aug 2009 15:22:38 -0700 (PDT), tm wrote:
> >>> On 27 Aug., 20:53, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>> wrote:
> >>>> On Thu, 27 Aug 2009 06:29:32 -0700 (PDT), tm wrote:
> >>>>> IMHO a function should be identified by its name and its parameters.
> >>>>> The type of the result should not be needed to identify a function.
>
> >>>> Counterexample is represented by parameterless functions and named
> >>>> constants. Numeric and string literals are such things. If you have several
> >>>> numeric types you need to overload their literals as well as operations.
>
> >>> Maybe for Ada this are counterexamples, but for Seed7 they are not.
> >>> In Seed7 a parameterless function and a named constant are both
> >>> identified just with the name (but attribute parameters can be used
> >>> to attach this names to a type or even several types). The type of
> >>> a Seed7 literal is also unambiguous:
>
> >>> 'a'  ... character literal
>
> >> The same is true for character types. Is 'a' ASCII, Latin-1, UCS-2, UCS-4,
> >> EBCDIC character?
>
> > Seed7 strings are UNICODE strings which use the UTF-32 encoding.
> > All conversions to and from strings used by the operating system
> > (ASCII, Latin-1, UTF-8, UTF-16, ...) are done automatically by the
> > run-time library.
>
> Very bad, it is non-portable too.

Totally wrong. Seed7 strings are portable.
Please look at the Seed7 documentation before claiming such things.

> >> You can declare:
>
> >>    type My_Fancy_String is array (Character range <>) of Wide_Character;
>
> >> and use "ab" as a literal of. Note the My_Fancy_String is indexed by
> >> Character (Latin-1) and contains Wide_Character (UCS-2 Unicode). So a value
> >> of could be:
>
> >>    ('a' => 'a', 'b' => 'b')
>
> >> where 'a' on the left is not 'a' on the right...
>
> > Really?
> > Without your explanation I would have never expected that 'a' and
> > 'a' are not the same.
>
> Why should you expect that?

It seems obvious that 'a' and 'a' is the same.
Most people will agree with me. Ask somebody else to verify.

> >> To me user-defined scalar types are paramount.
>
> > Seed7 supports user defined enumeration types and subtypes of scalar
> > (and other) types (see below for a link to an example).
>
> But no integers, reals etc.

This is wrong. Seed7 supports subtypes of integers and floats also.
Please do not make such unproven claims.

> >>> The expression '20 times 0' creates the array value of 20 integer
> >>> elements with the value 0.
>
> >> But already this is ambiguous in a language like Ada.
>
> > But not in Seed7. In the expression '20 times 0' the 'times'
> > operator uses the index type 'integer' and the lower bound 1.
>
> Why Integer and not Byte, Priority_Level, Identity_No etc?

I did not say that the index must be 'integer'. I wrote:

  Seed7 also supports arrays where the
  index type is not 'integer'.

which includes Byte, Priority_Level, Identity_No etc.

> >> Ada is a strongly typed language you
> >> cannot get anything wrong because of overloading. Any ambiguity is treated
> >> as an error.
>
> > As I showed above a sub-expression like 1+2 can be ambiguous.
>
> Ambiguous in Ada = illegal. You cannot compile an illegal program. No harm
> can happen.

You obviously don't try to follow my arguments.

> >>>> This is
> >>>> automatically more friendly, because the body of name clashes is smaller in
> >>>> Ada than seems to be in Seed7.
>
> >>> I have probably more knowledge about Ada than you about Seed7 :-)
> >>> and I have a different view. "Do what I mean" concepts which are
> >>> not understood by the programmer are a possible source of undetected
> >>> errors.
>
> >> I don't see how it applies here. If there are conflicting interpretations
> >> of a construct, the program is rejected in Ada.
>
> > When the programmer does not know how the overload resolution works
> > he might think that 'a' has type Latin-1 instead of UCS-2. Here I am
> > referring to your example
>
> >   ('a' => 'a', 'b' => 'b')
>
> > where you said:
>
> >   "where 'a' on the left is not 'a' on the right"
>
> The programmer can think anything he wants. What is the problem? So long
> there is no ambiguity, everything is OK.

You think that a program that compiles without errors is OK?

> >>> People are instinctively aware that the bottom up overloading
> >>> resolution determines the type of every expression and subexpresion
> >>> unambiguously.
>
> >> This is an unsupported claim.
>
> > Proof: When I asked you for the type of 1+2 you answered:
> > "Technically in Ada it is Universal_Integer"
> > You probably used a bottom up approach.
>
> No, I did not. Ada declares all integer literals of the type
> Universal_Integer which is automatically converted to the particular
> integer or modular type. The effect is as if types had literals of their
> own. That does not change the semantics. You can treat 1+2 as
> Unsigned_64'(1) + Unsigned_64'(2).

When the + is overloaded with

  function "+"(LEFT, RIGHT: INTEGER) return REAL;

the expression 1+2 may return a 'REAL' result as well as an
'INTEGER' one.

> There is a subtle but important difference, which can illustrate the
> advantages of Ada's model. The standard requires all static numeric
> expressions to be evaluated exact. Consider the following:
>
>    type T is range 1..2;  -- Has only 1 and 2 values
>    X : T := 1024 / 512;  -- This is OK!
>
> Though neither 1024 nor 512 belong to T, the compiler is required to accept
> this program because 1024 / 512 is statically 2 which is in T. Observe that
> an attempt to qualify the types involved in, in a bottom-up manner would
> produce an illegal program,

There is a cast involved when the integer 1024 / 512 is assigned
to T. Seed7 would just require that this cast is explicit instead
of implicit.

> >> On the contrary, observe natural languages
> >> and scientific notations as examples where bottom-up does not work. Human
> >> brain, being heavily parallel, works differently to a computer. To human
> >> perception top down analysis is as natural as bottom up.
>
> > I did not state that bottom up is always better than top down. Just
> > for overload resolution I think it is a simpler and more natural
> > approach with an unambiguous result.
>
> > From the time when structured programming was introduced up to today
> > there are discussions about the advantages of 'goto' statements.
> > I do not expect that the concept of unambiguous expressions (and
> > sub-expressions) is accepted without any discussion.
>
> Huh, the alias name of structured programming was TOP DOWN design.

You seem to misunderstand something.
This is not a fight of TOP DOWN against BOTTOM UP.

> 1+2 perfectly fits the concept. You want to add things at the higher
> abstraction level (on the TOP). If the compiler grasps your idea,
> everything is OK and you both are happy. If it complains, you descend one
> level below (DOWN) and consider what are these types involved etc. It is
> just a matter of productivity, comfort and SAFETY. Consider awful integer
> literals in C. of different length. You have to specify 1L and if later the
> type gets changed you will have to revise the program. That is error prone.

A strong typed language would at least tell you where you need
to change something. In C you don't get helpful error messages
to hint which changes are necessary.

> > AFAIK Ada supports attributes like S'Digits and S'First. Attributes
> > are predefined and IMHO the user cannot define new attributes.
>
> Just like operators, some attributes can be redefined in Ada. BTW I am not
> a bid fan of attributes, especially because they aren't well integrated
> into Ada OO model. I wished to see them primitive operations (AKA "virtual"
> in C++).
>
> > The
> > attribute parameters of Seed7 are a concept which allows user
> > defined attributes.
>
> That is good. Bad is that this feature is misused in order to patch a
> language problem, that parameters of a subprogram receive different
> treatment depending on whether they are arguments or results.

Attribute parameters are a feature that can be used for different
purposes.

> >>>> In Ada it is, in the case of a conflict or when + is not directly visible:
>
> >>>>    My_Module."+" (1, 2)
>
> >>> Ah, the "infix operator is a function and vice versa" concept.
>
> >> Yes. In Ada each operator has a corresponding function, which can be named
> >> and used as a function. For example, + defined on Integer has the name
> >> Standard."+".
>
> > I think this duality of operator/function is not necessary (At least
> > Seed7 does not need it).
>
> Consider this:
>
>    type Saturated is new Integer range 1..20;
>    function "+" (Left, Right : Saturated) return Saturated;
>
> How would you implement "+" that overrides the standard one? The
> implementation can access it using its fully qualified name. (There are
> also other ways. Ada usually offers more than one solution to the problem)

I will think over that.

Greetings Thomas Mertes

Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.