FPC Feature request/suggestion

[440bx]

Nothing will stop people from making mistakes,

I agree with that.  To err is human.  No way around it.

especially if someone is not focused when writing the code or if they lack knowledge,

It helps to be focused and it helps to be knowledgeable but neither prevents making trivial mistakes.

so refraining from expanding the functionality of the language is not a solution to the problem.

I also agree with that but, one thing that programmers should have learned from C is that there is such a thing as brutally poor design (that's putting it kindly) and, that is reflected in things like "=","==","|","||","<","<<" and _countless_ other ways for someone to make a mistake (a simple typo).  A well designed language avoids constructions that lead to such mistakes because, if they are possible, they will happen (particularly typos).   The initialization in Lua is simply extremely poor design.

Features that save time are features that don't send the programmer into the debugger because of a typo.  A language that causes that to happen is ... [accurate description censored by the PTA].

Programming is about _organizing_.  Different initial values -> different declarations.  That way things are grouped by what they have in common, as they should be.

[flowCRANE]

Great summary @Winni — you only convinced me that I was right.

A well designed language avoids constructions that lead to such mistakes because, if they are possible, they will happen (particularly typos). The initialization in Lua is simply extremely poor design.

In the case of Lua-style initialization of variables, this is not a matter of typos, but just a lack of focus. If you assign wrong values to grouped variables, then you wrote several characters incorrectly, not just one.

Programming is about _organizing_.  Different initial values -> different declarations.  That way things are grouped by what they have in common, as they should be.

Python alows for this too, and C-style assigning one value to many variables also. And the Go language too. Why modern languages are so poor designed and, at the same time, so popular? Rhetorical question.

[munair]

I never thought that this could be such a point of debate. It should be easy for the compiler to implement:

1. collect all identifiers
2. get the type
3. get the initial value (if specified)
4. see if the value matches the type

I share that feeling. 

#1 - the compiler already does it.
#2 - the compiler already does it.
#3 - the compiler already does it (but only if there is one identifier... more on that in a bit)
#4 - the compiler already does it.

Apparently not. I was directly referring to your request:

it would be nice if the compiler would allow an initial value for multiple variables in the same declaration.

So "collect all identifiers" is not what the compiler already does. Perhaps I should program my wording more carefully? 

[440bx]

In the case of Lua-style initialization of variables, this is not a matter of typos, but just a lack of focus.

I won't buy that but, I'll rent it for a sentence or two.  No matter how focused you are, you are going to make mistakes.  Moreover, the more focused you are on one thing, the more likely you are to make mistakes in other things that are only "incidental" at the time.  I know, because I do it all the time and I see other people fall in that same trap all the time too.

Focus, not only is no guarantee of not making a mistake, it actually is the cause of mistakes in areas that are not the primary focus.

If you assign wrong values to grouped variables, then you wrote several characters incorrectly, not just one.

if the values assigned are simply determined by their position (that's the impression I get from Leledumbo's example) then transposition is a cause of errors and, transpositions are a very common human error.

Why modern languages are so poor designed and, at the same time, so popular?

The answer to that is really easy.  It's because languages like Python (and RADs like Lazarus) allow people who are not really programmers to get something done.  It makes them feel good.   I don't like to be harsh but, there is a significant percentage of Python users who couldn't code a small fraction of the library functions they use even if their life depended on it.    They use the stuff, as long as their program seems to work, they are happy and grateful there is a tool that enables them to do that.

IOW, Python is popular for the same reason TV Dinners are popular.  You don't need to be a Chef.  Step 1. Remove wrapping cardboard.  Step 2. make a few piercings in the plastic top.  Step 3. microwave for 5 minutes.  Step 4.  Enjoy the culinary masterpiece.  Python Cordon Bleu.  Bon Appetit.

Pascal isn't perfect but considering the state of things when it was designed, it is a masterpiece.  Unfortunately, it got hijacked by a company who saw it as a cash cow.  That worked for a while but, the cow ran out of milk (or is close to running out.)

So "collect all identifiers" is not what the compiler already does. Perhaps I should program my wording more carefully? 

It collects all identifiers up to the data type.  After that it only collects if there is one and only one variable identifier.  IOW, it collects "selectively".

[flowCRANE]

if the values assigned are simply determined by their position (that's the impression I get from Leledumbo's example) then transposition is a cause of errors and, transpositions are a very common human error.

Forgetting to initialize a variable is even more common human error, and language doesn't prevent it.

The answer to that is really easy.  It's because languages like Python (and RADs like Lazarus) allow people who are not really programmers to get something done.

Every single modern and high-level language allow people to do things without huge programming knowledge.

[munair]

Every single modern and high-level language allow people to do things without huge programming knowledge.

Good point.

[jamie]

Code: Pascal  [Select][+][-]

1. 000000010002C991 4889e5                   mov    %rsp,%rbp
2. 000000010002C994 488d6424c0               lea    -0x40(%rsp),%rsp
3. 000000010002C999 48894df0                 mov    %rcx,-0x10(%rbp)
4. 000000010002C99D 488955f8                 mov    %rdx,-0x8(%rbp)
5. unit1.pas:36                              A :=0;B:=0;C:=0;D:=0;E:=0;F:=0;
6. 000000010002C9A1 c745e800000000           movl   $0x0,-0x18(%rbp)
7. 000000010002C9A8 c745e000000000           movl   $0x0,-0x20(%rbp)
8. 000000010002C9AF c745d800000000           movl   $0x0,-0x28(%rbp)
9. 000000010002C9B6 c745d000000000           movl   $0x0,-0x30(%rbp)
10. 000000010002C9BD c745c800000000           movl   $0x0,-0x38(%rbp)
11. 000000010002C9C4 c745c000000000           movl   $0x0,-0x40(%rbp)
12.  

Just an example on how the compiler can do a better job at this..

[440bx]

Forgetting to initialize a variable is even more common human error, and language doesn't prevent it.

That doesn't make initializing a variable to the wrong value a good thing.  A good language, implemented by a good compiler should help the programmer avoid mistakes and catch as many as possible.  Those two characteristics are essential in a piece of software that claims to be a compiler.  Providing a method to carry out some action with a high probability of the programmer getting it wrong is "design a la C".

Every single modern and high-level language allow people to do things without huge programming knowledge.

Yes but, while people could be excused from having an extensive amount of programming knowledge, they cannot be excused from not really knowing what they are doing when using the language.   Computer languages are first and foremost a tool to increase productivity, they are not tools to justify deficient programming knowledge on the part of their users.

The bottom line is simple: if someone wants to be a programmer then they have to know how a computer works.  A cushy high level language does not excuse them from not acquiring a minimum of knowledge in that area.  An example that is almost quintessential by now is the ever more common inability of programmers to use pointers.  It's like someone claiming to be an accomplished driver as long as they are at the wheel of a self-driving car and, claiming that is logically correct. 

[MarkMLl]

I have to admit that I find the one reason given so far to be a bit on the flimsy side.  Here is why: when declaring multiple variables in a group, the _one_ and only _one_ data type specified applies to all the variables in the group.  The data type is assigned to each identifier.  If there was a value specified then, that value can be assigned to each identifier just as the data type is.

I'm not saying that that's a bad or an unconvincing argument, but IMO it's an unfortunate one since the "type after variable names" form of declaration was a hack inflicted by Wirth when he washed his hands of ALGOL for no reason other than to break compatibility. I've reached the relucatant conclusion that the "type before names" form is preferable because it allows the parser to make an early decision as to what form the variable names and possible initialising text should take.

At the same time... there's an ongoing thread where somebody has written assignments like

Code: [Select]

numBytes: = avpicture_get_size (AV_PIX_FMT_RGB24, codec_context ^ .width, codec_context ^ .height);
mybuffer: = av_malloc (numBytes * sizeof (cardinal));

That does have a kind of awful symmetry about it, since it suggests a general

Code: [Select]

identifier [':' type] ['=' initialiser]

syntax applicable to constant declarations, type declarations and ordinary assignment... although I'm pretty sure that Wirth didn't write his compilers assuming that ( :=  was originally a digraph for a left arrow).

MarkMLl

[440bx]

I've reached the relucatant conclusion that the "type before names" form is preferable because it allows the parser to make an early decision as to what form the variable names and possible initialising text should take.

As you noted, specifying the type first makes the parser's job easier but, it does not make the human being's job easier.  The quintessential example of that is the C language.  When reading C, the human being may have to look ahead several tokens (sometimes quite a few) to find out what is being declared (C++ is even worse).   While I subscribe to designing with the goal of being able to use simple algorithms, the top priority is designing for the human being that uses the software and, if that requires more complex algorithms than programming for the computer then, the computer and the parser are out of luck.

I wish I could remember where I read the following, from a compiler writer, who likened putting the data type first as a dictionary where the words are sorted by noun, verb, adjective instead of simply alphabetically.  I found that analogy to be right on the money.  In C, and languages that put the type first, you don't look up "house" by going to the "h", you look it up, first by finding the section about nouns then within that you can find "house".   Someone who tries to look up "accismus" and doesn't know whether it is a noun, a verb or an adjective is going to have some real fun with that one.

At the same time... there's an ongoing thread where somebody has written assignments like

Code: [Select]

numBytes: = avpicture_get_size (AV_PIX_FMT_RGB24, codec_context ^ .width, codec_context ^ .height);
mybuffer: = av_malloc (numBytes * sizeof (cardinal));


I noticed that as a result of the comment you made about it.  I tried to compile it and, as expected, it does _not_ compile.  ":=" is a single token, putting a space between them changes the semantics resulting in an invalid statement.  I doubt any version of FPC compiles that code if there really is a space between the ":" and "=" and, if there is a version that does compile it, I'd report it as a bug since, in that case, the statement is semantically meaningless.

[MarkMLl]

reflected in things like "=","==","|","||","<","<<" and _countless_ other ways for someone to make a mistake (a simple typo).

Most of which can be fixed by adequate type checking, which is something that most language communities are gradually coming to realise.

The things that strike me as really problematic are the single-character = operation (which is variously an assignment or comparison in different languages, and could usefully be replaced by := and == across the board), and ALGOL-style a = b = c assignments (which makes checking for monstrosities like a == b =c difficult).

MarkMLl

[MarkMLl]

I'd be the last to hold C/C++ up as an exemplar of good design. I know that doctrine has it that it wasn't intended to be a set of PDP-7 macros, but I've done enough of that sort of thing to find myself wondering whether initial implementations started off that way before the developers realised they needed a different approach.

I wish I could remember where I read the following, from a compiler writer, who likened putting the data type first as a dictionary where the words are sorted by noun, verb, adjective instead of simply alphabetically.  I found that analogy to be right on the money.  In C, and languages that put the type first, you don't look up "house" by going to the "h", you look it up, first by finding the section about nouns then within that you can find "house".   Someone who tries to look up "accismus" and doesn't know whether it is a noun, a verb or an adjective is going to have some real fun with that one.

OTOH there's the "identifiers should be adequately descriptive" doctrine, and there's common practice where large organisations describe their inventory in normalised form ("That's not a 'slice, fish', Quartermaster, that a 'skimmer, cook's'").

I noticed that as a result of the comment you made about it.  I tried to compile it and, as expected, it does _not_ compile.  ":=" is a single token, putting a space between them changes the semantics resulting in an invalid statement.  I doubt any version of FPC compiles that code if there really is a space between the ":" and "=" and, if there is a version that does compile it, I'd report it as a bug since, in that case, the statement is semantically meaningless.

Which makes me wonder WTF's going on in that thread, and if we're being trolled with non-working code or somebody using a compiler other than FPC.

MarkMLl

[440bx]

Most of which can be fixed by adequate type checking, which is something that most language communities are gradually coming to realize.

Yes but, the C language is so poorly designed that even with the strongest possible form of type checking some of these errors are unavoidable.  For instance, C allows assigning within an expression thus, a statement "if (a = b) ... " is correct in spite of the fact that it is extremely likely the programmer meant to type "if (a == b) ...".  C# and MSVC++ issue a sort-of warning to call the programmer's attention to that very common mistake but, when it comes to "|", "||", "<", "<<" and many others, the design of the language prevents a deterministic conclusion.

IOW, no matter how much lipstick goes on a pig, it's still a pig (granted, with a lot of lipstick... which might be useful for syntax highlighting.)

The things that strike me as really problematic are the single-character = operation (which is variously an assignment or comparison in different languages, and could usefully be replaced by :: and == across the board), and ALGOL-style a = b = c assignments (which makes checking for monstrosities like a == b =c difficult).

There are some syntactic constructions, like the last one you mentioned, which are inexcusable to use in a modern language.  Those constructions would even embarrass the missing link (might even be why it is still missing.) 

More and more I suspect that programming languages are like religion.  About 23 centuries ago, Ptolemy and Aristotle put down the foundations of "physics".  It took about 19 centuries to get rid of all that "wisdom".  Since computer years go by faster, hopefully it will be only one century before the word "science" can legitimately be placed after the word "computer".

[marcov]

As I stated before, I would be against the Lua way of multiple initial values because it's too easy to flip values and end up with the wrong initial values for some variables. […]

Nothing will stop people from making mistakes

Doesn't have to *stop*. Everybody makes small mistakes and typos all the time. Language design is about minimizing both the rate and damage, and maximizing the detection.

[MarkMLl]

There are some syntactic constructions, like the last one you mentioned, which are inexcusable to use in a modern language.  Those constructions would even embarrass the missing link (might even be why it is still missing.)

Your earlier

For instance, C allows assigning within an expression thus, a statement "if (a = b) ... " is correct in spite of the fact that it is extremely likely the programmer meant to type "if (a == b) ...".

is actually the same as the example I gave, which is based on many if not most modern languages being prepared to ignore the result of an expression rather than demanding a dummy assignment. The combination of ignoring an expression result and multiple assignment is what's really dangerous.

In one scripting implementation I've allowed this by putting an expression in parentheses, i.e. a statement  a == b = c;  which would be illegal since it left a value on the stack could be fudged as  (a == b = c);

Another alternative would be to outlaw both  =  and multiple assignment, and at some point (many, many years in the future) reintroduce  =  specifically for assignment inside an expression... I believe that Python now allows that but IMO they've got their notation the wrong way round (= is a normal assignment, := is an in-expression i.e. multiple assignment).

MarkMLl