Local type inference

On 4 Mar, 13:34, thomas.mer...@gmx.at wrote:

> It is exaclty the violation of this principle that makestypeinferencepossible. As long as this principle holds you need
> to know the global and local declarations to find out the result
> type of an expression. Withtype inferenceit is necessary to
> take other expressions in the local function and even expressions
> in other functions into account. I do not say that this is not
> possible (for sure it is an interesting challenge to invent an
> algorithm to do this). But the reader of the program needs to use
> this algorithm also every time he/she reads the program. And that
> is very bad since (as I already mentioned) a program is more
> often read than written.

It is possible to allow local type inference only, as in C#, where
types can be infered within
function/member bodies only. Woudl that break anything in seed7?

On 19 Aug., 14:00, gremnebulin <peterdjo...@yahoo.com> wrote:
> On 4 Mar, 13:34, thomas.mer...@gmx.at wrote:
>
> > It is exaclty the violation of this principle that makes type
> > inference possible. As long as this principle holds you need
> > to know the global and local declarations to find out the result
> > type of an expression. Withtype inferenceit is necessary to
> > take other expressions in the local function and even expressions
> > in other functions into account. I do not say that this is not
> > possible (for sure it is an interesting challenge to invent an
> > algorithm to do this). But the reader of the program needs to use
> > this algorithm also every time he/she reads the program. And that
> > is very bad since (as I already mentioned) a program is more
> > often read than written.
>
> It is possible to allow local type inference only, as in C#, where
> types can be infered within
> function/member bodies only. Woudl that break anything in seed7?
As the variable declaration of Seed7 use an initialisation value, it
would be possible to get the type from there. Constant declarations
without type could also get the type information from the
initialisation value.

Besides this simple cases a processing of the whole function would
be necessary. I have not thought over this, but the following things
pop up in my mind: Assignments and other functions which would
allow to draw a conclusion about the type are not special for the
parser (other than having an 'inout' parameter which can change a
value).

Syntax and semantic parsing is done in a two step process. The
syntax stage recognizes hardcoded syntax such as a function call
(a name followed possibly by comma separated parameters inside
parens) and syntax constructs declared by the 'syntax' statements
of Seed7 (such as: if while + - := ). The output of the syntax stage
are lists (and sublists) E.g.:

a := 5;
b := a + 1;

is turned into something like

(a := 5) ; (b := (a + 1))

Note that this list consists of symbols and sub symbols, without
any information what these symbols mean. After a function body has
been turned into this form a semantic stage trys to recognize
function calls and everything else. This semantic stage uses a
database of currently valid objects. In principle the recognition
process is working inside out. This mechanism is simple, general,
very powerful and no special meanings are hardcoded. Note that even
the semicolon is not special in this process (there is a semicolon
operator defined in the seed7_05.s7i library).

What happens normally when some type information is missing in some
sub-expression during the semantic parsing is this:

The overloading recognition mechanism uses the type information to
get the right function. When some function argument has no type
information the function cannot be recognized and the type of the
result is also unknown. Another function which uses the result of
the first function as argument has the same problem. The situation
explodes outward such that the whole body of the function has an
unknown type.

Without beeing able to recognice an assignment there is no base to
draw a conclusion about the type. It's like the chicken or the egg
causality dilemma.

I guess that languages which support type inferencing have a
different approach to syntax and semantic analysis which allows
assignments and other important constructs to be recognized without
any type information. Something like: I know this is an assignment,
but I don't know which one. The Seed7 database of defined objects
does not support such things (the symbols and the types are used
as key to find something in this database). Maybe a hardcoded
assignment recognition is used in the type inferencing languages.

To support type inferencing in Seed7 it would be necessary to
introduce such a middle semantic level together with a database
of things declared at this middle semantic level. This database
would also contain the conclusions which can be drawn (type
information wandering from one argument to another). It would also
be necessary to fill this middle semantic level database with
information from type inference statements (which contain the
allowed conclusions).

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.