Recent

Author Topic: Custom type for Nil  (Read 6857 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Custom type for Nil
« Reply #15 on: March 14, 2022, 08:07:21 pm »
Yeah, but wouldn't it be really useful to make use of such a feature yourself?

Yes, but my point is that when Wirth designed Pascal few if any languages and development environments allowed such things: there was hardly any use of external linkable and while it would have undoubtedly been useful to have that flexibility in a monolithic program I suspect it quite simply didn't occur to him... and as I've said before I very much believe that Pascal was rushed.

Quote
I think writeln is a really cool function, it's a shame as a programmer you will never be able to create something as cool as that

I think you could using something like Seed7, and in any case you could obviously massage the source using a sufficiently intelligent preprocessor.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Custom type for Nil
« Reply #16 on: March 14, 2022, 08:54:26 pm »
Summary and conclusion: the problem with variable number of parameters is matching the parameter to the correct type and, the C implementation is, by any meausre, very inadequate (which is typical of C.)  Using function overloading comes very close to enabling the programmer to write variable count parameter functions _almost_ ideally.
That is why I was talkng about C++, which introduced a new varadic parameter mechanism through varadic templates. Rather than having to deal at runtime with the parameters, like C varargs do, it is all during compiletime, using full typechecking. For example, if you want to write a Write like function in C++ this would look somewhat like this:
Code: C  [Select][+][-]
  1. void WriteLn() {
  2.     std::cout << std::endl;
  3. }
  4.  
  5. template<class FirstArg, class... Args>
  6. void WriteLn(FirstArg const &firstArg, Args &&...args) {
  7.   std::cout << firstArg;
  8.   WriteLn(args...);
  9. }
  10.  
  11. int main() {
  12.     WriteLn("Hello World", 42);
  13.     return 0;
  14. }
Note that this has full typechecking, if you use a type that is not supported by std::cout, it will throw an error

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Custom type for Nil
« Reply #17 on: March 15, 2022, 08:50:33 am »
There are a lot of threads complaining that Object Pascal is not C and it should be, it seems.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Custom type for Nil
« Reply #18 on: March 15, 2022, 09:01:56 am »
There are a lot of threads complaining that Object Pascal is not C and it should be, it seems.
Then they are retards that can not distinguish between grammatically the same and expect semantically the same.
They should stay with there multi-line comments oriented (Curly brackets are an example of the above) languages:D O:-)
« Last Edit: March 15, 2022, 09:07:34 am by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Custom type for Nil
« Reply #19 on: March 15, 2022, 09:08:55 am »
There are a lot of threads complaining that Object Pascal is not C and it should be, it seems.
Then they are retards that can not distinguish between grammatically the same and expect semantically the same.
They should stay with there multi-line comments oriented (Curly brackets are an example of the above) languages:D O:-)

Hence https://forum.lazarus.freepascal.org/index.php/topic,53139.msg392670.html#msg392670

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Custom type for Nil
« Reply #20 on: March 15, 2022, 09:20:29 am »
@Warfley: Pascal simply is a language that makes use of some compiler magic. There simply is some functionality that you can't replicate with user code and there is no problem with that, because one does not need to replicate everything.

Code: Pascal  [Select][+][-]
  1. procedure Test(var aArg: LongInt);
  2. begin
  3.   Writeln(HexStr(@aArg));
  4. end;
  5.  
  6. var
  7.   i: LongInt;
  8. begin
  9.   Test(i);
  10.   Test(PLongInt(Nil)^);
  11. end.

I see, I'd been trying (nil^). Is it possible to test for a var parameter that's been fabricated like that being nil?

What about Assigned(@aArg) ;)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Custom type for Nil
« Reply #21 on: March 15, 2022, 09:36:30 am »
What about Assigned(@aArg) ;)

Apologies if that appeared to be a silly question, I'm just being very cautious :-)

