[kepler-dev] Generating simple actor documentation using Javadoc

Edward A Lee eal at eecs.berkeley.edu
Wed Aug 11 05:46:13 PDT 2004


I think a reasonable way to start down the path of having a declarative
way to give such type constraints would be to "pretty print" the type
constraints that are already there...  Right now, if you get a type
error, it's a mind-bending slog to read the error message an figure
out what is going on...  I think we could render the type information
much more nicely, and then, if we do it right, create a round-trip,
so that the pretty-printed syntax can also be used to create the
type constraints in the first place...

Edward


At 03:47 PM 8/10/2004 -0700, Stephen Andrew Neuendorffer wrote:

>>btw: in terms of inferred vs. declared, there is one point though, now
>>that I think about it:
>>
>>A noticed that several PT actors have a type e.g., of the form
>>         actorX :: {unknown} -> unknown                     (1)
>
>They don't have this type...  They should implement the correct type 
>constraints
>for {alpha} -> alpha... I agree it is awkward that such constraints are 
>specified in a
>different way, but they must declare it.  I have long wanted a more 
>declarative way
>of specifying such things: essentially expression language syntax for type 
>constraints.
>Note that quite alot of information is specified operationally in actors,
>rather than declaratively.  E.g. type constraints.  Choices added through 
>the addChoice
>mechanism.  Default parameter values.  Reactions to changed attributes.
>Such mechanisms are simple to build in the short term, but really bog down in
>the long term...

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal




More information about the Kepler-dev mailing list