RAW_FILE not symmetric with put_boolean and no read_boolean

[Brother Bill]

RAW_FILE has

put_natural and read_natural
put_double and read_double

put_boolean but no read_boolean
put_string but no read_string

What good is it to have put_boolean but no read_boolean?
Is there a different routine for read_boolean?

Same thing for put_string, but no read_string.
How are we to read a string?

[rfo amalasoft.com]

For reading a string, use 'read_stream', give it the number of bytes to read, and then access what was read as "last_string'.

And don't forget the check encoding of the stream you just read so that you can associate it with the properly typed handle.

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Brother Bill <brother...@gmail.com>
Sent: Monday, July 1, 2024 2:14 PM
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] RAW_FILE not symmetric with put_boolean and no read_boolean

 

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/afec93aa-7f07-4785-82a4-4f196693d541n%40googlegroups.com.

[Ulrich Windl]

Some API symmetry would be nice however.

--

Mit freundlichen Grüßen
Ulrich Windl

01.07.2024 20:39:37 rfo amalasoft.com <r...@amalasoft.com>:

> For reading a string, use 'read_stream'/, give it the number of bytes to read, and then access what was read as "last_/string'.

> And don't forget the check encoding of the stream you just read so that you can associate it with the properly typed handle.
> R

> ----------------------------------------
> *From:* eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Brother Bill <brother...@gmail.com>
> *Sent:* Monday, July 1, 2024 2:14 PM
> *To:* Eiffel Users <eiffel...@googlegroups.com>
> *Subject:* [eiffel-users] RAW_FILE not symmetric with put_boolean and no read_boolean

>  
> RAW_FILE has
> put_natural and read_natural
> put_double and read_double
> put_boolean but no read_boolean
> put_string but no read_string
>
> What good is it to have put_boolean but no read_boolean?
> Is there a different routine for read_boolean?
>
> Same thing for put_string, but no read_string.
> How are we to read a string?
> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/afec93aa-7f07-4785-82a4-4f196693d541n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/afec93aa-7f07-4785-82a4-4f196693d541n%40googlegroups.com?utm_medium=email&utm_source=footer].

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB9610A7FD113B1681D68A679AA0D32%40CYXPR08MB9610.namprd08.prod.outlook.com[https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB9610A7FD113B1681D68A679AA0D32%40CYXPR08MB9610.namprd08.prod.outlook.com?utm_medium=email&utm_source=footer].

[Bertrand Meyer]

The design is not new so I do not remember the details, but I assume that for booleans the reasoning was that people do not typically write "True" or "False" in files, so there was no need for a read_boolean, and for strings that other routines are available.

On the other hand, it seems reasonable to expect that if something can be written by a routine in the library (e.g. the result of put_boolean) it can also be read by a routine of the library, so read_boolean seems reasonable to add.

As to a possible read_string I am not sure -- what should its specification be? There are things like read_line and (as Roger pointed out) read_stream, which specify precisely how far they read. A read_string would potentially read the entire remaining part of the file.

-- BM

.

[rfo amalasoft.com]

If there were to be a read_string, perhaps its semantics would be more like a "read into string" where a string whose capacity is defined is passed as argument (the handle to the string, not a copy of it) to the routine and the routine fills the target with up to the same number of characters as the argument's capacity.  All this would do is avoid having to provide the count and to refer to last_string afterward, and at a cost of being very confusing and possibly error prone.  As desirable as symmetry might be, it's not always the best arrangement.

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Bertrand Meyer <Bertran...@inf.ethz.ch>
Sent: Tuesday, July 2, 2024 7:55 AM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Cc: me...@inf.ethz.ch <me...@inf.ethz.ch>
Subject: RE: [eiffel-users] RAW_FILE not symmetric with put_boolean and no read_boolean

 

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/05a801dacc76%24bea0afe0%243be20fa0%24%40inf.ethz.ch.

[Brother Bill]

Regarding put_boolean and read_boolean in RAW_FILE, if put_boolean wrote a one-byte NATURAL_8:  1, read_boolean would read contents. 0 = False, non-zero = True.
Regarding put_string and read_string.  Put ASCII string would write out a NATURAL_32 (4 bytes) which is the length of the following string, then the string itself.

There doesn't seem to be much need for writing to a file, without expectations of later reading that same file.

