Kimberley Burchett wrote:
> That's interesting.  I didn't know about that feature in Sather.  It's also interesting that they're now deprecating it.  However I somehow doubt that they're deprecating it just because somebody managed to use it to botch up their code.

That's nonsense. It is not deprecated at all. One maintainer didn't like it (just like some people have objections about the feature on this list) and since he was the only one really investing time into Sather development, nobody really was in the position to speak up and argue against it. It was a decision of coding style by one person, and his style was mostly guided by high philosophical opinions rather than by real practicability.

Ciao,
Nobbi

"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> wrote in message news:b09ad9$30q8$1@digitaldaemon.com...
> Daniel Yokomiso wrote:
> > Sather 1.2 provides
> > a ::= assignment that declare lvalue with type and value of rvalue. In
> > Sather 1.3 they are warning against this usage, because it can lead to
> > maintanance problems.
>
> Careful: I was the maintainer of Sather during that time. I've done lots
of
> code in Sather (a complete compiler written from scratch, at one time) and I can only speak in favor of that "::=" construct. I really urge everyone to consider the "var" suggestion. It definitely *improves* maintainability greatly. Of course, one can use that feature to produce unreadable code, but then, an expression where you can't infer the type by a quick glance
is
> a bad idea anyway. If you've come to need the type written in variable declarations as documentation, you really have a much deeper problem.

That's what I thought.  ;)

I believe I prefer a new operator such as := or ::= over the "var" keyword. "var" is more in-line with how C, C++, and D parse declarations though.

> Of course, in D, type inference is not always possible from an expression alone, but why not simply make the use of "var" an error in those cases?

Where is an D expression's type not 100% deterministic?  It's never determined by the type of the result variable.  So it must be determinable just from the expression itself and any declarations that are in scope.  I can't think of a single example.

> Ciao,
> Nobbi

In article <b09jar$5na$1@digitaldaemon.com>, Sean L. Palmer says...
>I believe I prefer a new operator such as := or ::= over the "var" keyword. "var" is more in-line with how C, C++, and D parse declarations though.

I don't mind ::= and I generally like to use existing syntax if possible. However, it would look weird to use ::= for a return type.  Example:

&nbsp;&nbsp;&nbsp;&nbsp;::= add(SomeType x, SomeType y) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return x+y; &nbsp;&nbsp;&nbsp;&nbsp;}

versus this:

&nbsp;&nbsp;&nbsp;&nbsp;var add(SomeType x, SomeType y) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return x + y; &nbsp;&nbsp;&nbsp;&nbsp;}

I think the word "var" already sucks as a return type, but ::= is even worse.

>Where is an D expression's type not 100% deterministic?  It's never determined by the type of the result variable.  So it must be determinable just from the expression itself and any declarations that are in scope.  I can't think of a single example.

recursive functions, if you allow var return types:

&nbsp;&nbsp;&nbsp;&nbsp;var foo(SomeType x) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return foo(x+1)+x;
&nbsp;&nbsp;&nbsp;&nbsp;}

Well I guess using   didn't work.  Here it is again, probably with all the indentation omitted :(

>In article <b09jar$5na$1@digitaldaemon.com>, Sean L. Palmer says...
>I believe I prefer a new operator such as := or ::= over the "var" keyword.
>"var" is more in-line with how C, C++, and D parse declarations though.

I don't mind ::= and I generally like to use existing syntax if possible. However, it would look weird to use ::= for a return type.  Example:

::= add(SomeType x, SomeType y) {
return x+y;
}

versus this:

var add(SomeType x, SomeType y) {
return x + y;
}

I think the word "var" already sucks as a return type, but ::= is even worse.

>Where is an D expression's type not 100% deterministic?  It's never determined by the type of the result variable.  So it must be determinable just from the expression itself and any declarations that are in scope.  I can't think of a single example.

recursive functions, if you allow var return types:

var foo(SomeType x) {
return foo(x+1)+x;
}

Kimberley Burchett wrote:

> In article <b09jar$5na$1@digitaldaemon.com>, Sean L. Palmer says...
>>I believe I prefer a new operator such as := or ::= over the "var" keyword. "var" is more in-line with how C, C++, and D parse declarations though.
> 
> I don't mind ::= and I generally like to use existing syntax if possible. However, it would look weird to use ::= for a return type.  Example:

Please forget about using it for return types. One would need to take a look at the implementation to get the necessary information for the interface. It is nice for local variables, where declaration and "implementation" (i.e. the expression that actually determines the type) are always directly at the same place, but for nothing else. Allowing this "undeterminedness" to spread outside of the function scope woule really make the program unreadable, and in case of recursive functions, the compiler would not even able to determine any type at all.

