Joshua Hui
Pankaj Jain
Meikel Poess
Catherine Tornabene

March 12, 1996

> 
> 1)  Is CHAIMS to be a typed language?
>     If so, what sort of primitive data types should it support?
>     
>     We feel that CHAIMS should support three primitive data types -- 
>     number, string, and blob.  The original paper talks about dates but
>     we feel a date type can be pushed down to the megamodules, especially
>     if string and number are supported.
> 
>     The number type is a generic type that can be (in C terms) a float
>     or an integer.  
> 
>     Blob signifies everything else, particularily any complex type.
>     Handles to megamodules (the result of a setup call) are of type
>     blob, for example.


I think an untyped language seems to be neater for our purpose. Though I 
should mention that the choice between typed vs untyped is not very easy 
as each has its own advantages (ref my write up of BNF).

Also I don't see the need for any additional types like ints or strings 
or dates. Atleast in the first design. This may just make the language a 
bit untidy. Infact blob - which I shall call message from now on (as I 
feel it is more appropriate) can take care of all these. Anyway are we 
not assuming an arithmetic megamodule. So we don't need a special type 
for looping etc. I agree it will make the control structure a little 
wieldy syntactically but we can allow that in the first design. Note that 
there are two design goals - The Chaims language should be small and 
simple enough (just adequate for composition) and that the megaprogram 
should not be too long. The first one would directly affect the internal 
design so needs to be addressed first. The second one is more of question 
of interface to the language and can be improved once we have a basic 
system going by having another layer over the basic infrastructure. I 
believe that the i/o and arithmetic modules would be special modules 
finally for the sake of optimization and this issue can be dealt later.

> 
> 
> 
> 2)  How will data conversion between megamodules (via the CHAIMS program)
>     be handled?
> 
>   
>     This will not be visible to the CHAIMS program; this has been 
>     discussed in some detail in our meetings.  As far as the 
>     language itself is concerned there is not an issue since we 
>     all agree on this point (let us know if one of you disagree!).  
> 
>     This assumption raises some serious issues with regard to the
>     compiler and the structure of the megamodules.  (ie, how often
>     should megamodules expect to have to convert input parameters 
>     and how pervasive will runtime conversion libraries be). 

That depends on the structure of the message we decide upon.
> 
> 
> 3)  Do we allow for separation of input parameters?
> 
>     i.e.  (using Joshua's example syntax and the room reservation example)  
>            Do we allow:
> 
>            a) rrh.invoke ("Reserve", a, b, c);
> 
>            b) rrh.invoke ("Reserve", X);  where X is a blob containing a,
>               b and c
> 
>     The question is whether we allow a) or b) or both.  We are leaning
>     towards both, so that you can be allowed to do the first.  We think
>     it will be easier on the megaprogrammer when a, b, and c are 
>     simple types. 

Both are valid. The arguments to invoke just depends on the specs of the 
method in the repository.

> 
> 4)  Can the CHAIMS megaprogrammer hardcode a default value when making
>     a function call?  If he or she can't, then does this go down
>     to the level of another megamodule?  If so, how?
> 
>    
>     What we are thinking about is the following, using the same example
>     as above:
>     
>        rrh.setup ("Reserve", 10, "Bob")
> 
>        This will set the first argument (which the CHAIMS programmer knows
>        is the number of people by looking the repository) to 10 for
>        all subsequent rrh.invoke calls.  Same for the string, which is
>        the name of the person organizing the meeting.
> 
>     This seems like a reasonable thing to allow in the CHAIMS program,
>     but it could get complicated if the CHAIMS programmer wants to 
>     set a default value that is a complex type.  We weren't sure about it.
> 
> 
> 5)  We have discussed having all arithmetic operations pushed down to
>     the level of an Arithmetic megamodule in meetings, which you will 
>     probably remember.  
> 
>     If this is the case, are we essentially disallowing operators in the
>     CHAIMS language?  This could make any looping structure fairly
>     unwieldy.  However, if we allow arithmetic operations for looping
>     (ie, increment or compare), then can we disallow it in other
>     parts of the language?    
> 
> 
>     We think that we should have support for some basic arithmetic
>     operations in the CHAIMS language, because having to go to the level
>     of the megamodules for a simple operator seems too complex and will
>     make CHAIMS programs too awkward.  We do not think there is too much
>     of a risk of the CHAIMS programmer trying to use this simple arithmetic
>     support for complicated calculations within CHAIMS.

I guess I have soem explaination about this in 1)

> 
> 6)  Should there be a separate handle for different calls to the same 
>     megamodule?  Specifically, should there be a megamodule handler 
>     and a process handler?
> 
> 
>     We're not sure about this one.  We were thinking about this as a 
>     way of supporting asynchrony by essentially treating invoke as
>     a fork.  Of course, we haven't completely decided that asynchronous
>     execution is going to be our default.
> 
> 
>     So, example code would be:
> 
> 
>     ph = rrh.invoke ("Reserve");    // ph is a process handle
>        ....later.....               // rrh is the room res. megamodule handle
>     
>     if (ph.examine () = done)
>        rrh.extract (x) 
> 
> 
>     (This is assuming we still use extract to get a particular
>     value; we have discussed in our meetings eliminating this completely.
>     We are more concerned with the various handles here, in any case.)
> 

I think that examine should have another argument specifying the id of 
the call. Or it could be on the output variable. Also which fork are you 
refering to - the unix fork or the fork/join stuff. I feel strongly for 
message based system rather than fork/join complexities.


      
> 7)  What sort of control structures do we need?  
> 
>     The options are a while loop, a for loop, an if-then-else loop,
>     and/or a switch statement.
> 
>     We were leaning towards a while and an if-then-else since the others
>     can be subsumed by these two.

I think while is a good thing to keep. Choice between case and if may be 
decided arbitralily or by some other goal like ease of use, ease of 
implementation(!) or probably size of megaprogram.