Standards

From Rosetta
Jump to: navigation, search

The Rosetta language and semantics standardization is overseen by the IEEE DASC P1699 Rosetta Working Group. There are three major elements of the standardization effort. The Language Standard defines the base language for defining expressions, facets, domains, interactions and packages. It also includes reflection packages used to represent and manipulate Rosetta abstract syntax when defining domains and interactions. The Domains Standard defines the base collection of semantic domains for Rosetta modeling. Finally, the Tool Flow Standard will define how integration points for Rosetta tool implementation. The current standards effort involves the first two elements. The final element will be developed as toolification becomes more active.


Base Language

The Base Language Standard is the definition of the Rosetta language, its semantics, a collection of domains that must be provided by any Rosetta implementation, and the reflection packages. The draft standard documents and code files are maintained by the Working Group's Technical Editor on the LRM Subcommittee web page.


The Reflection Packages are a special part of the base Rosetta language standard that define reflection capabilities. Reflection is a critical component of Rosetta's domain and interaction system. The Reflection Packages define a collection of functions and types that must be supported by a Rosetta tool environment providing reflective capabilities. It is anticipated that not every Rosetta tool will implement the entire reflection subsystem, thus the reflection package is defined separately. If you have downloaded both the Rosetta standard documents and support libraries above, there is no need to download the support libraries separately. You already have the reflection packages.

Updated: Alex 18:15, 10 January 2008 (CST)

Domains

The Domains Standard is a collection of standard domains that may be supported by a Rosetta installation. It is anticipated that many tools will not implement the entire Rosetta domain collection, thus they are defined individually as a part of a domain lattice. Thus, implementers are free to implement an appropriate subset confident that all other implementations of that subset will be consistent.

Updated: Alex 15:54, 22 May 2007 (CDT)


Tool Flow

Tool Flow standard describes methods for implementing Rosetta methodology in practice. The

Updated: Alex 15:58, 22 May 2007 (CDT)


P1699 Rosetta Working Group

The Rosetta Working Group was established by IEEE-SA under the Design Automation Standards Committee to develop a standard LRM and semantics for Rosetta and its base domain set. This section contains details of how the committee operates, meeting schedules and minutes, and membership. P1699 Working Group membership is open as are all IEEE standards activities. Please contact the working group chair for access to the wiki.

To Do List

Following is the current to do list of assigned issues related to the standard document.

  • Define new syntax for function type using classical "->" notation - Nick Frisby
  • Look through Ben's LRM comments
  • Look at supporting spaces in bit/hex stream syntax (Bug 506)
  • Look at a syntax for labeled parameter instantiation in facet interface instantiation (Bug 507)
  • Explore syntax for facet instantiation that includes interactions (done)
  • Look at the syntax for anonymous facets - Perry Alexander - working (Bug 345) (Note that anonymous facet may be different than facet value.)
  • Look at facet signatures (use facet interface) (Bug 496)
  • Define component semantics - Megan Peck - working (Bug 508)
  • Redefine facet semantics as restricted component semantics - Megan Peck - working (Bug 508)
  • Determine if behavioral (boolean) terms should have labels allowing syntactic recognition of facet expressions - Ben Tyler - completed. Boolean terms will remain the same with labels as optional constructs. Look for other ways to distinguish facet type expressions from behavioral terms. (Bug 490 is still open)
  • Update definition of facets to specify them as object-like structures that are instantiated - Peter Ashenden - pending agreement (Bug 509)
  • Explore redefining the base types using algebraic datatypes - unassigned, to be explored later
  • Define elaboration of interactions to packages - Ben Tyler - complete
  • Define elaboration of facet terms to declarations - Perry Alexander - working -(Bug 510)
  • Freshen wiki pages including specifications - pending other work
  • Write up instantiate, include, and use definitions - Perry Alexander - done, but move to a central spot
  • Bug 253 - Assigned to Perry Alexander - proposal posted
  • Bug 433 - Assigned to Perry Alexander - proposal posted as a part of Bug 253
  • Bug 460 - Assigned to Peter Ashenden - working
  • Bug 465 - Assigned to Peter Ashenden - waiting on Bug 253
  • Bug 136 - Assigned to Peter Ashenden - working
  • Bug 85 - Assigned to Ben Tyler - working
  • Bug 374 - Assigned to Peter Ashenden - working
  • Bug 486 - Assigned to David Barton - working
  • Type Schema white paper - Peter Ashenden - obsolete
  • Pattern Matching white paper - Peter Ashenden - compete
  • Interactions white paper - Perry Alexander - complete
  • Justifications white paper - David Barton - pending

