Proposal: automatic type deduction

This proposal is inteded to save the user from a lot of redundant code-repetition and is mainly used for convenience and readability (similar to why a foreach-loop was introduced).


I propose to add a keyword 'let'. The usage looks like the following:

let identifier = expression;

This code is the same as:

typeof(expression) identifier = expression;



'let' prevents from code-repetition, especialy in template-code.

let var = foo * bar + quer;
vs.
typeof(foo * bar + quer) var = foo * bar + quer;

It helps maintainig the code. If you change the code on the right, you have to change the code on the left as well.



But even on very simple common constructs like

SomeClass foo = new SomeClass ();

it can save you from repeating the type:

let foo = new SomeClass ();

Lines looking like this can be found very often, so it helps .




Additionaly 'let' could, but does not neccesarily be useable for automaticaly deducing functions:

void function (let x, let y)
{
..
}

If you need to create further objects of the same type as the arguments, typeof can bee used. The only problem I see is the return-type, as the arguments aren't in socope (are they?) I suppose something like

typeof (x*y) mul (let x, let y)
{
..
}

is illegal, but I'm still no expert in D, so I don't know. If the arguments aren't in scope of the return type, and this isn't going to change, it's eigther impossible or another synthax of specifying the return-type would be needed:

let mul (let x, let y) : typeof (x*y)
{
..
}


If the return-type is 'let' the real return-type will be defined after a colon behind the parameters. An alternate synthax would be using a -> or a notation without any special synthax. I used a colon, as many languages use it in similar cases.

This way any expression containing at least one of the arguments could be used to deduce the type:

let function (let x, let y) : typeof (other(x))
{
..
}

A very interesting idea. I can't think of a problem with what you've described, and it's certainly appeal in a number of ways, so you've got my tentative vote. :)

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bubbe9$1rmf$1@digitaldaemon.com...
> Proposal: automatic type deduction
>
> This proposal is inteded to save the user from a lot of redundant code-repetition and is mainly used for convenience and readability
(similar to
> why a foreach-loop was introduced).
>
>
> I propose to add a keyword 'let'. The usage looks like the following:
>
> let identifier = expression;
>
> This code is the same as:
>
> typeof(expression) identifier = expression;
>
>
>
> 'let' prevents from code-repetition, especialy in template-code.
>
> let var = foo * bar + quer;
> vs.
> typeof(foo * bar + quer) var = foo * bar + quer;
>
> It helps maintainig the code. If you change the code on the right, you
have to
> change the code on the left as well.
>
>
>
> But even on very simple common constructs like
>
> SomeClass foo = new SomeClass ();
>
> it can save you from repeating the type:
>
> let foo = new SomeClass ();
>
> Lines looking like this can be found very often, so it helps .
>
>
>
>
> Additionaly 'let' could, but does not neccesarily be useable for
automaticaly
> deducing functions:
>
> void function (let x, let y)
> {
> ..
> }
>
> If you need to create further objects of the same type as the arguments,
typeof
> can bee used. The only problem I see is the return-type, as the arguments
aren't
> in socope (are they?) I suppose something like
>
> typeof (x*y) mul (let x, let y)
> {
> ..
> }
>
> is illegal, but I'm still no expert in D, so I don't know. If the
arguments
> aren't in scope of the return type, and this isn't going to change, it's
eigther
> impossible or another synthax of specifying the return-type would be
needed:
>
> let mul (let x, let y) : typeof (x*y)
> {
> ..
> }
>
>
> If the return-type is 'let' the real return-type will be defined after a
colon
> behind the parameters. An alternate synthax would be using a -> or a
notation
> without any special synthax. I used a colon, as many languages use it in
similar
> cases.
>
> This way any expression containing at least one of the arguments could be
used
> to deduce the type:
>
> let function (let x, let y) : typeof (other(x))
> {
> ..
> }
>
>

since this seems to only apply when there is an initializer then something
like
  typeof(=) <identifier> = <expression>;
or
"typeof(something-that-indicates-the-type-of-the-initializing-expression)"
could be used. I would guess, though, that something short is what you had
in mind.

Or are you also suggesting "let" be used without an initializer? That would
be a much bigger deal to work into the language. For example, would this
compile?
  let x;
  x = 0;

-Ben

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bubbe9$1rmf$1@digitaldaemon.com...
> Proposal: automatic type deduction
>
> This proposal is inteded to save the user from a lot of redundant code-repetition and is mainly used for convenience and readability
(similar to
> why a foreach-loop was introduced).
>
>
> I propose to add a keyword 'let'. The usage looks like the following:
>
> let identifier = expression;
>
> This code is the same as:
>
> typeof(expression) identifier = expression;
>
>
>
> 'let' prevents from code-repetition, especialy in template-code.
>
> let var = foo * bar + quer;
> vs.
> typeof(foo * bar + quer) var = foo * bar + quer;
>
> It helps maintainig the code. If you change the code on the right, you
have to
> change the code on the left as well.
>
>
>
> But even on very simple common constructs like
>
> SomeClass foo = new SomeClass ();
>
> it can save you from repeating the type:
>
> let foo = new SomeClass ();
>
> Lines looking like this can be found very often, so it helps .
>
>
>
>
> Additionaly 'let' could, but does not neccesarily be useable for
automaticaly
> deducing functions:
>
> void function (let x, let y)
> {
> ..
> }
>
> If you need to create further objects of the same type as the arguments,
typeof
> can bee used. The only problem I see is the return-type, as the arguments
aren't
> in socope (are they?) I suppose something like
>
> typeof (x*y) mul (let x, let y)
> {
> ..
> }
>
> is illegal, but I'm still no expert in D, so I don't know. If the
arguments
> aren't in scope of the return type, and this isn't going to change, it's
eigther
> impossible or another synthax of specifying the return-type would be
needed:
>
> let mul (let x, let y) : typeof (x*y)
> {
> ..
> }
>
>
> If the return-type is 'let' the real return-type will be defined after a
colon
> behind the parameters. An alternate synthax would be using a -> or a
notation
> without any special synthax. I used a colon, as many languages use it in
similar
> cases.
>
> This way any expression containing at least one of the arguments could be
used
> to deduce the type:
>
> let function (let x, let y) : typeof (other(x))
> {
> ..
> }
>
>

