🚀 go-pugleaf

In article <11491@ur-cc.UUCP> steve@bat.cc.rochester.edu (Steve Swales) writes:
>C-INTERCAL version 0.6 is now available by anonymous ftp
[rest deleted]

I got the compiler, but...

From "test1.i":

       DO ABSTAIN FROM (52)
       DO ABSTAIN FROM NEXTING		(this line added by me)
       DO REINSTATE (52)
(52)   DO (123) NEXT
       DO ERROR: LABEL REINSTATING NOT WORKING

According to the manual section on REINSTATE, statement (52) should
NOT be abstained from, but the C-INTERCAL 0.6 compiler gets this terribly
wrong. The error message is printed, while it should not be.

    REINSTATEment  nullifies  the  effects  of  an   abstention.
    Either  form  of  REINSTATEment  can  be  used  to  "free" a
    statement, regardless of whether the statement was abstained
    from  by  gerund  list,  line   label,   or   NOT.

Can something be done about this? And we only get comp.lang.misc
here, not alt.lang.intercal, btw.

It looks like some people have misread the manual (that is, interpreted
it differently than I did :-). Therefore, I'll quote a bit more and
give line-by-line comments on the example I supplied.

The manual says about ABSTAIN:
	 This statement takes on one of two forms.   It may  not
    take  on  both  at  any  one time.   DO ABSTAIN FROM (label)
    causes the statement whose logical line label is (label)  to
    be  abstained from.   PLEASE ABSTAIN FROM gerund list causes
    all statements of the  specified  type(s)  to  be  abstained
    from, as in [deleted]

As you can see, a STATEMENT can be abstained from, NOT an OPERATION
(as indicated by the gerund list). Therefore, ABSTAIN FROM gerund
is equivalent to ABSTAIN FROM (label) for each statement that
consists of the specified operation.

[The second sentence (It may not take on both at any one time)
is just humorous because one statement CAN be only one form at a
time, disallowing this is just funny. It cannot mean that you
can use only one of the forms in the entire program, because
such a drastic claim would have been more explicit, and is
inconsistent with the text on REINSTATE]

And this about REINSTATE:
    REINSTATEment  nullifies  the  effects  of  an   abstention.
    Either  form  of  REINSTATEment  can  be  used  to  "free" a
    statement, regardless of whether the statement was abstained
    from  by  gerund  list,  line   label,   or   NOT.

This confirms my "abbreviation" interpretation above.

Now the example again:
       DO ABSTAIN FROM (52)
This line is irrelevant here.. it abstains from (52).
       DO ABSTAIN FROM NEXTING		(this line added by me)
This abstains from all lines with NEXT.. here that is only (52).
       DO REINSTATE (52)
This reinstates (52) and therefore undoes the previous two
abstentions. Any other statements with NEXT are not affected.
(52)   DO (123) NEXT
This should now be executed normally.
       DO ERROR: LABEL REINSTATING NOT WORKING
and therefore control should not reach this statement.

Oh, look at me... I only got the manual a few days ago and now I am
already in a violent argument about its interpretation ;-)

In article <IISAKKIL.90Dec31071548@xaloc.tky.hut.fi>, iisakkil@xaloc.tky.hut.fi
(Mika R Iisakkila) writes:
> howell@grover.llnl.gov (Louis Howell) writes:
> > Yes, but WHY is this the expected behavior?  Statement (52) has just
> > been reinstated, so it should be executed, no?  All other NEXT statements
> > should still be abstained from, but not (52).
> 
> 	Well, now I think that I understood the point - I'm so
> embarrased. I promise to post some real source some day...

I believe you can be forgiven... after all, the author, as well as I,
the semi-official fully part-time lunatic-in-charge of maintenance,
failed to see this as well.

> 	BTW, was there any consensus about the proposed string
> handling extensions to intercal? I didn't have time to follow the
> news when this was discussed and the articles have already expired here.

No, and the discussion did not really go on very far. I am hoping that
there will be more interest in this topic, now that I have released
Version 0.6. How about it folks?

I'll try to post a summary of the discussion so far as soon as I get a
chance.

Also, I expect I will be posting an 'official patch' to correct this
latest problem (the ABSTAIN/REINSTATE problem) in the near future,
assuming a satisfactory solution can be found.

Oh, and speaking of patches... if any of you find there is a compiler
error due to 'linebuf', there is a spurious declaration in 'ick.h' that
can be removed. The line is:
	extern char linebuf[];

This did not cause a problem on the (BSD-ish) platform I use, but was
pointed out to me by someone with a System Vr3 platform (thanks again
Kevin!), where the compiler is a bit more picky about sloppy stuff
like this (no offense, Eric, this was MY error!)

-steve

-- 
-------------------------------------------------------+"Come, Watson, come!"
 Steve Swales                (716) 275-0265,-3857,-5101| he cried. "The game is
 steve@bat.lle.rochester.edu           (128.151.32.111)| afoot. Not a word!
 {decvax,harvard,ames,rutgers}!rochester!ur-laser!steve| Into your clothes and
 University of Rochester            250 East River Road| come!"		S.H.
 Laboratory for Laser Energetics    Rochester, NY 14623|     'The Abbey Grange'