I'll have a play with that presently. I transcribed a moderate-sized library from C to Pascal a few weeks ago where I had to backtrack and pass stuff as pointers, so it's interesting to know that there's a viable alternative.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Custom type for Nil
« Reply #22 on: March 15, 2022, 10:51:17 am »
There are a lot of threads complaining that Object Pascal is not C and it should be, it seems.
Language development should of course look at other languages on what works and what can be incorporated. That said I do not want Pascal to become C++, in fact the template example from above is one thing I do not want in Pascal, because the way templates are implemented in C++ are way to complicated, as they rely on pattern matching and using substitution failures (SFINAE) which can really make your head spin.
I don't think that this should really be replicated in any form.

C++ is a language that tries to incorporate pretty much all features it can find. Some of which are great, others not so. If there are good features in C++, I think they should be considered to work into Pascal, the same holds for other languages as well. There are heaps of features of for example C#, Swift, Haskell (or functional programming in general) or Python that I think would be great in Pascal (e.g. Lambda expressions, which are currently in development for the FPC and already exist in Delphi). From the top of my head I could name at least 5 features of those languages right now, that would be really great in Pascal.
C++ is of course a close one to look to, because Pascal is in many ways already rather close to C++ with both languages being low level native languages that require you to deal with things like pointers and memory management, so it of course invites comparisons

PS: I see very often that people write C when they mean C++ (and I just assumed you did, because every comment in this direction here was about C++ not C). Just on a side note, these are two different languages, while C is mostly compatible with C++, it is not a full subset. Most non-trivial C programs will not be accepted by a C++ compiler. A C programmer will probably not be able to write good C++ code and a C++ programmer will probably also struggle writing good C code.
« Last Edit: March 15, 2022, 11:05:15 am by Warfley »

bytebites

  • Hero Member
  • *****
  • Posts: 632
Re: Custom type for Nil
« Reply #23 on: March 15, 2022, 11:26:38 am »
One of the Python features would be popularity.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Custom type for Nil
« Reply #24 on: March 15, 2022, 11:46:03 am »
One of the Python features would be popularity.
Maybe it is so popular because of it's great features ;)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Custom type for Nil
« Reply #25 on: March 15, 2022, 01:08:05 pm »
The last time I worked on a large C# (web) application, I spend a lot of time making my code as readable and logical as possible. When working in a team, that helps a lot. But the senior developer was a huge fan of Resharper: he turned om all the checkboxes and let it rip on our unsuspecting code.

At some point, the new version of Resharper supported Lambda functions and turned all my beautiful and readable code into single LINQ expressions. That project didn't end well...

So, yes, improvements can be made. But you shouldn't force them on people and not all changes are automatically better. The more ways there are to do the same thing, the less readable the result. I think a lot of things Delphi did (especially after version 7) also fall in that category.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Custom type for Nil
« Reply #26 on: March 15, 2022, 01:44:46 pm »
At some point, the new version of Resharper supported Lambda functions and turned all my beautiful and readable code into single LINQ expressions. That project didn't end well...
Of course, just because you can, doesn't mean you should. One great example with this I have is I worked on code with someone who really did not like multiple ifs and started building multiline boolean expressions to cover to the point where when had a bug in one of these conditions, it lead to having to rewrite nearly all of them and took multiple hours to do so.

