[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