Is Tesseract broken?

[nielsie95]

Yes, the reasoning is as in your first example. Perhaps this explains it a bit further:

procedure setVal(var Self: Int32; NewVal: Int32);
begin
  WriteLn('Regular proc: ', @Self);
end;

procedure Int32.setVal(NewVal: Int32);
begin
  WriteLn('Type proc: ', @Self);
end;

procedure test(const a: Int32); overload;
begin
  //setVal(a, 123);   <-- Will not compile: "Variable expected"
  a.setVal(456);   // <-- Will pass "nil" for self, because a is constant/immutable
end;

procedure test(const a: ^Int32); overload;
begin
  setVal(a^, 123); // <-- Dereference is always writable, so can pass as variable
  a^.setVal(456);  // <-- Dereference is always writable, so can pass as variable
end;

var
  i: Int32 = 1;
begin
  test(i);
  test(@i);
end;

I would like to make "a.setVal(456)" give a compiler error too, but currently that would interfere with code like "WriteLn(@Int32.setVal)" if executed in the above example.

[slacky]

I really preferred how we where able to pass constants before, this changes to constant is only limiting what we can do, we can no longer write as expressive code..

the fact that "1.HelloWorld" passes nil is something I really really do not like. I would much rather see a copy passed, or heck.. be able to change the constant. It was useful to me to be able to do shit like { ' '.join(['hello', 'world', '=)']); } .. So, I am a bit angry @nielsie95 for that change, it's not welcomed by me.

[nielsie95]

I agree that it is not a good solution currently. What I want to do is have "variable" and "constant" type methods, similar to regular parameters. Then, instead of passing nil for "mismatches", the compiler could give an error. Constant type methods would not be able to modify Self, while variable type methods (the default) would behave as type methods do currently (with a mutable Self variable).

[slacky]

I agree that it is not a good solution currently. What I want to do is have "variable" and "constant" type methods, similar to regular parameters. Then, instead of passing nil for "mismatches", the compiler could give an error. Constant type methods would not be able to modify Self, while variable type methods (the default) would behave as type methods do currently (with a mutable Self variable).

That does sound like a usable concept; it does require us to repeat our code twice every time we need both var and const-versions. But I see that it might just be what's needed to achieve it without a bunch of hacks.

How would you go about the syntax for such a thing? :P
>> function const TIntArray.Append(..);
>> function TIntArray[const].Append(..);
I assume the former as it most accurately follows the current syntax for declaring constant.. (Tho I find the later prettier =p)

Also, have you seen the lape-issues site lately?
http://code.google.com/p/la-pe/issues/list

We have added two new issues for you to solve. First one (33) is simple enough, second one (34) I have no idea how to fix, so I hope you can take a look at em!

[Brandon]

How would you go about the syntax for such a thing? :P

>> function const TIntArray.Append(..);
>> function TIntArray[const].Append(..);
I assume the former as it most accurately follows the current syntax for declaring constant.. (Tho I find the later prettier =p)

That seems weird.. If it's const.. why would it be appended to? It can't change. But meh. Just a typo I guess.. What about adding it to the end instead?

Something like:

function TIntArray.indexOf(I: int): const int; const;

where the const modifier promises not to modify self or self's member. Basically const for result and const for function.

[slacky]

That seems weird.. If it's const.. why would it be appended to? It can't change. But meh. Just a typo I guess..

Haha! Yeah that's true, I did not think about what I called the function! :-P

What about adding it to the end instead?

Something like:

function TIntArray.indexOf(I: int): const int; const;

where the const modifier promises not to modify self or self's member. Basically const for result and const for function.

I guess, adding it to the end is an option, and it might be the clearest way to go about it.

[N1234]

very interesting, nicely done