Recent

Author Topic: A suggestion for a new FPC feature  (Read 6720 times)

440bx

  • Hero Member
  • *****
  • Posts: 1197
Re: A suggestion for a new FPC feature
« Reply #45 on: July 03, 2019, 06:56:17 pm »
but it becomes worse
i talking about less typing
Programming isn't about typing less, it's about writing code that is easy to understand and maintain.

simple fiddling with the above example
Code: Pascal  [Select]
  1. type
  2.   ARRAY_RANGE = 0..15;
  3.  
  4. var
  5.   SomeArray[ARRAY_RANGE] of <whatever you want here>;
  6.  
  7. begin
  8. ...
  9.   for I in ARRAY_RANGE do <again whatever you want>
  10. end;
  11.  

it sure beats the rather deficient junk C programmers have to write
Code: Pascal  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (I = 0; I < ARRAY_ELEMENT_COUNT; I++)
Not only is that a whole lot of typing, it is far from being as easy to understand and maintain.

NOTE: the post editor automatically uppercases the letter I (that would not be welcome in a real C program.)

and if for some reason you need the count of elements in the array a simple const after the type declaration does it
Code: Pascal  [Select]
  1. const
  2.   ARRAY_COUNT = high(ARRAY_RANGE) - low(ARRAY_RANGE) + 1;

Combine the above with enumerated types (no 0 thru 15 but <somename> .. <someothername>) when applicable and you can write crystal clear code.

ETA:

The problem is that writing code that is easy to read and understand doesn't make the programmer look "hard core" and, that, seems very important to some programmers (a lot of them love Perl.)
« Last Edit: July 03, 2019, 07:00:04 pm by 440bx »
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

devEric69

  • Full Member
  • ***
  • Posts: 144
Re: A suggestion for a new FPC feature
« Reply #46 on: July 03, 2019, 07:13:26 pm »
Quote
Programming isn't about typing less [SNIP]

Just a relative: I don't really agree with this statement, because the less you type, the less precise the thought and therefore its subsequent understanding or re-reading is, so understandable...
For a programming language, a strong typing is therefore an strong advantage, that should not "fade away" behind less to write for a new grammar change (the proof by the absurd: we can very well only use a unique global variable of the variant type, but it quickly becomes incomprehensible; less ancient languages, like Php, are becoming more typified, precisely to "gain in semantics").
use: Ubuntu 18.04 + Laz. 1.8.5 + FPC 3.0.5 (64 bits).

440bx

  • Hero Member
  • *****
  • Posts: 1197
Re: A suggestion for a new FPC feature
« Reply #47 on: July 03, 2019, 07:25:35 pm »
Just a relative: I don't really agree with this statement, because the less you type, the less precise the thought and therefore its subsequent understanding or re-reading is, so understandable...
It seems to me you are contradicting your own point.  Precision and accuracy very often require additional typing to increase them and, since programming is about precision and accuracy (among other things), it follows that the goal isn't to type less but to enhance and extend the number of mechanisms the language provides for the programmer to achieve greater precision and accuracy.


using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

devEric69

  • Full Member
  • ***
  • Posts: 144
Re: A suggestion for a new FPC feature
« Reply #48 on: July 03, 2019, 07:31:57 pm »
Okay, re-phrase like that, I agree :) .
use: Ubuntu 18.04 + Laz. 1.8.5 + FPC 3.0.5 (64 bits).

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7500
Re: A suggestion for a new FPC feature
« Reply #49 on: July 03, 2019, 07:45:03 pm »
off topic  :-\
i was always confusing about the range declaration in the array
in c it looks resonable

Yeah, I  always also feel very limited in having to forcedly start arrays at 0 in C. It looks reasonable, but it is limitations forced on you. C's form of  bondage and discipline.

440bx

  • Hero Member
  • *****
  • Posts: 1197
Re: A suggestion for a new FPC feature
« Reply #50 on: July 03, 2019, 08:43:50 pm »
Okay, re-phrase like that, I agree :) .
Good :)  I thought we agreed.


