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.

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

And what is the problem when the user defines new operator symbols
with priority and associativity?

But you need the priorities in the parser to make it working.

Seed7 has solved this problem with a table driven LL(1) parser.

It is possible to reconstruct parser dynamically each time the programmer
defines an operator, but that will one a can or worms.

It is not necessary to reconstruct the parser dynamically. Just the
tables need to be changed.

For example nested
operations declarations will change the syntax of their scope.

Nesting of syntax declarations is not supported in Seed7.

Nobody will
be able to understand such a program or errors spilled by the compiler.

While there is always room to improve, the error messages of the
'hi' (Seed7) interpreter are useful.

A pragmatic approach is to fix all operations and their priorities. I.e.
there is predefined symbol + with the priority lower than *, etc.

No, it is just not necessary to fix all operator symbols and their
priorities in the compiler.

You can introduce a special syntax for op(x,y,z).

Are you suggesting and additional notation used when the operator
is defined?

Is 'y' the operator symbol and 'op' used for all
operators? An additional function style notation for operator
symbols is IMHO a bad idea.

These priorities and associations are NOT necessary. The plan is to
define all such user-defined infix operators as unspecified precedence
and association - at least for now. Then they would need parentheses
to explicitly define the order of application.


OK, but that would take the charm of infix notation away, you would have
parentheses anyway.

However many levels of priorities become a problem, like in C. I think a
reasonable solution is 4-6 levels plus association rules that forbid
certain combination of the operations of equal priority. Ada deploys this
technique. For example:

   x and y or z   -- Illegal

logical "and" may not share operands with "or" (they have same priority).

   x and (y or z)   -- This is OK

You can
introduce a special syntax for op(x,y,z). For example, C++ uses operator op
to construct a proper name of op. Ada uses "op". I think these are good
pragmatic solutions, especially because the syntax op(x,y,z) is rarely used
with operations.

Not sure what you mean here. By a proper name of op you mean a name
for a symbol?

I think you already have this in the form <op><dot>. I.e. if "+" is an
operation then its proper name is "+.". So

  1 + 2
  +.(1, 2)
  integrate (array_of_data, +., *.)  // Passing operations as parameters

I don't think that dot suffix is a good choice. You probably wanted to use
dot as an operation. Traditionally the record member extraction operation
is denoted as dot.

James Harris wrote:

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

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

A little example of definition and usage:

-- | Kripke's quus function.
--   Behaves like +, but returns 5 if either operand is 56 or greater
x `quus` y
    | x < 56 && y < 56 = x + y
    | otherwise = 5


-- | Tests if x is more or less equal to y
x +- y = (x >= y * 0.95) && (x <= y * 1.05)

main = do
  print (4 `quus` 5)
  print (56 `quus` 3)
  print (10 +- 11)
  print (105 +- 100)

Disclaimer: I am not a Haskell programmer, so these examples may not be
idiomatic Haskell.

On 26 Aug, 13:14, "bartc" <ba... at (no spam) freeuk.com> wrote:

James Harris wrote:

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Ah - good question. I'll need to explain a bit more.

The first reason is for simple consistency.

Fields are components of records.
Elements are components of arrays.

For example,

record.field selects an element of the record
seq.index selects an element of the sequence

In both cases the dot allows selection of a subcomponent.

"James Harris" <james.harri... at (no spam) googlemail.com> wrote in message

news:169f6574-7d8d-4b06-8e14-96916468b0d8 at (no spam) b14g2000yqd.googlegroups.com...



On 26 Aug, 13:14, "bartc" <ba... at (no spam) freeuk.com> wrote:

James Harris wrote:

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Ah - good question. I'll need to explain a bit more.

The first reason is for simple consistency.

 Fields are components of records.
 Elements are components of arrays.

For example,

 record.field    selects an element of the record
 seq.index       selects an element of the sequence

In both cases the dot allows selection of a subcomponent.

So the dot selects a field or array element, with the parentheses needed for
array elements because otherwise there would be confusion (but you go on to
say these are optional).

(The confusion, assuming you allow seq.12 even though it looks odd, is that
seq.i could be selecting a field i, or indexing an array with i. With my
languages that would be ambiguous because both kinds of i are allowed into
the namespace at the same time, and a record can be both field selected and
indexed!)

That's OK although most array syntax looks like seq[i] or seq(i).

(I did have vaguely similar ideas once, where I grouped my complex objects
into two: multiple values (lists and arrays), and compound values usually
considered a single object (such as records and strings).

So I used two
indexing methods:

array[i]     i'th element
record.[i]   i'th field (as well as regular fields)
string.[i]   i'th character
integer.[i]  i'th bit

Having the two methods caused some subtle problems however so now I just
have regular a[i] indexing for everything)

  seq.12
  seq.(12)
  seq.(i)
  seq.(8 + 4)

would all mean the same thing.

  seq.i

would be invalid for an array.

It seems then that indexing in this language will usually be seq.(index), so
that the ability to do seq.intconst would be an exception.

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

seq.12.34