>>Where is an D expression's type not 100% deterministic?  It's never determined by the type of the result variable.  So it must be determinable just from the expression itself and any declarations that are in scope.  I can't think of a single example.

OK, true, the thing I was thinking of were struct initializers, but those are not really standard expressions...

Norbert Nemec wrote:
> Please forget about using it for return types. One would need to take a look at the implementation to get the necessary information for the interface.

Well of course!  I wasn't intending to allow it for interfaces.

> Allowing this "undeterminedness" to spread outside of the function scope woule really make the program unreadable, and in case of recursive functions, the compiler would not even able to determine any type at all.

I said earlier in this thread that I would disallow it for recursive functions, because that would require some kind of type solver.  I don't know why you think I suggested letting the thing "spread outside of the function scope".

If you want to object to it based on the fact that it would be significantly harder to implement for return values than for local variables, then I'm willing to take the point.  I don't expect the return value thing to actually make it into D at this point.  But the local variable thing might have a chance, and when considering what keyword to use, we might as well take into account where the feature might go in the future.

Kimberley Burchett

Hi,

    Comments embedded.

"Kimberley Burchett" <kimbly at kimbly.comKimberley_member@pathlink.com>
escreveu na mensagem news:b07aek$1tv0$1@digitaldaemon.com...
[snip]

> I agree that the feature can be used in ways that make code more opaque. But then, so can pointers, templates, operator overloading, unions, exceptions, and many more! :)  However I still think something like it is necessary, otherwise templates will be hampered by the type system.
>

    You can program Fortran in any language ;-)

> I'd like to point out that this:
>
> var foo = bar.testIt(baz, fred, 1, 1.9, "\");
> print(foo);
>
> is completely equivalent to this:
>
> print(bar.testIt(baz, fred, 1, 1.9, "\"));
>
> However, by using the variable declaration you can avoid order of execution problems (e.g. if there were code between the assignment of foo and the call to print() that would change the return value of bar.testIt).  Also, the variable declaration lets you reuse the value more than once without having to call bar.testIt() again.
>
> I've never heard anyone claim that you shouldn't be able to compose expressions because it's not clear what the type is of the intermediate values.  So why is it a problem here?

    No real problem I was just trying to make a point. Which point I leave
as an exercise to the reader ;-)

>
> >Sather 1.2 provides a ::= assignment that declare lvalue with type and value of rvalue.  In Sather 1.3 they are warning against this usage, because it can lead to maintanance problems.
>
> That's interesting.  I didn't know about that feature in Sather.  It's also interesting that they're now deprecating it.  However I somehow doubt that they're deprecating it just because somebody managed to use it to botch up their code.

    Sather 1.2 was develop by Berkeley
http://www.icsi.berkeley.edu/~sather/index.html while 1.3 by Waikato
http://www.cs.waikato.ac.nz/sather/  If you read the docs in both sites you
get a dual view about Sather proper usage. They're also against the #
operator now, and promoting the long usage: i.e. instead of #CPX(1,0) you
use CPX.create(1,0). Like the Eiffel deprecated !! notation. Both languages
are going towards explicit coding and verbosity IMO.

> >IMO it's better to make a simpler template
> >syntax than add another concept to to the same job.
>
> I would tend to agree.  I don't think I like it for function args.
>

    If we can address the template problems first, we can focus our
attention latter on other problems. Some kind of type inference would be
wonderful but now it's too difficult to play with the type system and get
something nice out of it.

    Best regards,
    Daniel Yokomiso.

"Actually, C++ is being post-incremented, so this iteration C++ is the same
as c, but next time around it'll be great!"
- tfinniga at /.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003

Hi,

   Comments embedded,

"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de@NOSPAM.COM> escreveu na mensagem news:b09ad9$30q8$1@digitaldaemon.com...
> Daniel Yokomiso wrote:
> > Sather 1.2 provides
> > a ::= assignment that declare lvalue with type and value of rvalue. In
> > Sather 1.3 they are warning against this usage, because it can lead to
> > maintanance problems.
>
> Careful: I was the maintainer of Sather during that time. I've done lots
of
> code in Sather (a complete compiler written from scratch, at one time) and I can only speak in favor of that "::=" construct. I really urge everyone to consider the "var" suggestion. It definitely *improves* maintainability greatly. Of course, one can use that feature to produce unreadable code, but then, an expression where you can't infer the type by a quick glance
is
> a bad idea anyway. If you've come to need the type written in variable declarations as documentation, you really have a much deeper problem.

    Nice to hear that we have some Sather developer here. Most of people
came from an strictly C++ OO/Generics model. I've came accross this warning
at Waikato documentation about Sather 1.3. I just pointed the fact, not
saying some eternal truth.

>
> As an example for where I really hate the lack of such a possibility in
C++
> are iterators:
>
>         for(Somecontainer<Sometype>::Reverse_iterator i = C.end();i;i--) {
>                 ...
>         };
>
> How about this:
>
>         for(var i = C.end();i;i--) {
>                 ...
>         };
>

    Well we can also do this:


C.end().forEach(fun(i) {...});


or


for (i in C.end()) {
    ...
}


or


loop i ::= C.item!
    ...
end

;-)


    Iteration is a problem when you have to create explicit "friend"-like
classes to allow external iteration. IMO Sather iterators are one of the
best possible ways of doing external iteration. If Sather had a simpler type
system, where a Hindley-Milner unification was possible (and using streams
with ! operator instead of anything ending with a !) it could have
higher-order programming over iterators, using them as lazy languages use
lazy lists. My pet language, Eon, has Sather-like iterators as basic types
(along tuples and function types) so we can use map, filter, etc. with
iterators, making any possible higher-order mapping over lists available to
iterators. Someday I'll write a compiler for it. Iin D of course ;-)
    I know that multiple collection iteration is difficult with internal
iterators, but Slate http://slate.tunes.org/ provides a multiple collection
selector. But they're use dynamic typing and I think their implementation
must be dynamically typed.


> Just consider you want to try out another container type and have to go through all your code to adjust the iterators. Of course, there are ways
to
> avoid that, but they all need some overhead at some other place.
>
> Of course, in D, type inference is not always possible from an expression alone, but why not simply make the use of "var" an error in those cases?
>
> Ciao,
> Nobbi


    I don't like the feel of some language feature that sometimes is invalid
because it's ambiguous. That's why I'm playing devil's advocate over this
feature.

    Best regards,
    Daniel Yokomiso.

P.S.: I never thought that post would bring more than one response. I guess people really abhor type declarations ;-)


