Pascal for VisualBasic users in the Lazarus wiki

[marcov]

Can it be done for dynamic arrays or for static only?

Only for static arrays. Dynamic arrays, being compiler-managed, have to strictly follow the constraints imposed by their behind-the-scenes management, which includes being always zero-based.

Afaik that is mainly because they recycled ansistring parts of the Delphi compiler when they needed dyn arrays for COM, which didn't support a variable lower bound.  The Pascal standards do support e.g. open arrays with explicit lower and upper bound. (search for "conforming arrays")

[Leledumbo]

I used vb6 long before, and fell strange about 'begin' and 'end'.
There no such things in vb.

I welcome you to a block structured language where data declaration/definition is separated from code execution. This makes your eyes easy to search for the variables and can quickly calculate and decide whether a procedure is already too complex by counting the number of declared variables. This makes the compiler job a little bit harder to decide variable's locality, but Pascal is designed for human to read easier.

[taazz]

I had no idea. I use VB6 only when writing Office macros.

https://msdn.microsoft.com/en-us/library/aa266179%28v=vs.60%29.aspx

[mercury]

I welcome you to a block structured language where data declaration/definition is separated from code execution. This makes your eyes easy to search for the variables and can quickly calculate and decide whether a procedure is already too complex by counting the number of declared variables. This makes the compiler job a little bit harder to decide variable's locality, but Pascal is designed for human to read easier.

Well, I think vb is more easy to use.
Variables can be defined any where, or use it without define, even use a UTF-8 name variable.
And 'var', 'begin' and 'end' make the code much longer, don't you feel?

Code: [Select]

If xxx Then
xxx
End If
3 lines in vb

if xxx then
begin
xxx
end;

4 lines in pascal

Code: [Select]

Sub xxx()
xxx
End Sub
3 lines in vb

Code: [Select]

function xxx():xxx;
var
  xxx:xxx;
begin
  xxx
end;
6 lines in pascal

And in vb, you can easy to add a string with a number like

Code: [Select]

MsgBox(Text1.Text + 1)

but in pascal, you must convert first

Code: [Select]

ShowMessage(IntToStr(StrToInt(Edit1.Text) + 1));


[Leledumbo]

Are we starting a Pascal vs VB thread? Very well

Variables can be defined any where, or use it without define, even use a UTF-8 name variable.

Re-read my comment above. Laziness compromises readability.

And 'var', 'begin' and 'end' make the code much longer, don't you feel?

Again, re-read my comment. It makes the code easier to read.

And in vb, you can easy to add a string with a number like

And is a big source of bugs in many VB apps. Strong typing is a Pascal family property, and it prevents many runtime/logic errors easily happened in weakly typed language like VB. VB.NET doesn't allow that anymore since it has to be a good .NET citizens, which also imposes strong typing.

[ausdigi]

Variables can be defined any where, or use it without define

Just today I was doing some VB scripting and set a string in my code and later used it in a report and wasted a couple of minutes trying to work out why part of my report was blank. Turned out I had misspelled the variable the second time VB just accepted it blindly.

[CM630]

 I added Translation of some commonly sought commands and VB commands, which are not present in fpc/Lazarus (total 3 commands).

And 'var', 'begin' and 'end' make the code much longer, don't you feel?

Again, re-read my comment. It makes the code easier to read.

I absolutely disagree with that. Dedicated start and end tags prevent mistakes. But anyway, let's not spoil the thread discussing things which we cannot change.
 

Just today I was doing some VB scripting and set a string in my code and later used it in a report and wasted a couple of minutes trying to work out why part of my report was blank. Turned out I had misspelled the variable the second time VB just accepted it blindly.

Unless you are using MS Office, you should be able to set the compiler to require variable changes. Also, I type the name of a variable once, all next time I use ctrl+ space, both in VB and Pascal.
Edit: In MS Office 2003 you can Main Menu -> Tools -> Options -> Editor -> Require variable declaration

[marcov]

And 'var', 'begin' and 'end' make the code much longer, don't you feel?

Code Length is not an important metric. Typing time doesn't even factor into the time that making a program costs. Debugging is the biggest post.
Readability therefore is paramount.

That goes both ways though, I always liked Modula2/Basic "end xxxx" more than just "end". Though I think the M2 way to only end procedures and functions blocks with "end proc" and "end func", is enough. But not with the function name like M2 does, that is annoying while renaming functions and restructuring code in general.

(a qualifier at the end of the block limits the scope for searching errors in block nesting)

So in short, Pascal's successor Modula2 already did several of these changes (always END to end a block, do away with begin except for a function start etc)
BUT, compatibility is more important. Which is why I'm using Pascal and not Modula-2.

And in vb, you can easy to add a string with a number like

Code: [Select]

MsgBox(Text1.Text + 1)


That is a disaster waiting to happen.

but in pascal, you must convert first

Code: [Select]

ShowMessage(IntToStr(StrToInt(Edit1.Text) + 1));


Yes, treating you proper behaviour, keeping data and UI state apart.

[marcov]

Unless you are using MS Office, you should be able to set the compiler to require variable changes. Also, I type the name of a variable once, all next time I use ctrl+ space, both in VB and Pascal.
Edit: In MS Office 2003 you can Main Menu -> Tools -> Options -> Editor -> Require variable declaration

Such workarounds are like saying "you should have used a safety net" when sb is lying dieing on the ground 

[sam707]

a text concatened with a number simply means that the script engine or the compiler uses "variants", that implies a lot of conversions at runtime, depending the fact it is or not preprocessed, plus its about 'constants" (or not) that can be translated at compile time, vars always will be translated at runtime; all this make a WASTE of time at program execution. the Benefit of strong typed languages and their compilers reside in the fact that 'variants' are not used unless you specify you want them in.

AGAIN ==> Pascal +1 , VB/VBScript -10!!!

[mercury]

Well, I admit that strong typing is better, but weakly typing is much easier.
Or, an option to accept weakly typing or not in compiler?

BTW, both pascal and vb are case not sensitive, but vb's IDE will auto correct.
I hope lazarus can do this too.

[Leledumbo]

Well, I admit that strong typing is better, but weakly typing is much easier.
Or, an option to accept weakly typing or not in complier?

No.

BTW, both pascal and vb are case not sensitive, but vb's IDE will auto correct.
I hope lazarus can do this too.

auto correct what? case?

[mercury]

Well, I admit that strong typing is better, but weakly typing is much easier.
Or, an option to accept weakly typing or not in complier?

No.

Why not?

BTW, both pascal and vb are case not sensitive, but vb's IDE will auto correct.
I hope lazarus can do this too.

auto correct what? case?

auto correct case.

[CM630]

I  tried this:

Code: [Select]

procedure on..click..
var
  i:integer;
begin
   showmsg (inttostr(i));
end;
The result was Zero.I tried it several times.
For some reason I thought the variables in fpc do not get initialized upon declaration and I expeted to receive a random number. Am I wrong or this zero is just a coincedence?


 

Such workarounds are like saying "you should have used a safety net" when sb is lying dieing on the ground 

What workaround? It's just a matter of settings.

[Leledumbo]

Why not?

• Need to modify the syntax parser
• Variants are HEAVY and EXPENSIVE
• Most important: this is Pascal, not VB

Note that VB is not truly compiled, it packs an interpreter inside your exe. It employs then same technique as most dynamically typed language does.

auto correct case

Should be easy to implement, why don't you do it? Extends code tools with this feature, you know what keypress triggers the correction. Identifier lookup functionality is provided already.