Board index » delphi » Re: RFC: Type inference

Re: RFC: Type inference


2008-06-17 12:38:17 AM
delphi148
Joanna Carter writes:
Quote
Rudy Velthuis [TeamB] a écrit :

>Some newsreaders (say, Thunderbird <g>) don't have to convert to
>HTML to do that. They display smileys like that.

Hmmm, yes I am using Thunderbird. What threw me was that all
subsequent replies, even though the do not contain smilies, are also
being rendered in the same font ????
I think I already said, somewhere, that Thunderbird sucks, as newsgroup
client. <g>
--
Rudy Velthuis [TeamB] www.teamb.com
"Behind every great fortune there is a crime."
-- Honore de Balzac (1799-1850)
 
 

Re: RFC: Type inference

Robert Giesecke writes:
Quote
Rudy Velthuis [TeamB] writes:
>
>OK, it may be inferenced later on, but that is too far away from
>the declaration.
>

I think that was what he intended, and why I called it manual code
obfuscation. ;-)
Indeed. OK, the type can probably be inferred (inferenced?) at compile
time, but it looks a lot like dynamic typing to me.
--
Rudy Velthuis [TeamB] www.teamb.com
"Don't sweat the petty things, just pet the sweaty things."
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] writes:
Quote

OK, it may be inferenced later on, but that is too far away from the declaration.

I think that was what he intended, and why I called it manual code obfuscation. ;-)
 

Re: RFC: Type inference

Craig Stuntz [TeamB] writes:
Quote
It's not my preference, either. But "hard to read" is different from
"does not work."
What about the example someone else gave:
procedure Foo(const S: string);
var A; B;
begin
// ... many lines of code here ...
if (SomeCondition) then
begin
// ... more lines of code here ...
A := S; // A: String
// ... more lines of code here ...
B := 1; // B: Integer
end
else
begin
// ... more lines of code here ...
A := 123; // A: Integer
// ... more lines of code here ...
B := S; // B: String
end;
This could turn into dynamic typing after all, which would/should not
work.
--
Rudy Velthuis [TeamB] www.teamb.com
"The only way to combat criminals is by not voting for them."
-- Dayton Allen
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] a écrit :
Quote
Some newsreaders (say, Thunderbird <g>) don't have to convert to HTML
to do that. They display smileys like that.
Hmmm, yes I am using Thunderbird. What threw me was that all subsequent
replies, even though the do not contain smilies, are also being rendered
in the same font ????
My apologies top the the OP for inferring guilt :-)
Joanna
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] writes:
Quote
What about the example someone else gave:
With inferred types, that would fail to compile. Type inferencing
cannot "turn into" dynamic typing. It is static typing, full stop.
(The error would be on the assignment of 123.)
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: learningtowhistle.blogspot.com
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] writes:
Quote
But it
could be pretty hard for users to understand why the above didn't work
with the else part, but would work without it.
Again, that is just a readability issue, and I already said I agreed it
isn't terribly readable without having the assignment inline.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from mers.com
 

Re: RFC: Type inference

Craig Stuntz [TeamB] writes:
Quote
It turns out that supporting type inferencing in publicly visible
types makes the inferencing much, much harder for the compiler. That's
why C#supports it for local variables only. Start there.

Understood.
1. My fault in my OP was that I didn't mention that this was a direct
continuation of the reducing-scope-of vars discussion/inline assignment
from the above thread (see the thread 'Lets' organize our Delphi code).
2. Do you think that having this for local variables only will be
enough? Btw a private field is 'local variable' in our discussion? A
protected one?
--
m. th.
 

Re: RFC: Type inference

Xavier writes:
Quote
m. Th. writes:
>1.) For variables:
>
>var
>foo; //inferenced
>a, b, c: string; //normal vars
>i, j, k: integer; //more normal vars
>...

Type inference simply doesn't fit with Object Pascal's var "section", I
think. To really be useful, inline variable declarations would have to
be added to OP:

procedure Foo(const S: string);
begin
var A := 123; // A: Integer
var B := S; // B: String
end;

Yes, of course. I started an entire thread for this. See above 'Lets'
organize our Delphi code.
Quote
Otherwise, your proposed syntax could lead to serious issues:

procedure Foo(const S: string);
var A; B;
begin
// ... many lines of code here ...

if (SomeCondition) then
begin
// ... more lines of code here ...
A := S; // A: String
// ... more lines of code here ...
B := 1; // B: Integer
end
else begin
// ... more lines of code here ...
A := 123; // A: Integer
No. Compiler error here: 'Unit1.Pas(88): Ambiguous type inference with
line #<lineno>'
Quote
// ... more lines of code here ...
B := S; // B: String
end;

// How does this work now? Nevermind the compiler,
// the coder would be floored way sooner.
A := A + 200;
Same compiler error here. Is type inference, not dynamic typing (A isn't
a variant).
Quote
B := B + 'bar';
end;

>2.) For procedures:
>
>procedure Foo(bar, var baz; aNormalArg: integer);

And what happens to untyped parameters? "Foo", "const Foo", "var Foo"
and "out Foo" are all valid parameter declarations *right now*.
I just wrote in my Delphi 2007 the following code:
interface
procedure Test(a, b, c);
implementation
procedure Test(a, b, c);
begin
ShowMessage('Test');
end;
Ctrl+F9 gives
[DCC Error] Unit1.pas(74): E2067 Missing parameter type
[DCC Error] Unit1.pas(85): E2067 Missing parameter type
[DCC Error] Project1.dpr(11): F2063 Could not compile used unit 'Unit1.pas'
Am I missing something?
--
m. th.
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] writes:
Quote
Robert Giesecke writes:

