[M3devel] Areas that may need attention in the frontend?

[Jay K]

I think this isn't right. I understand the static link is implied by level > 0. But the activation/exception parameter should be always passed or never passed. Or there should be two functions -- one that takes an exception, one that doesn't, and one calls the other. Or pass it as null if there isn't an exception.
I should really not have to resort to K&R and passing varying numbers of parameters.
I still have to look at a few test cases to see when each parameter is used.Maybe I'm confused.
The other thing, you want the code to stay?
 - Jay


CC: jay.krell at cornell.edu; m3devel at elegosoft.com
From: jay.krell at cornell.edu
Subject: Re: [M3devel] Areas that may need attention in the frontend?
Date: Wed, 19 Sep 2012 21:33:43 -0700
To: hosking at cs.purdue.edu

Clarification: the "questioning comment" is not mine, it is there in the code. I suspect it is a good question & that the code isn't what it should be.

 - Jay (briefly/pocket-sized-computer-aka-phone)
On Sep 19, 2012, at 7:39 PM, Antony Hosking <hosking at cs.purdue.edu> wrote:

On Sep 19, 2012, at 9:31 PM, Jay K <jay.krell at cornell.edu> wrote:Areas that may need attention in the frontend?

TryFinStmt.m3:
      CG.Start_call_direct (p.handler.cg_proc, p.handler.level, CG.Type.Void);      (* Shouldn't we pass the activation parameter here?         What value do we pass? *)      CG.Call_direct (p.handler.cg_proc, CG.Type.Void);
The level let’s you compute that.
I'm wondering this too...like..what is the interfaceto except/finally blocks?
?
It appears they take two, or one, or zero parameters,depending on intepretation and context.

two parameters: _static_link exception stuff
 one parameter: _static_link 
zero parameters: the above

I think the right implmentation (assuming no significantchange to nested functions, which Tony is thinking about:) )is one parameter:
  exception stuff
and the implied/popped static_link, always.

For now, I think I'll not prototype these and use K&R definitions, yuck!
That works.
Maybe generating C++ with overloads is a good idea??


values/Procedure.m3:
    ELSIF (cur.token = TK.tSEMI) THEN      t.body := NEW (Body, self := t);      ProcBody.Push (t.body);      (* try accepting the Modula-2 syntax *)      Error.ID (id, "expecting \'=\' before procedure body");
 Probably everything after the error should be removed?Or this is an example trying to recover from parse errorsand doing best effort?
Yes.


 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120920/dcc2f2c3/attachment-0002.html>