Message from discussion Syntax for user-defined infix operators
From: tm <thomas.mer...@gmx.at>
Subject: Re: Syntax for user-defined infix operators
Date: Fri, 28 Aug 2009 14:01:34 -0700 (PDT)
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)
NNTP-Posting-Date: Fri, 28 Aug 2009 21:01:34 +0000 (UTC)
Injection-Info: 32g2000yqj.googlegroups.com; posting-host=126.96.36.199;
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; de; rv:188.8.131.52)
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>
> 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
> 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
> >> 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
> >>>> 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.