This reminds me of OOSC2 where B.M. had satire of developers having a mania of writing to data structures unnecessarily.
Why write to a file for no purpose?
So symmetry seems desirable.  We write, we later read.  Symmetry is good.

[rfo amalasoft.com]

Please do not confuse symmetry of purpose or process with symmetry of syntax or semantics.  Not the same thing.

The notion of Boolean representation is at the core of the put/read asymmetry.  Put-ing a true/false string might be handy for writing to a screen (remember the old saying that "In UNIX, everything is a file"?) but the screen will not be, programmatically, read.  Not all file-like-devices are plain old files and as such, the symmetry-of-process does not and cannot apply.  A put_boolean routine might be enhanced to include format options, and if so, then there might be an argument made for a "symmetrical" counterpart on the read side.

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Brother Bill <brother...@gmail.com>
Sent: Tuesday, July 2, 2024 9:44 AM
To: Eiffel Users <eiffel...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/787c5074-0562-40c4-9484-edcce9c9e603n%40googlegroups.com.

[Ulrich Windl]

Hi!

I think we have two things:
1) A library that prevents the programmer from "thinking bits"
2) A lack of library functions that force the programmer to "think bits"

So if Eiffel wants to avoid the bitlevel, it has to save the programmer.
Perl has pack and unpack to convert data types to bits and back. Usually you don't need that, but when I wanted to save a floating point number in a way that it is equal when loaded back, I had to use it.
If curious you can find details at stackoverflow.
I also know another product that saves a lot of numeric data as text; when loading a file and saving again, many fractionsl bits change without actually being changed. I noticed when using git to manage versions.
I'm unsure about current Inkscape, but older versions had the same problem.
Again when curious you might find the corresponding bug report.

Sorry for diverting, but binary load/save is important.

Ulrich

[Ian Joyner]

This is an interesting topic. It is about layers of software, abstract (computational) thinking, separation of concerns.

General programmers should not think about bits. They should only think in computational abstractions like those presented by a class as an algebra (set of values, operations on those values, and axioms about the values and operations). Programming should not be done thinking about bits, bytes, or words. That is BCPL, which C is based on, which makes C a mish-mash of programming, with poor separation of concerns.

Of course, programmers might disparage languages with separation of concerns that “I wanted to do … and I couldn’t”. That does not make a language weak, in fact it makes it strong, because abstractions are not undermined. Management likes to choose things using a check list — the more ticks the better. Bit-level operations… tick, must be good. But the absence of the tick is the right option. Trying to change this thinking in the programming profession is difficult.

Mixing in thinking about bits undermines abstractions. This makes for unsafe and insecure programming. (Unsafe versus insecure was addressed by Vint Cerf in a recent CACM.)

In the OSI stack, bit manipulation of data formats is done at the presentation level saving anything written at the application level having to deal with that. System programming is about dealing with the details (non abstract) so that others don’t have to. Class encapsulation is about dealing with the details of a type so that others don’t have to or lock their software into those details.

Undoubtedly for the presentation layer, bit operations are required. But mixing them in an application- and problem-oriented language is a disaster leading programmers to use those operations, resulting in inflexible software and lock in (which C and C++ achieve admirably for the wrong reasons).

So how do we satisfy both needs?

We could just throw everything in as C and C++ do. Obviously I think that is a poor, cheap-and-nasty solution. But it feeds programmers who have been taught about bits, bytes, and words instead of abstract, computational thinking. Of course part of a CS course must teach how it works underneath, but students then miss the important learning about abstract thinking.

We could extend a language with ‘dangerous’ low-level operations, flagged as such. This seems to be the Rust approach, which is rather like Burroughs/Unisys NEWP (which annotates blocks with many levels of different dangerous facilities much more fine-grained than Rust).

https://public.support.unisys.com/aseries/docs/ClearPath-MCP-21.0/86002003-409.pdf

See section 8 ‘Unsafe Mode’.

However, NEWP is only the language for the MCP OS, no programs are written in it (except some low-level stand-alone utilities). The ALGOL-based languages are also layered, with NEWP for the OS, DCALGOL for middleware and presentation layer, and Extended ALGOL for general systems programming (with events and interrupts if required). Application languages are on top of that.

Eiffel has CECIL (is that up-to-date?) to call to languages that do bit-level when needed. This ensures separation of concerns.

