issue-#95 TextMapper Scanner & SETS

User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#95 TextMapper Scanner & SETS

Post by Robert »

Ivan Denisov wrote:Please, take a look at the changes...
I have done some more testing, and these changes give the same results as my suggestion. I tested the cases "{" & "}" which led to the surprising (to me) observation that line feeds are allowed within SETs. I am not saying this is a problem.

It was not obvious to me, looking at the source code, that your changes were equivalent. I assume that you have thought it through.
Ivan Denisov wrote:I changed the LOOP statement to WHILE...
Ok. Personally I think the LOOP is shorter, simpler, and more efficient than all the additional ELSE logic. I guess that computer scientists don't like LOOPs because they don't fit formal Proof-of-correctness reasoning. The way I think about certain classes of problem is more closely aligned to LOOPs with multiple EXITs, so for me this is a more natural construct for these problems. But we don't need to discuss this here.

Regards
Robert
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: TextMapper Scanner & SETS

Post by Josef Templ »

Robert wrote: The correction could consist of modifying the code to comply with the Docu, or modifying the Docu to explain the syntax that interpretSets does recognize.
I prefer the second option.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#95 TextMapper Scanner & SETS

Post by Robert »

Robert wrote:I think the LOOP is shorter, simpler, and more efficient than all the additional ELSE logic.
My (LOOP) version is 7 lines shorter than Ivan's.

His version produces 268 bytes less code.

Gosh!
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: issue-#95 TextMapper Scanner & SETS

Post by cfbsoftware »

LOOPs aren't the problem, single EXITs are maybe OK, it is when you have multiple EXITs that they can become a maintenance nightmare. In the past I have used LOOPs when I'm feeling lazy and don't want to have to think too hard about the problem I am trying to solve. I usually regret it 6 months later when I have to revisit the code ...
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: TextMapper Scanner & SETS

Post by Robert »

Josef Templ wrote:
Robert wrote:The correction could consist of modifying the code to comply with the Docu, or modifying the Docu to explain the syntax that interpretSets does recognize.
I prefer the second option.
Just add the following line to the text for "CONST interpretSets":

Code: Select all

Note: The scanner is not strict about the set syntax; for example both "{2, 3 6}" & "{2, 3, 6,}" are interpreted as "{2, 3, 6}".
I still prefer the first option.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#95 TextMapper Scanner & SETS

Post by Josef Templ »

cfbsoftware wrote:LOOPs aren't the problem, single EXITs are maybe OK, it is when you have multiple EXITs that they can become a maintenance nightmare. In the past I have used LOOPs when I'm feeling lazy and don't want to have to think too hard about the problem I am trying to solve. I usually regret it 6 months later when I have to revisit the code ...
In this particular example the main problem is the state machine.
For a hand written parser it is never a good idea to use a state machine.
Please have a look at the compiler or at Strings to see how to do it without a state machine.

(I still prefer the second option;-)

- Josef
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: issue-#95 TextMapper Scanner & SETS

Post by cfbsoftware »

Josef Templ wrote:In this particular example the main problem is the state machine.
For a hand written parser it is never a good idea to use a state machine.
I'd agree 100% on that. Here, also it is the error detection which exacerbates the issue. The simple StrToSet procedure that you see in typical Oberon Strings modules doesn't do any error detection and is much easier to follow.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#95 TextMapper Scanner & SETS

Post by Robert »

cfbsoftware wrote:
Josef Templ wrote:In this particular example the main problem is the state machine.
For a hand written parser it is never a good idea to use a state machine.
I'd agree 100% on that. Here, also it is the error detection which exacerbates the issue. The simple StrToSet procedure that you see in typical Oberon Strings modules doesn't do any error detection and is much easier to follow.
Chris, thanks for that!
I originally described this solution as "inelegant", so having you guys agree after several months is hardly a big step forward.
What would be progress is if more people took sides on whether having error detection is desirable. If the majority prefer having a scanner that doesn't know how to recognise a properly formed SET we don't need to worry about how to write an elegant one.

Privately I was hoping that someone with a computer science background (or interest) would show how it should be done; this kind of parsing has to be standard fare.
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: issue-#95 TextMapper Scanner & SETS

Post by cfbsoftware »

This task is done a lot more elegantly in the compiler. However, the set processing part of the compiler relies on much of the rest of the infrastructure / error handling of the scanner / parser. What you have here is a simplified version. Error handling in String processing modules is always a tricky issue. e.g. if copying a large string to a smaller string do you terminate? warn? silently truncate?
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#95 TextMapper Scanner & SETS

Post by Ivan Denisov »

We have some time to think about reducing state machine in parser. And then will vote about having a fix of the parser or the documentation.
Post Reply