Yeah, I  always also feel very limited in having to forcedly start arrays at 0 in C. It looks reasonable, but it is limitations forced on you. C's form of  bondage and discipline.
Starting at an index different than zero can really complicate pointer arithmetic which is quite common in C (and just as common in Pascal depending on what you're doing.)

I rarely use a low bound different than zero - even in Pascal - for that very reason.  That way expressions that calculate an offset in memory can directly use the zero based array index to compute displacements instead of adjusting the index by - low(array)


using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 635
Re: A suggestion for a new FPC feature
« Reply #51 on: July 03, 2019, 09:41:05 pm »
The problem is that writing code that is easy to read and understand doesn't make the programmer look "hard core" and, that, seems very important to some programmers (a lot of them love Perl.)

Yes, but even simpler: if I was too cryptic or quick-and-dirty, and they ask me a year later to make some changes, I don't understand it myself.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7500
Re: A suggestion for a new FPC feature
« Reply #52 on: July 03, 2019, 09:51:13 pm »
Starting at an index different than zero can really complicate pointer arithmetic which is quite common in C (and just as common in Pascal depending on what you're doing.)

Well avoiding pointers is hard, because that is the way of C. Even for something as simple as a by reference parameter.

A lot of it would be unnecessary with a mature language, and then also the limitation seems artificial.

Quote
I rarely use a low bound different than zero - even in Pascal - for that very reason.  That way expressions that calculate an offset in memory can directly use the zero based array index to compute displacements instead of adjusting the index by - low(array)

Not daily. Most of my arrays start with zero. But I wouldn't want to be forced to do that. Arrays for subranges of enums are an example.

PascalDragon

  • Hero Member
  • *****
  • Posts: 670
  • Compiler Developer
Re: A suggestion for a new FPC feature
« Reply #53 on: July 04, 2019, 09:39:42 am »
But the trouble is indeed that the delphi syntax only allows to specify how to catch variables by making them parameters, but that hits the signature.  Syntax wise, some way to mark values are byvalue would be enough, and martin's syntax is not bad.
I'm definitely open to suggestions here though I don't think that "overloading" variable initialization with that is a good idea (especially if - as the example shows - both the inner and outer scope variable share the same name). Introducing a with section wouldn't be that unpascalish though as it can be nicely read from left to right:
Code: Pascal  [Select]
  1. queue(
  2.   procedure
  3.   with msg // by value
  4.   //with msg as var // by ref (default)
  5.   begin
  6.     callwithmessasage (msg);
  7.   end
  8. );
Okay, the with msg as var would conflict with a following var section, but similar to this syntax (maybe with var msg like for parameter declarations?)...

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7500
Re: A suggestion for a new FPC feature
« Reply #54 on: July 04, 2019, 09:52:35 am »
Fine with me. The initialized constant is maybe to ambiguous, since Delphi doesn't do initial local vars.

Zoran

  • Hero Member
  • *****
  • Posts: 1461
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: A suggestion for a new FPC feature
« Reply #55 on: July 04, 2019, 10:48:18 am »
NOTE: the post editor automatically uppercases the letter I (that would not be welcome in a real C program.)

For C code, you should use tag [code=C], not [code=Pascal]. Let's see the difference and whether i is uppercased:

Code: C  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)

comparing to [code=Pascal]
Code: Pascal  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)

Edit:
i is not uppercased, not even with [code=Pascal], I don't know how it happened to you.
Anyway, mark C code as C, not Pascal.
« Last Edit: July 04, 2019, 10:51:16 am by Zoran »

440bx

  • Hero Member
  • *****
  • Posts: 1197
Re: A suggestion for a new FPC feature
« Reply #56 on: July 04, 2019, 11:33:52 am »
For C code, you should use tag [code=C], not [code=Pascal].
I normally use the "code" dropdown and, at least on my machine, it doesn't offer a "C" option.

It works when setting the option manually but I didn't know that "C" was a valid option since it's not found in the dropdown. It doesn't automatically uppercase i, that is nice! :)

Code: C  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)
^ yup, that worked.

Thank you @Zoran, that is definitely an improvement.


using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5696
    • wiki
Re: A suggestion for a new FPC feature
« Reply #57 on: July 04, 2019, 12:47:21 pm »
I normally use the "code" dropdown and, at least on my machine, it doesn't offer a "C" option.
There is a C option.


... Well now there is. Just added.

440bx

  • Hero Member
  • *****
  • Posts: 1197
Re: A suggestion for a new FPC feature
« Reply #58 on: July 04, 2019, 01:23:52 pm »
... Well now there is. Just added.
Excellent!... thank you. :)
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

lucamar

  • Hero Member
  • *****
  • Posts: 2078
Re: A suggestion for a new FPC feature
« Reply #59 on: July 04, 2019, 01:26:46 pm »
OffTopic, but ...

Martin, is there some place where we can see which highlighters are installed in the forum?
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.