Re: load_map in map.e - unstructured programming example.

new topic     » goto parent     » topic index » view thread      » older message » newer message
gimlet said...

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.

Hmm. This is a good point. On the other hand, we could get away with stating that "The following characters ... are illegal in unquoted text, if you want to use them you must use quoted text."

gimlet said...

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 { }.

Looks like you are right. That's actually pretty bad.

gimlet said...

If you insist on quotes at least a scanner can check that `=` is within quotes and therefore is part of the key.

Agreed.

gimlet said...

And finally if this was the product of save_map it would appear as a sequence or a quoted string.

Or a binary serialized map, yeah.

gimlet said...
    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.

Ok, I get it now! I think this is unimportant, either condition will exit correctly.

gimlet said...

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.

On the flip side, a blank line can not be a valid record. So the only time this could be a problem is when a line continuation is followed by one or more blank lines and then another record.

gimlet said...

Step 1 You read lines until you get one which is not empty.

Isn't this the same as ignoring blank lines?

gimlet said...

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.

Ok. This algorithm works as long as line continuations do not occur in the middle of a sequence or quoted string, etc. But I'm not sure if that's currently legal anyways.

Why not finish your algorithm and submit a patch? You already seem to know exactly how and where load_map() is broken, and how to fix it. You've already done most of the hard work - but without a patch, someone else would have to redo a lot of that work that you have already done.

gimlet said...

  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.

You mean when we've hit -1 EOF ? I concur, but it should return all the valid data accumulated thus far as well.

gimlet said...

If it is an error processing the line report an error and continue.

Ditto.

gimlet said...

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.

Now you are trying to speak about psychology here.... It's reasonable to state that use of a certain programming language construct affects a person's way or form of thinking, but it's still a huge leap to make.

Until you produce such a post, I'll continue to maintain that no demonstrated connection exists.

gimlet said...

They work, so why would they be removed? This just seems silly.

As load_map doesn't work...

I think you've demonstrated that there are cases where load_map() can fail to load a map made by save_map() (if it's stored in keyvalue pairs and one of the strings includes an equal sign, for example). I'd agree that load_map() is broken.

I don't think this means load_map() should be removed entirely, however. The binary serialization format still works, and even a save_map() generated keyvalue text file will work with load_map() with one simple change to save_map() (to tell save_map() to store strings containing an equal sign, or the double quote character, etc., as sequences instead of as quoted strings).

It's like load_map() works 70% of the time, which is "good enough". There is definitely room for improvement, however.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu