Received: from ATHENA-AS-WELL.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA11599; Fri, 29 Jan 93 18:43:26 EST
Received: from CECI.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA24132; Fri, 29 Jan 93 18:43:23 EST
Message-Id: <9301292343.AA24132@Athena.MIT.EDU>
Received: from CECI.MIT.EDU by ceci.mit.edu id AA17103g; Fri, 29 Jan 93 18:43:29 EST
To: aybee@ceci.mit.edu
Date: Fri, 29 Jan 93 18:43:29 -0500
From: Adam Feder <aybee@ceci.mit.edu>


hi ---

my todo list looks somehthing like this (right now):

fix the grammar so that you can only declare arrays of base and compound types
and can only have initializor blocks for objects 
(if you can do both, i get a shift/reduce error...both the dimension spec and
 the initializor block start with '{'...if you want to leave ability to make
 arrays of objects...or initializor blocks for arrays, we need to choose new
 delimiters...(again)...maybe <> ? :) )

add the rule to recognize true reals (with exponents) to the lexer

move a copy of the grammar into frame (sans rules) and get people to comment
if they like (primarily you...) 

start specifying the type checking we will provide...what types does the  
system need to understand? how do the overloaded functions work?
what kind of errors can you expect from the parser? runtime?

then: 
requirements:
   variables              
   types
   dictionaries...method, class, variable...
   methods
   classes
 **** what must they be able to do?
   expressions?
 *** what errors can you expect? what might happen? how much semantic checking
     do we do? return types? ensure always return something?

design:
   classes and interfaces for 'em!

implement:
   better know as "code 'n pray"  (pray that first to steps caught most things!)


how does that sound?


(also, i will continue to think about networking and media and .....)


phew....
ab
