 |
Newsgroups: comp.lang.misc
From: "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
Date: Sat, 29 Aug 2009 10:20:33 +0200
Local: Sat, Aug 29 2009 4:20 am
Subject: Re: Syntax for user-defined infix operators
On Fri, 28 Aug 2009 14:01:34 -0700 (PDT), tm wrote: I wrote about types. If user-defined integer *types* are supported, do they > On 28 Aug., 18:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >>>> To me user-defined scalar types are paramount. >>> Seed7 supports user defined enumeration types and subtypes of scalar >> But no integers, reals etc. > This is wrong. Seed7 supports subtypes of integers and floats also. have literals? If they do, then there shall be contexts where 1 may mean more than one type. >>>>> The expression '20 times 0' creates the array value of 20 integer In that case 20 times 0 is "ambiguous" because 20 may refer to >>>>> 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' >> 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 > which includes Byte, Priority_Level, Identity_No etc. Priority_Levels Idle, Very_Low, Low etc, or Bytes from 0 to 19, or whatever. >>>> Ada is a strongly typed language you No, "ambiguity" is a language term. You are using it is a psychological >>>> 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 > You obviously don't try to follow my arguments. context of some imaginary layman, who would consider some language constructs "ambiguous" or not. This is fruitless, because in order to make statements about psychology or sociology, one should conduct scientific experiments. Otherwise it is all a matter of taste. As an OO programmer I am accustomed to generic programming, that is ---------------- >>>>>> This is Certainly yes, if its semantics responds the programmer's intention. The >>>>>> 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 :-) >>>> I don't see how it applies here. If there are conflicting interpretations >>> When the programmer does not know how the overload resolution works >>> ('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 > You think that a program that compiles without errors is OK? converse is wrong. If the programmer's intention was to index UCS-2 string using Latin-1 The task: create a map of Latin-1 characters to the Unicode UCS-2 code In Ada this task can be accomplished in a way I used above: type Latin_to_UCS is array (Character) of Wide_Character; It is natural, obvious and elegant to denote Latin-1 'a' and Unicode 'a' >>>>> People are instinctively aware that the bottom up overloading And Unsigned_8, and Integer_16, and Long_Integer, and potentially infinite >>>>> 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: >> No, I did not. Ada declares all integer literals of the type > When the + is overloaded with > function "+"(LEFT, RIGHT: INTEGER) return REAL; > the expression 1+2 may return a 'REAL' result as well as an number of types. Why should I care without a context? >> There is a subtle but important difference, which can illustrate the So casting to a known type is supposed to be readable? I prefer a language >> 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 >> Though neither 1024 nor 512 belong to T, the compiler is required to accept > There is a cast involved when the integer 1024 / 512 is assigned where I am not forced to cast obvious expressions. >> 1+2 perfectly fits the concept. You want to add things at the higher Yes, and this argument equally refutes what you wrote about "ambiguities". >> 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 > Attribute parameters are a feature that can be used for different Overloading is such a feature. Programmers are not advised to extensively > purposes. use it, but in certain cases they have to. -- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||