2 Feb
2021
2 Feb
'21
7:50 p.m.
On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote:
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
On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via
cctalk wrote:
[...]
So why could this not have been done 30 earlier?
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…
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. 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
USE JAVA USE C<BLAH> SPONSORED BY
<BLAH>
SEARCH RUST PROGRAM
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.
Ben.