Updated: Alex 23:43, 9 August 2010 (CDT)

Issues and Proposals

We use Bugzilla to track ongoing language issues and specific proposals. If you wish to participate in discussions, please contact User:Alex for access. Please note that Bugzilla is a "push" technology. If you wish to participate in the discussion of a particular issue and want to know when updates are made, you must register your email on the carbon copy list for that specific issue. Please make a habit of checking the server periodically for new issues. Also, please review the way in which we use the Bugzilla status and resolution fields to track issues.

There are also white papers discussing proposals for new and revised language features:

  • Pattern Matching, by Peter Ashenden. Proposes a pattern-matching form of case expression, as well as simplification of if expressions and let expression to case expressions. Comments on Pattern Matching contains some assessments and suggested corrections for the proposal.
  • Interactions, by Perry Alexander. Proposes a packaging definition that defines components of an interaction between two domains. Updated to 2008 version to continue discussions. Note the that the discussion of the sharing clause has been subsumed by later discussions. This chapter should be ignored in the interactions document. Updated 10/9/08.
  • Domain Discussion, maintained by Perry Alexander for discussing issues related to domains, elaboration and interactions. I have copied the discussion from April 28 to the discussion page associated with Domain Discussion so we can continue there.
  • Facet Instantiation, maintained by Perry Alexander for discussing issues related to facet instantiation.
  • Radio Specifications is a collection of Software Defined Radio specifications included as an example
  • Coordination and Sequencing is a proposal for coordination events and sequencing (Deprecated)
  • Sequencing is a proposal for sequencing events to replace the previous proposal. (Under Construction)
  • Share Clause is a proposal for a new construct similar to export clauses that will allow item instances declared in a domain to be shared among different instances of the domain (similar to static members in Java)
  • Rosetta FAQ, a list of common questions (and their answers) that someone who is unfamiliar with the language may ask
  • Algebraic Types is a preliminary discussion on the type algebra and about what types are constructed types
  • Default Combinator Discussion discusses the results of applying the default combinators + and *
  • Attributes Attached to Declarations is a proposal for allowing atributes to be included as part of a declaration.
  • Export None is a proposal for adding the none keyword to complement the all keyword in export lists.
  • Anonymous Tuples is a proposal for adding support for anonymous tuples to rosetta.

Policies and Procedures

We follow the policies and procedures developed and approved by the IEEE-SA DASC. We are in the process of reviewing them and will post policies specific to this working group here. Please stay tuned for further details.

Policies and Procedures

Meeting Notes and Agendas

Minutes of our regular meetings and agendas for upcoming meetings will be posted here along with attendance records. Note that a star indicates that issues discussed in the meeting have been transferred to the bugzilla database.

The '*' annotation indicates that meeting notes have been reviewed and items for the bugzilla issue-base extracted and added.

Draft Standard Updates

Below are links to text that has been proposed as an official addition to the standard:

Officers and Members

Officers:

  • Chair: Perry Alexander, Cadstone Inc / The University of Kansas
  • Vice-Chair: Ben Tyler, EDAptive Computing, Inc
  • Secretary: Joanne DeGroat, Ohio State University

LRM Subcommittee:

Perry Alexander, Peter Ashenden, David Barton, Garrin Kimmell, Ben Tyler

Membership details will be posted here.

Updated: Alex 15:31, 05 February 2010 (CST)

Retrieved from "https://wiki.ittc.ku.edu/rosetta_wiki/index.php?title=Standards&oldid=2669"