Is this seq.(12).(34), or seq.(12.34)? And at the lexical level, abc.123
looks at first like a name followed by a floating point constant value. For
that matter, does seq .12 work? What about seq..950 (seq.(0.950) (I'm
assuming floating indices will be converted to integers). Or:

define twelve=12

seq.twelve?

Yes, I think I would insist on the parentheses!

On 26 Aug, 13:14, "bartc" <ba... at (no spam) freeuk.com> wrote:

James Harris wrote:

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Ah - good question. I'll need to explain a bit more.

The first reason is for simple consistency.

Fields are components of records.
Elements are components of arrays.

For example,

record.field selects an element of the record
seq.index selects an element of the sequence

In both cases the dot allows selection of a subcomponent.

On 26 Aug, 19:46, "bartc" <ba... at (no spam) freeuk.com> wrote:
"James Harris" <james.harri... at (no spam) googlemail.com> wrote in message

news:169f6574-7d8d-4b06-8e14-96916468b0d8 at (no spam) b14g2000yqd.googlegroups.com...

On 26 Aug, 13:14, "bartc" <ba... at (no spam) freeuk.com> wrote:

James Harris wrote:

I have dot as a "subordinacy" or "binding" operator. For records
the notation is record.field. For indexable sequences or any
other type of mapping including function calls the notation is
seq.(index) or mapping.(arg1, arg2, ... argN). Of course, a dot
is also used in floating point numbers.

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Fields are components of records.
Elements are components of arrays.

For example,

record.field selects an element of the record
seq.index selects an element of the sequence

In both cases the dot allows selection of a subcomponent.

So the dot selects a field or array element, with the parentheses
needed for array elements because otherwise there would be confusion
(but you go on to say these are optional).

(The confusion, assuming you allow seq.12 even though it looks odd,
is that seq.i could be selecting a field i, or indexing an array
with i. With my languages that would be ambiguous because both kinds
of i are allowed into the namespace at the same time, and a record
can be both field selected and indexed!)

The expression "seq.12" is OK and would be the same as "seq.(12)" (the
expression in parens, 12, resolves to, er, 12 so is fine) but if i is
an integer the expression would need to be "seq.(i)". On the other
hand "seq.i" would try to select a field called i (which wouldn't
exist in an array) and wouldn't compile. To be clear, if i is 12

seq.12
seq.(12)
seq.(i)
seq.(8 + 4)

would all mean the same thing.

seq.i

would be invalid for an array.

"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()...

Classes are types and are effectively records with field protection
combined with a pseudo-executable inheritance. (I really don't want to
get into the pseudo-executable part of that just now as that is way
off topic. It's probably enough to just ignore the pseudo-executable
part of it and say that classes are types and are effectively records
with field protection combined with inheritance.)

Methods are effectively executable fields of classes with their own
types which includes the types of results and the types of parameters.

OK, this is the "standard model", which is slow (due to redispatch),
asymmetric (cannot handle integers etc), excludes multiple dispatch (cannot
handle + as a method). I dislike it.

On 26 Aug, 15:22, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:
On Wed, 26 Aug 2009 06:52:02 -0700 (PDT), James Harris wrote:
On 26 Aug, 13:14, "bartc" <ba... at (no spam) freeuk.com> wrote:

James Harris wrote:

Well, here are my current plans for the humble dot:

I have dot as a "subordinacy" or "binding" operator. For records the
notation is record.field. For indexable sequences or any other type of
mapping including function calls the notation is seq.(index) or
mapping.(arg1, arg2, ... argN). Of course, a dot is also used in
floating point numbers.

Dots are therefore used in many places. Perhaps too many. I hope they
don't become as irritating as Lisp's parentheses....

Anyone see a problem with using dot in these places?

Why is the dot necessary in seq.(index) or mapping.(arg...)?

Ah - good question. I'll need to explain a bit more.

The first reason is for simple consistency.

  Fields are components of records.
  Elements are components of arrays.

For example,

  record.field    selects an element of the record
  seq.index       selects an element of the sequence

In both cases the dot allows selection of a subcomponent.

Yes, but for a record field is a name, for an array index is an expression.
So, record selection should probably be:

   record.field.

because

   record.field

in your notation could rather mean - take a variable named field and index
record by the value of field.

Not quite. If the subcomponent is an expression it would need
parentheses. Let me show specific examples. Say we had a boring old
employee record. Its fields might include

employee.id
employee.surname
employee.initial

For an array, if we had an array called scores indexed from 0 up to 3
its elements would be

scores.0
scores.1
scores.2
scores.3

In the above, because they are constants, parentheses are optional so

scores.2
scores.(2)

mean exactly the same. If we wanted to access that array with
subscripts which were expressions - say "i" and "i + 2" we would
require parentheses so we get

scores.(i)
scores.(i + 2)

If we had an associative array p_tab its elements might be accessed by

p_tab."id"
p_tab.(name_type + "name")
p_tab.(field_name)

Parens would be mandatory for the last two entries as they are
expressions. Parentheses would be optional for "id" as it is a
constant.

Traditionally record member is considered itself an operation. So it is the
operation <dot><field-name> which is applied to record, rather than the
operation <select> applied to the arguments record and field.

I'm not sure I follow. Are you talking about implementation? My
intention is that the source code express the algorithm but is as
ignorant as possible of the implementation. The idea is that the
implementation can change - perhaps to something faster or to a
debugging version - but the application logic does not need to change.

The
distinction is important. Because the former can give birth to methods, all
distinct according to the names of the fields. With <select> you have only
one method, which limits design to flat containers. Further the signature
of <select> has statically same result type (or no type), so statically all
record components would have one type (or none). This type would
dynamically be resolved to the actual specific types at run-time. I.e. you
force yourself to dynamic typing and only dynamic typing,

Interesting. I've not much considered object orientation much as I'm
waiting to see what is readily implementable and what would be too
slow. What I have in mind at this early stage is:

Classes are types and are effectively records with field protection
combined with a pseudo-executable inheritance. (I really don't want to
get into the pseudo-executable part of that just now as that is way
off topic. It's probably enough to just ignore the pseudo-executable
part of it and say that classes are types and are effectively records
with field protection combined with inheritance.)

Methods are effectively executable fields of classes with their own
types which includes the types of results and the types of parameters.