>since this seems to only apply when there is an initializer then something like
>  typeof(=) <identifier> = <expression>;
>or "typeof(something-that-indicates-the-type-of-the-initializing-expression)" could be used. I would guess, though, that something short is what you had in mind.

You mean 'typeof(=)' is what is 'let' in my proposal? I have no problem with
this.


>Or are you also suggesting "let" be used without an initializer? That would be a much bigger deal to work into the language. For example, would this compile?
>  let x;
>  x = 0;
>

No. This shouldn't be possible.

Walter, what about you?

> Walter, what about you?

He'll be in stalker-mode. He let's us all argue about it for weeks, and if the consensus doesn't represent a material improvement on his own ideas, or the current situation, it dies.

It's quite a good strategy, if you think about it. :)

In article <budtfl$2t1c$1@digitaldaemon.com>, Matthias Becker says...
>
>>since this seems to only apply when there is an initializer then something like
>>  typeof(=) <identifier> = <expression>;
>>or "typeof(something-that-indicates-the-type-of-the-initializing-expression)" could be used. I would guess, though, that something short is what you had in mind.
>
>You mean 'typeof(=)' is what is 'let' in my proposal? I have no problem with
>this.
>
>
>>Or are you also suggesting "let" be used without an initializer? That would be a much bigger deal to work into the language. For example, would this compile?
>>  let x;
>>  x = 0;
>>
>
>No. This shouldn't be possible.
>
>


How about:

identifier :: type ;
identifier ::= expression ;
identifier ::= auto classname ( parameters ) ;
identifier ::= new classname ( parameters ) ;

At the cost of a a small added complexity in the parser, this could address the type deduction and auto construction questions at the same time.

The tokens mimic the definition token used in some other languages, e.g. dylan.

Ian

>How about:
>
>identifier :: type ;
>identifier ::= expression ;
>identifier ::= auto classname ( parameters ) ;
>identifier ::= new classname ( parameters ) ;
>
>At the cost of a a small added complexity in the parser, this could address the type deduction and auto construction questions at the same time.
>
>The tokens mimic the definition token used in some other languages, e.g. dylan.

I don't think it fits into D. This synthax is just too different. But that's only my opinion.

Sorry to bring it all back to where it started, but what's the problem with

    auto Class instance(args);

??

"Ian Johnston" <Ian_member@pathlink.com> wrote in message news:buj16f$23nj$1@digitaldaemon.com...
> In article <budtfl$2t1c$1@digitaldaemon.com>, Matthias Becker says...
> >
> >>since this seems to only apply when there is an initializer then
something
> >>like
> >>  typeof(=) <identifier> = <expression>;
> >>or
>
>>"typeof(something-that-indicates-the-type-of-the-initializing-expression)"
> >>could be used. I would guess, though, that something short is what you
had
> >>in mind.
> >
> >You mean 'typeof(=)' is what is 'let' in my proposal? I have no problem
with
> >this.
> >
> >
> >>Or are you also suggesting "let" be used without an initializer? That
would
> >>be a much bigger deal to work into the language. For example, would this compile?
> >>  let x;
> >>  x = 0;
> >>
> >
> >No. This shouldn't be possible.
> >
> >
>
>
> How about:
>
> identifier :: type ;
> identifier ::= expression ;
> identifier ::= auto classname ( parameters ) ;
> identifier ::= new classname ( parameters ) ;
>
> At the cost of a a small added complexity in the parser, this could
address
> the type deduction and auto construction questions at the same time.
>
> The tokens mimic the definition token used in some other languages, e.g. dylan.
>
> Ian
>
>
>

Matthias Becker wrote:

> Proposal: automatic type deduction
> 
> This proposal is inteded to save the user from a lot of redundant
> code-repetition and is mainly used for convenience and readability (similar to
> why a foreach-loop was introduced).

I had already brought up such a proposition. Someone else also did. We know it from Sather programming language, where := is a normal assignment operator, and ::= is a type deduction convenience assignment operator. However, Sather has a few more shortcuts to save on, for example, you can let out the type in the new expression and it can be deduced as well. Those are all purely from the information available to compiler anyway, thus not complicating it much.

For D, i had proposed either var keyword as replacement for type, or one of the assignment operators:

var nv = <expr>;
nv := <expr>;
nv ::= <expr>;

to mean

typeof(<expr>) nv = <expr>;

> Additionaly 'let' could, but does not neccesarily be useable for automaticaly
> deducing functions:
> 
> void function (let x, let y)
> {
> ..
> }

This would not be good. We have a requierement that function body need not be parsed to determine calling convention for a function, so that fast parsing and compilation can be used, as well as abridged modules which look like C++ headers.


Sather seems to have done a few things right, since D also inherit property notion and array operator overloading semantics from it.

I'm pretty much sure Walter is aware of the proposal, and at least so far he has not said anything against it. Maybe he's saving it for the future to have room for improvement, or waits for votes or for syntax to come up which which he would be satisfied. I can imagine the feature to pop out of a sudden in the compiler someday. Hey, it pops up on the newsgroup as often as other stuff did, which did make it into the language!

-eye