Recent

Author Topic: indexind pointer  (Read 5331 times)

440bx

  • Hero Member
  • *****
  • Posts: 4731
Re: indexind pointer
« Reply #45 on: June 29, 2024, 04:57:38 pm »
What about costs in an economic sense?
which pales in comparison to the intellectual cost C has had on language development.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8015
Re: indexind pointer
« Reply #46 on: June 29, 2024, 07:43:38 pm »
In part, definitely. But this simple example comes to mind: String and PChar. The latter exists in Pascal only because the program being created needs to use the operating system or some external libraries written in C. And the conventions for calling functions/procedures: cdecl, safecall, stdcall, etc.? Can this be placed in libraries?

Well, Perl started representing things like that by the inclusion of external modules decades ago: possibly even predating Delphi.

Let's look at this from another angle. In the case of String vs PChar, could those be moved into a common underlying representation, particularly once dynamic arrays had been added to the language?

In Modula-2 Wirth eliminated strings and replaced them by array of char with zero-terminated operations. But in all cases, that leaves the very uncomfortable situation that moving between different families of types (i.e. Pascal's strings vs dynamic arrays) or between text representation in related languages (Pascal vs Modula-2) means changing from 1-based to 0-based indexing. Perhaps a better way would have been pragmata as used by e.g. the JPI/TopSpeed compilers: just as (in Object Pascal) the calling convention can be defined (inadequately, clumsily, non-portably...) by a declaration suffix, in any sensible implementation that would be done by pragmata.

Or another way would have been the early introduction of traits, so that a type could be annotated with "zero-based" or "one-based" etc. In other words, a general solution rather than tackling problems by extending the core language on a case-by-case basis.

So, calling and reference conventions have no place in the core language syntax, which should be reserved for things which are mandatory and portable (i.e. something like "forward" where needed, but not "inline").

Quote
The problem with C is that when it was created, it was basically a makeshift, hacker solution: "Does it work? Works! If anything more is needed, we'll see in the future.

I for one totally buy into the unfashionable idea that C was basically one step up from a set of macros. Good arguments have been made that it wasn't a "set of macros for a PDP-7", but in the 70s and 80s just about everybody extended his assembly-language-of-choice with a set of ALGOL-style macros (i.e. BEGIN, END and so on). About the only thing that merits C being a fullblown compiler rather than assembler macros is the combination of char-aligned memory and ++/-- operators which took into account referent size when manipulating a pointer.

Which is, of course, where this thread started, and which Pascal generally does better by having distinct concepts of "array" and "pointer".

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018