ben bfranchuk at jetnet.ab.ca
Tue Feb 2 21:50:56 CST 2021

On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote:
> On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote:
> [...]
>> I don't see languages in general have improved since the the mid
>> 1960's. Hardware and language models don't reflect each other,
>> and don't have extendable data sizes and types.
>> PL/I seems to have been the best,but too tied to IBM.
>> C standard 2131 complex numbers
>> C standard 2143 dubble complex numbers
>> Every machine I can think of had a carry flag of some type
>> yet no language uses that to extend it self.
> You're describing a failing in C and similar languages stuck in the 1960s.
> Here's a Rust method that does add-exposing-carry:
> https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add

So why could this not have been done 30 earlier?

> The documentation doesn't explicitly say "carry" because Rust is
> architecture-neutral and it's down to LLVM to decide how to express it in
> machine code, but on x86 (and probably ARM) the boolean return value comes
> directly from the carry flag.

mincing words, sigh.

>> I don't believe in objects because data structures don't have classes, but
>> are more similar to each other. A window A structure is like window B but
>> details are different. That makes things look portable when they are not.
>> Constants still
>> seem to be embedded in data structures, rather than abstract.
>> -- zero array
>> define LIMIT abc
>> blah array[LIMIT]
>> ...
>> i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw
>> I would like say
>> let LIMIT = abc
>> blah array[LIMIT]
>> i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw
> You "don't believe in objects" yet then describe a problem which only exists
> due to the lack of them and then present OO pseudocode to solve it. A lot of
> OO languages suck of course, but the fundamental idea of encapsulation is
> not the bit that sucks.

Are objects? they only way to solve  this problem.
I see a object as data structure tied to some code.

What I would like to see data structures having fixed constants like 
array start and end of a structure for a array as variables
when called into use.

  Here's it in Rust, where it takes in an arbitrary
> array (pedantically, "slice", a (pointer, element count)-tuple) and
> determines its length at runtime:
> pub fn clear_indexed(array: &mut [usize]) {
>    for index in 0 .. array.len() {
>      array[index] = 0;
>    }
> }

I don't want Information hiding, I want to know what it does clearly. If 
I can't figure it out how can a computer program do it. Where does 
".len()" find the size?

> (The code for C-style fixed-length arrays looks broadly similar but has a
> bit more boilerplate because they're less useful.)
> Iterating over indices is generally discouraged for a number of reasons, not
> least being that the index may be out-of-bounds, but also because it can
> inhibit vectorisation or parallelisation. You have no choice in broken
> languages such as C, but many languages provide some notion of iteration
> which guarantees to not go out-of-bounds:

I say the 0 index in C is broken. ... for array size is better.

> pub fn clear_iterator(array: &mut [usize]) {
>    for elem in array {
>      *elem = 0;
>    }
> }

> Both code fragments generate equivalent assembly in this trivial example
> because the Rust compiler could prove at compile time that the index
> variable can't go out-of-bounds. In more complex real-world code it cannot
> reliably do so and will insert a run-time check which aborts if the index is
> out-of-bounds. Or if it's C, trundle on and corrupt things.
Why prove it? Just test it at runtime.

C was quick and dirty language that had to shoe horn into UNIX, with 
structures tacked on at the last minute. It was up to the programmer not 
the language
to check things, and I still see that valid.

> Oddly enough, the state of the art has moved on a bit in the half-century
> since C was invented. It's just that quite a lot of programmers haven't yet
> noticed.
>   More like SEARCH programming languages

  not many items with 'program' ignoring keyword
  "Ford truck 5K miles for sale, some rust on the fender"

  I have not done programming since about 1990, so modern stuff 
don't have clue,nor do I have large powerful machine.

More information about the cctalk mailing list