[tex-k] Is there a way to find the error line?
helbig at mailbox.org
Mon Mar 22 13:14:01 CET 2021
> thank you very much for your advice. I think the problem came form the
> fact that some WEB units
> are procedures (and therefore need a semicolon at the end) and others
> are just code fragments
> that TANGLE will place at a location where semicolon is not allowed.
The code fragments in a WEB never end with semicolon. But at the places
where they are used, Knuth always writes a semicolon even if not needed,
i. e. before 'end'. Tangle is not an excuse. But Weave is, because the
empty statement changes dramatically the formatting.
> BTW a question: when adding features to existing TeX engines is it
> better to break the changes
> into many WEB units, so that their documentation is easier to follow
> or to keep the existing WEB
> units so that people can refer to them by using stable unit numbers?
I'd use stable unit numbers.
> For example, if I modify substantially §1015 which is the \patterns
> scanner, shall I rather break my
> modifications into new units and call them inside §1015, or keep a
> long §1015 so that what was
> previously §1016 keeps the same identifier?
I'd suggest to change module 1015. In TeX-FPC I put new staff in the
last part, System Changes, a procedure to load the editor for error
recovery, a code fragment to install an interrupt handler, and the
interrupt handler, which is a procedure. BTW, TeX-FPC contains a
>> Le 22 mars 2021 à 11:28, Wolfgang Helbig <helbig at mailbox.org
>> <mailto:helbig at mailbox.org>> a écrit :
>> Dear Yannis,
>> in Pascal, the semicolon seperates two statements, whereas in ALGOL
>> and C, the semicolon terminates a statement.
>> Or in Pascal, the semicolon is never part of a statement and in C it
>> is always is part of a statement.
>> In Pascal, the empty string is a statement, called "empty statement".
>> It does nothing.
>> So in parts of the program, where the syntax rules allow one or more
>> statements, you can always put the semicolon without changing the
>> meaning of the program.
>> But there are places, where only one statement is accepted, notably
>> the 'then' part of an if statement: A semicolon after the statement
>> in the 'then'-part ends the 'if'-statement, which is followed by the
>> empty statement. If your if-statement does have an else part, an
>> 'else' is following the empty statement. But 'else' may only follow
>> the 'then' part of the 'if'-statement, not the if-statement as a whole.
>> Unfortunately, some people misuse the empty statement and feel
>> licensed to terminate every statement with a semicolon -- A confusing
>> step backward in the evolution of ALGOL-like languages. A step
>> forward of course is Dijkstra's Guarded Commands notation. In fact,
>> the empty statement is the very first statement in Dijkstra: "A
>> Discipline of Programming", 1976, p. 25. and in Jensen, Wirth:
>> "Pascal User Manual and Report", 3rd ed. 1985, p. 169.
>> Alas, compilers are rare for dot.not, as I prefer to call Dijkstra's
>> notation. You recognize by its dots in the notation for arrays.
>>> dear Karl,
>>> thanks for your answer. I finally found the error, it was an
>>> unnecessary semicolon after an "end".
>>> I have a hard time finding the precise rules: when are semicolons
>>> after "end" necessary / optional / forbidden?
>>> (The only thing I know for sure is that the semicolon is forbidden
>>> when we are in an if-test
>>> and an "else" is following:
>>> if xxx begin xxx end else begin xxx end; <--- no semicolon between
>>> "end" and "else"
>>> but beside that I couldn't find precise information and TeX's Pascal
>>> code is either not very consistent
>>> with respect to semicolons or maybe it follows some pattern that I
>>> wasn't able to find out yet…)
>>> Thanks again for your help,
>>>> Le 21 mars 2021 à 02:57, Karl Berry <karl at freefriends.org
>>>> <mailto:karl at freefriends.org>> a écrit :
>>>> Is there a way to localize the error?
>>>> For the record, this is the brief reply I sent to when Yannis asked me
>>>> separately. It's all I have. Web2c is a lousy development environment,
>>>> no question.
>>>> Date: Fri, 19 Mar 2021 11:19:09 -0700
>>>> From: Karl Berry <karl at freefriends.org <mailto:karl at freefriends.org>>
>>>> To: yannis1962 at gmail.com <mailto:yannis1962 at gmail.com>
>>>> Subject: Re: Debugging
>>>> In-Reply-To: <466F362F-4E43-4655-B0FC-2710ABD215AD at gmail.com
>>>> <mailto:466F362F-4E43-4655-B0FC-2710ABD215AD at gmail.com>>
>>>> Can you tell me how to localize the error?
>>>> There is no good way. Just have to go back to the original, make
>>>> sure it
>>>> works, and add individual lines until you find the error, which
>>>> apparently has something to do with "true" and a semicolon.
>>>> Sometimes the .c file(s) left in (in your case)
>>>> as given by the error msg provide a clue. [...]
>>> IMT Atlantique <http://www.imt-atlantique.fr/>
>>> *Yannis HARALAMBOUS*
>>> Computer Science Department
>>> UMR CNRS 6285 Lab-STICC
>>> Site web IMT Atlantique
>>> <http://perso.telecom-bretagne.eu/yannisharalambous/>Twitter IMT
>>> Atlantique <https://twitter.com/y_haralambous>LinkedIn IMT
>>> Technopôle Brest-Iroise CS 83818
>>> 29238 Brest Cedex 3, France
>>> Une école del'IMT <http://www.imt.fr/>
>>> /Any sufficiently advanced bug is indistinguishable from a
>>> feature./ (Rich Kulawiec)
>> Wolfgang Helbig
>> Stauferstr. 22
>> 71334 Waiblingen
>> 07151-920 227
> IMT Atlantique <http://www.imt-atlantique.fr>
> *Yannis HARALAMBOUS*
> Computer Science Department
> UMR CNRS 6285 Lab-STICC
> Site web IMT Atlantique
> <http://perso.telecom-bretagne.eu/yannisharalambous/>Twitter IMT
> Atlantique <https://twitter.com/y_haralambous>LinkedIn IMT Atlantique
> Technopôle Brest-Iroise CS 83818
> 29238 Brest Cedex 3, France
> Une école del'IMT <http://www.imt.fr>
> /Le lecteur a le droit et même parfois le devoir de savoir en quels
> est composé le livre qu'il a entre les mains, et on ne peut exiger de lui
> qu'il sache le reconnaître tout seul./ (Gérard Genette)
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4 bytes
Desc: not available
More information about the tex-k