A class could be written to encapsulate bit-level operations. I think making such operations generally available would be a mistake.

Ian

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/f39ef85b-7e8a-4d5c-93f2-8dbab3339001%40gmail.com.

[rfo amalasoft.com]

Well spoken, Ian.

The programming languages I appreciate most are Eiffel and C for the very reasons you cite.  It's like Mister Natural said in the old comics: The Right Tool for the Right Job.  It also comes down to the oft ignored principles of coupling and cohesion.  Put more bluntly (and correctly): the Mind Your Own Business principle.  It applies to processes, programs, classes, and every other element of computation.

Abstraction, from the ancient Greek, means "to draw away from".  It does not mean "to run away from", it means to extract the essence, the meaning, the value of something.  In an idealized model it means not having to deal with elements that are not relevant.  It does not mean that they do not exist.  Abstraction removes them from view and if that is the view, the perspective from which a programmer is trying to see and solve a problem (the reason we do anything, presumably), then abstraction distills the essence, from the solution, so that we can see it clearly.

Each level of abstraction is necessary for solutions related to that perspective.  Corrupting that view, without a conspicuous mechanism, corrupts the view and can corrupt the viewer.  A good computer scientist can work at multiple levels of abstraction and will do so to get to the truth, but that doesn't mean they have to wallow in the muck unless that is the chosen perspective.

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Ian Joyner <joyne...@gmail.com>
Sent: Tuesday, July 2, 2024 8:55 PM
To: Eiffel Users <eiffel...@googlegroups.com>

Subject: Re: [eiffel-users] RAW_FILE not symmetric with put_boolean and no read_boolean

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/280924E7-CB75-4FE2-B14C-C25037A202AF%40gmail.com.

[Ian Joyner]

Hello Roger. There are some nicely expressed thoughts about abstraction there. I agree that Eiffel and some system language is good. But the problem with C is it has been hyped as a ‘do everything everywhere’ language. C++ wrongly extends that into OO. C is not even a great system language. We should do better with a more focused language in this day. C is poor at separation of concerns. C++ just makes C worse, not better. A good article on C is:

https://queue.acm.org/detail.cfm?id=3212479

Alan Perlis (first recipient of the ACM Turing Award for computing): “A programming language is low level when its programs require attention to the irrelevant. While, yes, this definition applies to C, it does not capture what people desire in a low-level language.”
C, C++ and the culture around them are holding back programming.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB96103187D715BFD3974C02F9A0DD2%40CYXPR08MB9610.namprd08.prod.outlook.com.

[rfo amalasoft.com]

Hi Ian

I just flashed back to the first C compiler on which I worked, a few hundred years ago.  We did not have an assembler so we output the code stream in machine code.  When I needed to access the CPU with something not offered by the C compiler, I could simply add a line to my C function that contained the hexadecimal machine code I needed, followed by a semicolon.  Good times 🙂

And note well, that when I speak of C, I'm not speaking of that spawn of Satan, C++.

Thanks

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Ian Joyner <joyne...@gmail.com>

Sent: Tuesday, July 2, 2024 11:11 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/2D47D32A-9C95-443E-8793-9B5C773DEB09%40gmail.com.

[Ian Joyner]

Hi Roger.

This is why I advocate having small processor/system platform-dependent structured languages (also for device drivers) for the lowest-level interaction with hardware. Burroughs/Unisys NEWP generates every processor instruction, but many only in blocks annotated to have such capability. For instance the process swap is achieved by the MVST (move stack) instruction, generated by the NEWP ‘move_stack’ instruction. This is only used in a single place in the entire MCP OS, and only the NEWP compiler can generate that instruction. This means there is no assembler or need for it.

Thus I think that instead of C’s lowest-common-denominator facilities like pointers to do memory-mapped control like I/O, a little prettied up by source-level defines (from Burroughs ALGOL in the first place) or target level macros (like Strachey’s GPM), that platform knowledge should be placed in the compiler where a small team has to manage it, rather than all programmers needing to know how semantic platform functions need to be implemented.

This means if a processor vendor changes those details, they reflect the changes in the compiler and not in the language, which is tied to the platform semantics but independent of the platform implementation.

That is another reason why I think C is primitive and should not be of this time.

Ian