I have also looked at numeric constants following dot operators, and it
seemed to cause problems:

seq.12.34

Yes, I think I would insist on the parentheses!

On Wed, 26 Aug 2009 20:20:31 GMT, bartc wrote:

Once I designed a language close to what James proposes with regard to the
operation dot. (The idea is somehow infectious ()

In particular it has the operations "." and ":", which are used to extract
substrings (and numeric slices as well). ":" takes the string prefix, "."
does its suffix. For example:

"abcdef".3:2 = "cd"

it works as follows:

("abcdef".3) = "cdef"
"cdef":2 = "cd"

On 27 Aug, 09:40, "Rod Pemberton" <do_not_h... at (no spam) nohavenot.cmm> wrote:
"Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de> wrote in
messagenews:zm5nrfntir2z$.212ivhpy3lmn.dlg at (no spam) 40tude.net...



On Wed, 26 Aug 2009 20:20:31 GMT, bartc wrote:

Once I designed a language close to what James proposes with regard
to the operation dot. (The idea is somehow infectious ()

In particular it has the operations "." and ":", which are used to
extract substrings (and numeric slices as well). ":" takes the
string prefix, "." does its suffix. For example:

"abcdef".3:2 = "cd"

it works as follows:

("abcdef".3) = "cdef"
"cdef":2 = "cd"

Heh! You just reminded me of BASIC. BASIC had/has three substring
operators, i.e., LEFT$, RIGHT$, MID$, and one operator for string
concatenation, +. Even after years of C programming with the
immensely
useful and powerful C string functions, I'm always amazed by how
much those
four operations could do in BASIC. Unfortunately, C needs a function
to do
string concatenation, i.e., strcat()...

One could do a lot with mid$ and its friends but they were seriously
horrible, weren't they?

*Far* better, IMHO, is simple string slicing treating the string as an
array of characters.

On 26 Aug., 11:02, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:

They do not fit into scoped languages,
where different scopes and the same scope may contain identically named
objects with identical / equivalent signatures.

Two objects with with identical / equivalent signature in the same
scope? That would mean that there are ambiguous expressions which can
only be resolved by context.

Ada supports this kind of expressions, but I don't think they are a
good idea. In Ada the + operator can be overloaded with the same
argument types and different result type. E.g.: Two + operators, one
with an integer and one with a float result. This way 1+2 may have
an integer or a float result and the context decides which operator
should be used.

Seed7 does not allow this kind of overloading. The Seed7 overloading
resolution does not take the result of an expression into account.
This way the overload resolution algorithm works strictly bottom up.
This also makes reading expressions easier for humans.

That is why Ada and to a
lesser extent C++ deploy nominal equivalence.

Seed7 - The extensible programming language: User defined statements
Ada and and to a lesser extent C++ have ambiguous expressions
resolved by context. Seed7 tries to avoid this problem by using
unambiguous expressions. In some rare cases this looks complicated,
but in the common case it improves the readability.

On 21 Aug, 15:49, Robbert Haarman <comp.lang.m... at (no spam) inglorion.net
wrote:



On Fri, Aug 21, 2009 at 05:54:15AM -0700, James Harris wrote:

I would like to offer to programmers the ability to use the same
syntax as is available for built-in operations so instead of

  op(a, b)

the programmer could code

  a op b

for a user-defined binary operator, op.

You may want to take a look at how Haskell does it. In Haskell, any function
whose name consists entirely of "symbols" (characters you would normally
expect to find in infix operators) is an infix operator. Other names are
prefix by default. E.g.

12 + 4
div 12 4

You can use an infix operator in prefix position by surrounding it with
parentheses (this is an instance of currying), and you can use a prefix
function in infix position by surrounding it with backticks:

(+) 12 4
12 `div` 4

Thanks, Bob. This is the kind of thing I was looking for. I have my
doubts about the specific syntax used but it shows the same constructs
as I have in mind: turning prefix into infix (and vice versa which is
additional). The result is easy to read though the mechanisms seem
fairly arbitrary.

On 21 Aug, 15:49, Robbert Haarman <comp.lang.m... at (no spam) inglorion.net
wrote:

On Fri, Aug 21, 2009 at 05:54:15AM -0700, James Harris wrote:

You can use an infix operator in prefix position by surrounding it with
parentheses (this is an instance of currying), and you can use a prefix
function in infix position by surrounding it with backticks:

(+) 12 4
12 `div` 4

Thanks, Bob. This is the kind of thing I was looking for. I have my
doubts about the specific syntax used but it shows the same constructs
as I have in mind: turning prefix into infix (and vice versa which is
additional). The result is easy to read though the mechanisms seem
fairly arbitrary.

Opinions sought....

Many (maybe most) languages accept symbols as infix operators for
binary (two-operand) operations such as

x + y

Some also predefine words as infix operators such as Pascal's

i div j

I would like to offer to programmers the ability to use the same
syntax as is available for built-in operations so instead of

op(a, b)

the programmer could code

a op b

for a user-defined binary operator, op.

The problem with this is that we have, effectively, three adjacent
words.

On Thu, 27 Aug 2009 06:29:32 -0700 (PDT), tm wrote:
On 27 Aug., 14:09, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:
On Thu, 27 Aug 2009 02:10:47 -0700 (PDT), tm wrote:
On 26 Aug., 11:02, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:
They do not fit into scoped languages,
where different scopes and the same scope may contain identically named
objects with identical / equivalent signatures.

Two objects with with identical / equivalent signature in the same
scope? That would mean that there are ambiguous expressions which can
only be resolved by context.

Not even by context, if the signature includes the result, as it should,

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.

OTOH a bottom up overloading resolution algorithm is easy to
implement and easy to understand for humans. This way it is also
easy to see why a compiler complains. With a nontrivial overloading
resolution algorithm it can happen that humans think that something
is unambiguous, but the compiler complains and the reason for the
error is not obvious.

But anybody would expect:

A : Array (1..20) := (others => 0);

Without the context (array of 20 elements), you cannot resolve the array
aggregate of indefinite bounds, unknown index type and unknown type of the
elements.

then the only way to resolve ambiguity is per using fully qualified names,
which is a reason to have them.

Ada supports this kind of expressions, but I don't think they are a
good idea. In Ada the + operator can be overloaded with the same
argument types and different result type. E.g.: Two + operators, one
with an integer and one with a float result. This way 1+2 may have
an integer or a float result and the context decides which operator
should be used.

Well this is not really ambiguous.

So you know the result type of 1+2 in the example above?

Why should I know it? Technically in Ada it is Universal_Integer,

but for
the sake of argument, there is no reason to define it in absence of the
target.

In Ada you can have a context where two
objects of equivalent signatures are visible. These cannot be distinguished
otherwise than qualifying the names.

Exactly for this reason I think the Ada way of overloading is wrong.

Actually it is never a problem. In 99% cases when qualified names are used
then with generic instances. But generics is an abomination by itself in
any language. C++ is strictly bottom up, yet templates there is a sheer
horror.

In case of overloading resolution the Ada one is far more
complex to learn and use than the Seed7 one.

No need to learn them, if you are not a compiler designer. The programmer
just uses the names he wants. The compiler rejects illegal choices.

This is
automatically more friendly, because the body of name clashes is smaller in
Ada than seems to be in Seed7.

The golden rule of language design - do not introduce arbitrary
constraints.

Technically you cannot enforce unique names in a large program. You have to
be able to resolve name clashes in the context. There are only two
thinkable ways: context-local renaming and canonic qualifying. The former
is very obtrusive and totally unreadable when it comes to a large scale
software.

I agree, but different libraries usually work with different types so
most things are resolved by normal overloading without the need to
invent strange names. Seed7 has also a feature called attribute
parameter which can be used to attach functions to a type. This
further reduces the need to invent strange names. Attribute
parameters are explained together with class methods here:

http://seed7.sourceforge.net/manual/objects.htm#class_methods

An example of an object declared with an attribute parameter is:

const char: (attr char) . value is ' ';

This attaches '.value' to the type char. To use this constant just
write:

char.value

Seed7 uses this concept to attach default values to all types.
Attribute parameters are not reduced to expressions with '.'.
They can be used in normal functions:

const func circle: create (in integer: radius, attr circle) is
return circle(radius);

This attaches the function 'create' to the type 'circle'. This
function can be called with:

create(10, circle)

Overloading 'create' with several other attribute types is also
possible. As you can see the author of a library has ways to
avoid name clashes to some extent when the library is designed.

This moves redresses lack of the result type in the form of a fake
parameter, ...

... just to make it *overloadable*, as it should have been right
from the start.

Why is this better than obvious:

My_Circle : Circle := Create (10);

Back to the qualifying as you see it. Seed7 does qualifying of
objects without parameters as

myModule.anElement

This is supported in structs and will be also done this way in the
(to be implemented) modules/packages. For objects with parameters
I prefer

myModule.(1+2)

or

myModule.((in integer param) + (in integer param))

over

1 myModule.+ 2

In Ada it is, in the case of a conflict or when + is not directly visible:

My_Module."+" (1, 2)

On 27 Aug., 14:09, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:
On Thu, 27 Aug 2009 02:10:47 -0700 (PDT), tm wrote:
On 26 Aug., 11:02, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:
They do not fit into scoped languages,
where different scopes and the same scope may contain identically named
objects with identical / equivalent signatures.

Two objects with with identical / equivalent signature in the same
scope? That would mean that there are ambiguous expressions which can
only be resolved by context.

Not even by context, if the signature includes the result, as it should,

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.

OTOH a bottom up overloading resolution algorithm is easy to
implement and easy to understand for humans. This way it is also
easy to see why a compiler complains. With a nontrivial overloading
resolution algorithm it can happen that humans think that something
is unambiguous, but the compiler complains and the reason for the
error is not obvious.

then the only way to resolve ambiguity is per using fully qualified names,
which is a reason to have them.

Ada supports this kind of expressions, but I don't think they are a
good idea. In Ada the + operator can be overloaded with the same
argument types and different result type. E.g.: Two + operators, one
with an integer and one with a float result. This way 1+2 may have
an integer or a float result and the context decides which operator
should be used.

Well this is not really ambiguous.

So you know the result type of 1+2 in the example above?

In Ada you can have a context where two
objects of equivalent signatures are visible. These cannot be distinguished
otherwise than qualifying the names.

Exactly for this reason I think the Ada way of overloading is wrong.

In case of overloading resolution the Ada one is far more
complex to learn and use than the Seed7 one.

Technically you cannot enforce unique names in a large program. You have to
be able to resolve name clashes in the context. There are only two
thinkable ways: context-local renaming and canonic qualifying. The former
is very obtrusive and totally unreadable when it comes to a large scale
software.

I agree, but different libraries usually work with different types so
most things are resolved by normal overloading without the need to
invent strange names. Seed7 has also a feature called attribute
parameter which can be used to attach functions to a type. This
further reduces the need to invent strange names. Attribute
parameters are explained together with class methods here:

http://seed7.sourceforge.net/manual/objects.htm#class_methods

An example of an object declared with an attribute parameter is:

const char: (attr char) . value is ' ';

This attaches '.value' to the type char. To use this constant just
write:

char.value

Seed7 uses this concept to attach default values to all types.
Attribute parameters are not reduced to expressions with '.'.
They can be used in normal functions:

const func circle: create (in integer: radius, attr circle) is
return circle(radius);

This attaches the function 'create' to the type 'circle'. This
function can be called with:

create(10, circle)

Overloading 'create' with several other attribute types is also
possible. As you can see the author of a library has ways to
avoid name clashes to some extent when the library is designed.

Back to the qualifying as you see it. Seed7 does qualifying of
objects without parameters as

myModule.anElement

This is supported in structs and will be also done this way in the
(to be implemented) modules/packages. For objects with parameters
I prefer

myModule.(1+2)

or

myModule.((in integer param) + (in integer param))

over

1 myModule.+ 2

On 28 Aug., 18:48, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:

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.

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.

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.

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

James Harris wrote:
On 27 Aug, 09:40, "Rod Pemberton" <do_not_h... at (no spam) nohavenot.cmm> wrote:
"Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de> wrote in
messagenews:zm5nrfntir2z$.212ivhpy3lmn.dlg at (no spam) 40tude.net...

On Wed, 26 Aug 2009 20:20:31 GMT, bartc wrote:

Once I designed a language close to what James proposes with regard
to the operation dot. (The idea is somehow infectious ()

In particular it has the operations "." and ":", which are used to
extract substrings (and numeric slices as well). ":" takes the
string prefix, "." does its suffix. For example:

"abcdef".3:2 = "cd"

it works as follows:

("abcdef".3) = "cdef"
"cdef":2 = "cd"

Heh! You just reminded me of BASIC. BASIC had/has three substring
operators, i.e., LEFT$, RIGHT$, MID$, and one operator for string
concatenation, +. Even after years of C programming with the
immensely
useful and powerful C string functions, I'm always amazed by how
much those
four operations could do in BASIC. Unfortunately, C needs a function
to do
string concatenation, i.e., strcat()...

One could do a lot with mid$ and its friends but they were seriously
horrible, weren't they?

*Far* better, IMHO, is simple string slicing treating the string as an
array of characters.

Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?

*Far* better, IMHO, is simple string slicing treating the string as an
array of characters.
Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?

But which is better?

Depends on your definition of character. Is s[3] really a character, a
codepoint or just the granularity of your encoding (e.g. 2 with UTF-16,
while characters can be multiple 32-bit codepoints in theory)

I think that character string should obviously consist of characters, where
each character is a code point independently on the encoding. Or better to
say it is of no matter which encoding String has. That is an implementation
detail.

To bring a particular encoding into the picture one should have strings of
octets (for UTF- strings of words (UTF-16) etc. These are different types
which basically have nothing to do with String.

On 2009-10-05, Dmitry A. Kazakov <mailbox at (no spam) dmitry-kazakov.de> wrote:

But which is better?

Depends on your definition of character. Is s[3] really a character, a
codepoint or just the granularity of your encoding (e.g. 2 with UTF-16,
while characters can be multiple 32-bit codepoints in theory)

I think that character string should obviously consist of characters, where
each character is a code point independently on the encoding. Or better to
say it is of no matter which encoding String has. That is an implementation
detail.

But in Unicode, (printable) characters can be multiple codepoints. Specially
languages that allow combining of accents need this iirc.

The trouble of using codepoints as character, is that to access s[n] you
have to parse the entire string till you find character n. Might be fine for
a scripting language, but can be a performance killer.

To bring a particular encoding into the picture one should have strings of
octets (for UTF- strings of words (UTF-16) etc. These are different types
which basically have nothing to do with String.

I'm talking about any realistic choice to be used as internal storage inside
"String", and how it translates to String's properties. Other types not
included.