On 29/10/2016 17:27, Dennis Lee Bieber wrote:
On Sat, 29 Oct 2016 15:32:16 +0100, BartC <b...@freeuk.com> declaimed the
following:
I still think a beginner would much prefer something along the lines of
'readln a,b,c' (and I still think that's more intuitive).
Then I would suggest using something like REXX or a K&K-based BASIC (I
have no idea, of the top of my head, what Visual BASIC uses).
In REXX, everything is considered a string until it needs to be a
numeric type. And old BASIC would require one to put a data type code on
the variable name which would control the input parsing.
-=-=-=-=-
/* */
say "Enter three integers"
parse pull a b c
That could be workable if it was line-oriented. I strongly suspect it
isn't, because C isn't, and C seems to have lot of influence.
(Non-line-oriented would mean it just keeps sitting there until it's
read three values, damn it, no matter how many times you press Enter,
and it's not going to shift until it has them! In other words,
user-unfriendly.
This is related to my big bug-bear with most text editors where keys
such as left, right, backspace and delete don't stop at the ends of a
line but keep going to previous or next lines.)
The parse command has lots of fancy options allowing for defining fixed
column positions
parse pull 0 a 5 b 8 c
parse pull 5 a 0 b "5" 4 c "9"
That's easy string processing, you don't really need i/o system support:
get the whole line as a string then slice it for the various fields.
For many years, FORTRAN couldn't even handle variable width input from
the keyboard.
READ(5, 1100, END=50, ERR=100) A, B, C
1100 FORMAT("I8, X, I8, X, I8")
I spent a year writing interactive Fortran IV, I'm fairly sure it was
possible but I couldn't tell you how.
Ada.Text_IO.Put ("Enter three integers => ");
Ada.Integer_Text_IO.Get (A);
Ada.Integer_Text_IO.Get (B);
Ada.Integer_Text_IO.Get (C);
I admire Ada in many ways, but this ...
When reading name, file and string items rather than integers, the split
method doesn't deal with embedded quotes. Probably there are bigger guns
you can bring out to deal with more elaborate input, but it starts to
get further away from beginner level.)
Typically, if doing interactive input, you ask for ONE item at a time,
and accept the entire line as the response.
You can't really draw the line like that. This sort of input can used
for live input from a keyboard, from an input file, or a input file
redirected so that it appears to come from the keyboard.
So embedded quotes aren't a
problem. OR you do your own parsing on the line if multiple items are
expected, only reading more from the console when you've run out of data.
Ad hoc parsing of user input is going to be difficult in any language.
But you wouldn't use this for that. I'd use these 'readln' methods for
reading formatted text files; I showed a PPM header example; for
text-mode images, 'read' can also be used.
Then there are text configuration files, or project description files,
or files contain lists of 3D data, or comma- or tab-separated data
files, simple command scripts....
There is a huge range of possible uses for a crude read/readln feature
where verification at the i/o level is not really necessary. (If the
width, image values of a PPM out of range, then you check that at the
application level.)
Anything that is not line-oriented, or that needs very precise parsing
such as code, would just use a different approach.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
