Re: load_map in map.e - unstructured programming example.
- Posted by gimlet May 08, 2014
- 1461 views
The latter is more 'picking-on' than any direct criticism of code could be.
I thought it was fair comment considering the quality of code.
A key-value line is <key> = <value> where <key> and <value> are Eu objects. Lines are evaluated applying get:value() to the key and value and placed into a map.
They can also be unquoted text, which are turned into strings in Eu.
Missing a point:
Quoted text has a beginning and an end, unquoted text could contain `" = ' { }`. That is good reason to flag this as an error.
The point for insisting on quoted text is there in the specification - 'the key is everything up to the `=`' and that is exactly what the procedure does. It respects nothing not quotes, not { }.
If you insist on quotes at least a scanner can check that `=` is within quotes and therefore is part of the key.
And finally if this was the product of save_map it would appear as a sequence or a quoted string.
They work, so why would they be removed? This just seems silly.
As load_map doesn't work...
if line[$] not in conts then -- clean ll exit -- exit condition should be end if -- (length(ll) and not ll[$] in conts) -- parentheses added for clarity.
I disagree. If that were the case, wouldn't the function exit as soon as it read the first line in, regardless of line continuation? It'd break the line continuation functionality.
No the condition is double: ll has length and does not require a continuation.
As the line is appended to ll the reference to line[$] in the program is unnecessary. It also shows there is a problem with blank lines. A blank line is not a continuation line - the author ignores them. Should he? Looks like an error to me.
How do you get the logical line without completing it??? The logical line is the line that has all line continuations combined (so the multiple physical lines have already been merged into a single logical line).
Step 1 You read lines until you get one which is not empty.
Step 2 If the line is not complete (ie has continuations) read lines until the line
is complete.
But these should all be on one logical line.
Right: they should be if the lines are written correctly.
Verification implies that getline() should do something like this
Read the line a character at a time.
on ' read a character and '
on " read a string and "
on { increment seq
on } decrement seq
on -- ignore the rest of the line
on `-#0-9` read a number
on = and seq = 0 and equ = 0 then you have the key set equ to 1
else you have an error
on `, $` or whitespace continue
else you have something which should not appear in the line
as you build the line each line is submitted to getline()
until you have a complete key and a complete value.
This point should coincide with then end of ll
One complication is this `"` at the end if the line can be followed
by `,` `,$` , `,{` , `}` or nothing. Same with `'`. There may be spaces
between.
However it can be done.
4 the true test of fidelity If the text read in produces the same number of key-value pairs as are defined and when read out the resultant text defines the same key-value pairs as in the original then you have a successful read (of one text). I agree, but I guess the issue is what should load_map() do on error? Should it abort the program, return failure and no valid data, or keep going and get as much valid data as possible? Of course it should report errors (which it sadly does not), but I think it should also try to handle erors gracefully.I'm glad you agree on this.
What the procedure can best do is probably report an error and stop if it is a problem reading lines. If it is an error processing the line report an error and continue.
Addendum:
There is a connection between using while with entry and the structural problems of the code. I didn't spell it out because post was long enough already. I will do that another time.
It is a matter of how while with entry affects you thinking rather than any logical error in its formulation.