But of course the language can also limit such features, e.g. what I really like about python, as opposed to for example Javascript (or C#, C++ and most other languages) is that it limits lambda functions to single expressions. While you have in Javascript often whole functions of multiple lines, with conditions, loops, etc as lambdas (well from a theoretical viewpoint those aren't lambda expressions anymore but anonymous functions), python only allow a singe expression:
Code: Pascal  [Select][+][-]
  1. lambda paramters: expr
Everything more than that, you need to write a function. Which I think is a great limitation, and one reason why monster lambda constructs aren't a thing in Python while in Javascript they make up most of the javascript code you see.

Also the features need to fit the language. For example I really like the way swift implements optionals is great, but would not be possible in Pascal as Pascal uses Pointers.
But a few features I like greatly and I think would fit pascal would be:
1. Dynamic sets and dictionaries (additionally to the dynamic arrays which already exist)  as in Python or Swift, making dictionaries (or associative arrays as they are also often called) a "base type" like dynamic arrays are with assignment syntax (such as [key: value, ...]), would make a lot of code much easier than having to initilize and fill a Dictionary object. Same vor hashsets (in addition to the already existing bitsets)
2. List comprehensions, like in Haskell or python, where you can create a list from expressions like squares = [x*x for x in 0..10]
3. named function parameters as in python, so you can write funcname(param1: Value, param2: Value, ...), which would be great for functions taking many parameters, which currently can be a massive source of errors when using default parameter values (where you do not realize you miss an argument because your arguments are shifted by 1 after adding a new argument in the front)
4. Fixing function parameters, like in haskell, where the function parameters can be partly set (like where (plus 5) is a function that calls plus with the first argument being 5). This would basically be possible (even if it's tedious as it requires declaring every parameter) with lambads.
5. Operators as functions, as in haskell. In Haskell you can take any operator also as function where (+) is the function taking two inputs calling the + operator on them. This is really useful if you want to pass a function pointer but you want it to only execute a simple operator, e.g. if you have a sorted list class that takes a compare function pointer and you could simply pass the existing < operator for integers.
6. Tuples like in Python or C#, just allowing functions to return more than one value as result, so you do not need to have to use an out parameter (which if you want to ignore it requires you to declare a dummy variable)

These are just 6 examples that I think would not just be really useful, but could also fit the language without leading to a massive feature bloat, as these would integrate nicely with already established features of the language

VisualLab

  • Sr. Member
  • ****
  • Posts: 290
Re: Custom type for Nil
« Reply #27 on: March 15, 2022, 02:03:50 pm »
There are heaps of features of for example C#, Swift, Haskell (or functional programming in general) or Python that I think would be great in Pascal (e.g. Lambda expressions, which are currently in development for the FPC and already exist in Delphi).

Python is an anti-example. You should definitely not copy anything from it. There is:

- interpreted (one of the reasons why scripts run slowly),
- it lacks a type system (errors are revealed when the script is run),
- it lacks class encapsulation (it has a primitive emulation of objects),
- variables (most of the time) are immutable (another one of the reasons why scripts run slowly),
- no variable declaration, which enables the creation of another variable, which may override an already existing variable with the same name,
- no constants,
- no statement like "case" ("switch" in C / C ++),
- not very clear notation.

These are some of the most conspicuous and, at the same time, the most annoying features of Python.

bytebites

  • Hero Member
  • *****
  • Posts: 632
Re: Custom type for Nil
« Reply #28 on: March 15, 2022, 02:08:37 pm »
Python has pattern matching: https://peps.python.org/pep-0636/

VisualLab

  • Sr. Member
  • ****
  • Posts: 290
Re: Custom type for Nil
« Reply #29 on: March 15, 2022, 02:15:00 pm »
But of course the language can also limit such features, e.g. what I really like about python, as opposed to for example Javascript (or C#, C++ and most other languages) is that it limits lambda functions to single expressions. While you have in Javascript often whole functions of multiple lines, with conditions, loops, etc as lambdas (well from a theoretical viewpoint those aren't lambda expressions anymore but anonymous functions), python only allow a singe expression:
Code: Pascal  [Select][+][-]
  1. lambda paramters: expr
Everything more than that, you need to write a function. Which I think is a great limitation, and one reason why monster lambda constructs aren't a thing in Python while in Javascript they make up most of the javascript code you see.

Lambda expressions are just irrelevant in languages such as Pascal, Object Pascal, C or C ++ (compiled into machine code). Because there are pointers to functions/procedures for a long time. There is no other mechanism in scripting languages such as JavaScript. So that's where it is needed. And I completely agree with the previous speaker that they are abused. Codes-monsters are created. Such code is not readable. In some time it will be like that in Delphi (or maybe it already is).

 

TinyPortal © 2005-2018