"Boss: "D?" What happened to C? Or that other one, C++, that you're always
harping about?
Me: Well, D is a further refinement of C++, and ...
Boss: Weren't you just telling me that "J" language was supposed to be the
next big thing? Isn't J further along than D?
Me: Yes and no ...
Boss: And if only want to make small changes, is a "+" higher than a "#"?
[suddenly, a shot rang out]"
- sunwukong at /.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003

Kimberley Burchett wrote:

> Norbert Nemec wrote:
>> Please forget about using it for return types. One would need to take a look at the implementation to get the necessary information for the interface.
> 
> Well of course!  I wasn't intending to allow it for interfaces.
> 
>> Allowing this "undeterminedness" to spread outside of the function scope woule really make the program unreadable, and in case of recursive functions, the compiler would not even able to determine any type at all.
> 
> I said earlier in this thread that I would disallow it for recursive functions, because that would require some kind of type solver.  I don't know why you think I suggested letting the thing "spread outside of the function scope".
> 
> If you want to object to it based on the fact that it would be significantly harder to implement for return values than for local variables, then I'm willing to take the point.  I don't expect the return value thing to actually make it into D at this point.  But the local variable thing might have a chance, and when considering what keyword to use, we might as well take into account where the feature might go in the future.

Guess, we are completely in line at that point. Leave the "inferred types" feature just for the declaration of variables and put everything beyond that ot the section "dreams about the future".

Personally I like the original "var" syntax most. It fits into D syntax far better than "::=" or any of the other suggestions.

Norbert Nemec wrote:
> Kimberley Burchett wrote:
> 
> 
>>In article <b09jar$5na$1@digitaldaemon.com>, Sean L. Palmer says...
>>
>>>I believe I prefer a new operator such as := or ::= over the "var"
>>>keyword. "var" is more in-line with how C, C++, and D parse declarations
>>>though.
>>
>>I don't mind ::= and I generally like to use existing syntax if possible.
>>However, it would look weird to use ::= for a return type.  Example:
> 
> 
> Please forget about using it for return types. One would need to take a look at the implementation to get the necessary information for the interface. It is nice for local variables, where declaration and "implementation" (i.e. the expression that actually determines the type) are always directly at the same place, but for nothing else. Allowing this "undeterminedness" to spread outside of the function scope woule really make the program unreadable, and in case of recursive functions, the compiler would not even able to determine any type at all.

Don't be so quick to judge it.  Often, APIs return "handles" and such. The user is NEVER supposed to access them, although they often are just typedef's of void pointers or unsigned integers.  A function that returned handle could return var.

Not sure if I like the idea or not, but it's worth considering, at least.

The example is problematic because most of the time, you need to save the handle in a struct for later use; how do you declare a member of a struct when it's type is inferred?