>Inference makes sense when you see the assignment.
>The actual type is not as important as seeing which value it will
>hold. Putting this in the preceding var-block w/o any clue of what
>it will hold makes it an efficient tool for manual code obfuscation...

I wouldn't even call his example type inference. I would call it dynamic
typing, which is not exactly the same. Type inference means one can
inference the type from the context, usually in an assignment. Here,
one can not (and neither can the compiler).
OK, it may be inferenced
later on, but that is too far away from the declaration.

Yes, exactly this I meant. "too far away from the declaration" - but
what if one can have the a 'using' like structure in Delphi - I called
it 'var'? (See my other thread above). Also, I find interesting while
you are against of having 'using'/declaring variables/aliases in code,
you complain that "...is too far away from the declaration". To quote you,
<quote>
Quote
In a typical 20 line function, it should
not make a big difference.
</quote>
:-)
...see, it is hard to find a balance.
--
m. th.
 

Re: RFC: Type inference

Rudy Velthuis [TeamB] writes:
Quote
Craig Stuntz [TeamB] writes:

>Rudy Velthuis [TeamB] writes:
>
>>What about the example someone else gave:
>With inferred types, that would fail to compile. Type inferencing
>cannot "turn into" dynamic typing.

I know. The compiler would not accept the code in the else part. But it
could be pretty hard for users to understand why the above didn't work
with the else part, but would work without it.

We can have a compiler error like Unit1.pas(42) 'Ambiguous type
inference on var 'foo' with line#88' - as I said elsewhere.
--
m. th.
 

Re: RFC: Type inference

m. Th. writes:
Quote
Do you think that having this for local variables only will be enough?
Works fine in C#.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio Gonzalez has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: RFC: Type inference

Joanna Carter writes:
Quote
Hmmm, yes I am using Thunderbird. What threw me was that all subsequent
replies, even though the do not contain smilies, are also being rendered
in the same font ????
I've seen messages from Japan and other Asian countries turn out a
different font in good ole' Mozilla. I think it chooses a different font
if the message is in unicode. Might be wrong though. And I didn't see
anything like that with m. Th.'s message.
Kjell
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that is one I will have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re: RFC: Type inference

m. Th. writes:
Quote
Yes, exactly this I meant. "too far away from the declaration" - but
what if one can have the a 'using' like structure in Delphi - I
called it 'var'? (See my other thread above). Also, I find
interesting while you are against of having 'using'/declaring
variables/aliases in code, you complain that "...is too far away from
the declaration". To quote you,
If you had read the thread about the inline declaration of blocks, you
would have know that I would actually love to see a "using" block, but I'd
still advocate declaring the using variable in the var section at the
top of the routine, just like the "index" of a for-in, for-to or
for-downto loop must be declared at the top, and not in the loop.
I agree that type inference is most useful with inline declared
variables. I have mixed feelings about this. Type inference is not
really a necessity, it is a convenience issue. So is inline declaration
of variables (unlike in C++, where it often IS a necessity). IME,
inline declared variables are generally harder to follow (trust me,
I've read a lot of C++ code) and therefore less maintainable. But they
make writing (but not reading it) code a lot easier. Type inference is
similar. It makes code harder to read, but easier to write.
At the moment, I still prefer the clarity of Pascal, and am therefore
FOR readability and maintainability, and against inlining and type
inference. But if many people like it, I can live with it. I am not sure
if I would use it.
To recap: Unlike in C++, where the spot where something is declared can
make a difference for the execution of a routine, in Delphi inlining
and type inference are not necessary. Something that can be declared
inline can also be declared at the top without changing the execution
of the code. Inferred types can also be explicitly declared (at the
top). So there is no real need for these features. I would rather see
features added that are needed, IOW, things the user can not simply do
without compiler support, like, say, genericity (yes, I know the next
Delphi will have it).
OTOH, code that is easier to write and does not require much
duplication and a variable that is initalized on the spot is probably
less error prone. IOW, this:
begin
ShowMessage('Start')
var A = IntToStr(17);
is less error prone than:
var
A: string;
begin
ShowMessage('Start');
A := IntToStr(17);
So I do have mixed feelings.
--
Rudy Velthuis [TeamB] www.teamb.com
"A mind all logic is like a knife all blade. It makes the hand
bleed that uses it." -- Rabindranath Tagore
 

Re: RFC: Type inference

Craig Stuntz [TeamB] writes:
Quote
Rudy Velthuis [TeamB] writes:

>But it
>could be pretty hard for users to understand why the above didn't
>work with the else part, but would work without it.

Again, that is just a readability issue, and I already said I agreed
it isn't terribly readable without having the assignment inline.
See my long reply to m. Th. of a few minutes ago. I have mixed feelings
about inlined variables and type inference. I think they often affect
readability negatively, but they also keep declaration and
initialization close to each other, which probably reduces the
opportunity to make errors.
--
Rudy Velthuis [TeamB] www.teamb.com
"If you take something apart and put it back together again
enough times, you will eventually have enough parts left over
to build a second one." -- The law of inanimate reproduction