From dougo@ccs.neu.edu Tue Dec  3 23:47:16 1996
Received: from nowhere (cream-of-wheat.ccs.neu.edu [129.10.112.49])
	by amber.ccs.neu.edu (8.8.3/8.7.3) with SMTP id XAA24774; Tue, 3 Dec 1996 23:46:24 -0500 (EST)
Date: Tue, 3 Dec 1996 23:46:24 -0500 (EST)
Message-Id: <199612040446.XAA24774@amber.ccs.neu.edu>
Received: by nowhere (SMI-8.6/SMI-SVR4)
	id XAA00325; Tue, 3 Dec 1996 23:43:37 -0500
From: Doug Orleans <dougo@ccs.neu.edu>
To: "Andrew Miller" <amiller@xis.xerox.com>,
        Karl Lieberherr <lieber@ccs.neu.edu>
Cc: cdickins@ccs.neu.edu, com3360@ccs.neu.edu, com1205@ccs.neu.edu
Subject: Re: Jack Question
In-Reply-To: <9611038496.AA849662078@xis.xerox.com>
References: <199612032239.RAA05394@stockberg.ccs.neu.edu>
	<9611038496.AA849662078@xis.xerox.com>
X-Face: ,HWj@r1~8onbE_1x>uxU@3+pdQ>wXW.a:'$Q/`^aA0sh}!JxD8ueZ7vTwvvl]y*Ai9]`Wqd
 ^o[-r'u!3,@i>wCa

Andrew Miller writes:
 >      In my CD, I reference several Java classes (Stack, Vector).  Jack 
 >      complains about these "non-terminal"s not being defined.  How can I 
 >      tell Jack that these are external terminals ?

This is a bug in demjava.  There are two workarounds:

    1. Make new classes that inherit from the external classes:

	Foo = <s> MyStack <v> MyVector.
	MyStack = *extends* Stack.
	MyVector = *extends* Vector.

    Unfortunately this causes a different error message if the
    external class has no empty constructor (e.g. PrintStream).

    2. Take the external class out of the CD file altogether, and
       provide your own part & method definitions in the behavior
       file:

	Foo {
	  (@
	    private Stack s;
	    public Stack get_s() { return s; }
	    public void set_s(Stack _s) { s = _s; }
	    private Vector v;
	    public Vector get_v() { return v; }
	    public void set_v(Vector _v) { v = _v; }
	  @)
	}

Sorry for the inconvenience.  Let me know if neither of these answers
work for you.

--Doug

From dougo@ccs.neu.edu Wed Dec  4 11:40:40 1996
Received: from nowhere (lucky-charms.ccs.neu.edu [129.10.112.37])
	by amber.ccs.neu.edu (8.8.3/8.7.3) with SMTP id LAA01581; Wed, 4 Dec 1996 11:40:37 -0500 (EST)
Date: Wed, 4 Dec 1996 11:40:37 -0500 (EST)
Message-Id: <199612041640.LAA01581@amber.ccs.neu.edu>
Received: by nowhere (SMI-8.6/SMI-SVR4)
	id LAA00356; Wed, 4 Dec 1996 11:37:52 -0500
From: Doug Orleans <dougo@ccs.neu.edu>
To: Karl Lieberherr <lieber@ccs.neu.edu>
Cc: uml-text@ccs.neu.edu, dougo@ccs.neu.edu
Subject: Re: input not used up
In-Reply-To: <199612041414.JAA08323@stockberg.ccs.neu.edu>
References: <199612041414.JAA08323@stockberg.ccs.neu.edu>
X-Face: ,HWj@r1~8onbE_1x>uxU@3+pdQ>wXW.a:'$Q/`^aA0sh}!JxD8ueZ7vTwvvl]y*Ai9]`Wqd
 ^o[-r'u!3,@i>wCa

Karl Lieberherr writes:
 > Hi Doug:
 > 
 > I was about to send the message below. I could not see what is wrong
 > since I expected the parser to complain if the input
 > is not used up. This seems not to be the case with the current
 > implementation. Can Jack tell us when the input is not used up.

If there's an <EOF> token at the end of a rule, it will give a parse
error if the input isn't fully consumed.  The question is, which rules
should get the <EOF> token?  I guess it's a safe bet that the first
rule should have an <EOF> at the end.  Or maybe the user should be
able to specify *eof* in the CD file...

Is this important enough for me to add now?  Or should I wait for the
end of the quarter?

--Doug

P.S. As a workaround, you could check the stream manually whenever you
call parse():

    Program p = Program.parse(System.in);
    if (System.in.read() != -1) {   // -1 means end of stream
	throw new ParseError();
    }