Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
research:dsal:alert [2009/06/23 18:32] – jfabry | research:dsal:alert [2009/06/24 15:44] (current) – jfabry | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== Alert ===== | ||
+ | (Internal classification: | ||
+ | |||
+ | Reference paper: **" | ||
+ | |||
+ | A simplified version for the Tiny Imperative Language is also presented in **" | ||
+ | |||
+ | The DSAL06 workshop paper argues for DSAL construction where "the DSAL [is] a meta-program that is executed at compile-time, | ||
+ | |||
+ | ===== Domain of the language ===== | ||
+ | |||
+ | Alert alows for the separate specification of exception handling, both on the throwing side as on the catching side of the exception. | ||
+ | |||
+ | |||
+ | |||
+ | ===== Intent of the language ===== | ||
+ | |||
+ | "[...] failure | ||
+ | |||
+ | The DSAL proposed is a language extension that has been implemented for C (as well as proposed for C++ and Java). It allows for " | ||
+ | |||
+ | While it does address a cross-cutting concern in a separate way, it can be argued that this is not an aspect language but just a language extension. This as the separation is not as strict as with other languages. The aspect code still is declared within the source code of the base, and still can be tangled with the base. Nonetheless, | ||
+ | |||
+ | ===== Join Point Model and Advice Model ===== | ||
+ | * JPM: Domain-Specific : The throwing of an alert (= exception) by a function call in (a block of) statement(s) | ||
+ | * AM: General-Purpose with domain-specific extensions: The code of the exception handler is a (block of) statement(s) that may use extra keywords to retry the call that caused an exception or to provide a replacement value for that call. | ||
+ | |||
+ | ===== Anatomy of the language ===== | ||
+ | |||
+ | Alert consists of 3 parts: declaring new alerts, specifying alert reporting and alert handlers. The grammars for these 3 parts are detailed in the paper. | ||
+ | |||
+ | Alerts are declared using syntax of enum, extended with the possibility to specify multiple super-alerts. | ||
+ | |||
+ | alert {Retry, AskUser, FatalSys, FatalBug, UserMistake}; | ||
+ | alert {eNoEnt : AskUser }; | ||
+ | alert {eBadF, eIO} : FatalBug : UserMistake; | ||
+ | |||
+ | The first line declares a number of alerts, the second declares one alert as a sub-alert, the third declares two alerts with multiple common super-alerts. | ||
+ | |||
+ | "Alert reports are specified at the **callee** [emphasis added] side with an alert clause in the function declaration" | ||
+ | |||
+ | int insert(tbl t, key k, val v) | ||
+ | alert eNoMem post (value == -1 && errno = ENOMEM); | ||
+ | |||
+ | The pseudo-variable value in the conditional expression refers to the return value of the function call. "The condition expressions may be arbitrarily complex but should only use globally accessible names, arguments to the call and [the pseudo-variable] value." | ||
+ | |||
+ | Functions can be grouped into funspaces: sets of functions. Set membership can be defined by enumerating functions as well as using wildcards. The set union operator is also provided. Alert reporting can be specified on a funspace as well. | ||
+ | |||
+ | "There are two alert handling constructs: on, for specifying an alert handler at any scoping level, down to a single statement, and the handler operator <::, which specifies a handler for a single expression" | ||
+ | |||
+ | on NotFound in lookup() use "Doe, Jane"; | ||
+ | |||
+ | retry tries the call again, with an optional maximum retry count, and an optional list of parameters as arguments. | ||
+ | |||
+ | on NotFoundError in readFile(char * name) { | ||
+ | warn(" | ||
+ | char *name = askUser(); | ||
+ | if (name != null) retry(name) max 5; | ||
+ | warn(" | ||
+ | use ""; | ||
+ | |||
+ | The handler operator <:: allows alerts to be handled at the expression level, for example: | ||
+ | |||
+ | printf(" | ||
+ | |||
+ | In this code, the argument between : indicates which alerts must be handled, if empty all alerts are handled. | ||
+ | |||
+ | Lastly, alert also allows for named exception handlers which can be called from the handling constructs, as well as for alerts to be parametrized. We do not discuss these here and instead refer to the paper. | ||
+ | |||
+ | ===== Typical Example ===== | ||
+ | |||
+ | The reference paper does not provide a typical usage example beyond the examples used to explain the language. | ||
+ | |||
+ | ===== Enforced Restrictions ===== | ||
+ | |||
+ | The paper does not mention any restrictions on the statements in an alert handler or the conditions in an alert reporter. | ||
+ | |||
+ | ===== Implementation description ===== | ||
+ | |||
+ | Weaving is done through source code transformation (using StrategoXT), |