Putting Declarative Programming Into The Web: Translating Curry To Javascript
Putting Declarative Programming Into The Web: Translating Curry To Javascript
Abstract 1. Motivation
We propose a framework to construct web-oriented user interfaces The implementation of software systems can be coarsely classified
in a high-level way by exploiting declarative programming tech- into two parts: the implementation of the application logic and the
niques. Such user interfaces are intended to manipulate complex implementation of the user interface. If one uses declarative pro-
data in a type-safe way, i.e., it is ensured that only type-correct gramming languages, the first part can be implemented with rea-
data is accepted by the interface, where types can be specified by sonable efforts (in particular, if one uses libraries with appropri-
standard types of a programming language as well as any com- ate interfaces, see, for instance, [10, 12, 18] for database program-
putable predicate on the data. The interfaces are web-based, i.e., ming). In contrast, the construction of the user interface is usually
the data can be manipulated with standard web browsers without complex and tedious. In order to simplify the latter task, scripting
any specific requirements on the client side. However, if the client’s languages with toolkits and libraries, like Tcl/Tk, Perl, or PHP, are
browser has JavaScript enabled, one could also check the correct- one approach to support this goal. Since scripting languages of-
ness of the data on the client side providing immediate feedback ten lack support for the development of complex and reliable soft-
to the user. In order to release the application programmer from ware systems (e.g., no static type and interface checking, limited
the tedious details to interact with JavaScript, we propose an ap- code reuse due to the lack of high-level abstractions), they are of-
proach where the programmer must only provide a declarative de- ten used to implement the user interface whereas the application
scription of the requirements of the user interface from which the logic is implemented in some other language. This approach cre-
necessary JavaScript programs and HTML forms are automatically ates new problems since it is well known that such combinations
generated. This approach leads to a very concise and maintainable could cause security leaks in web applications [25]. Therefore, an
implementation of web-based user interfaces. We demonstrate an alternative solution is the embedding of such domain-specific lan-
implementation of this concept in the declarative multi-paradigm guages in high-level languages able to provide appropriate abstrac-
language Curry where the integrated functional and logic features tions (e.g., see [9, 17, 29, 32, 34, 35] for functional and logic lan-
are exploited to enable the high level of abstraction proposed in this guages). This paper follows the latter alternative and considers an
paper. approach to construct web user interfaces (WUIs) in a declarative
way. The core idea of the declarative construction of WUIs has
Categories and Subject Descriptors D.1.1 [Programming Tech- been presented in [21]. In this paper we combine this construction
niques]: Applicative (Functional) Programming; D.2.2 [Software with the existing features of scripting languages by compiling parts
Engineering]: Design Tools and Techniques—User interfaces; of the declarative interface specifications into a scripting language
D.3.2 [Programming Languages]: Language Classifications— available in almost all web browsers: JavaScript.
Multiparadigm languages; D.3.3 [Programming Languages]:
Language Constructs and Features—Polymorphism; D.3.4 [Pro- In order to provide an example of the new approach presented in
gramming Techniques]: Processors—Compilers; H.5.2 [Informa- this paper, we give a short summary of the framework to construct
tion Interfaces and Presentation]: User Interfaces WUIs presented in [21]. This approach to construct WUIs is useful
in situations where data of an application program should be ma-
General Terms Languages nipulated via standard web browsers (i.e., by HTML forms). The
application program supplies the WUI with the current data of the
Keywords Functional Logic Programming, User Interfaces, Web application and an operation to store the modified data. Further-
Programming, Curry, JavaScript more (and most important), it provides a type-oriented specifica-
tion of the WUI structure that matches the type of the application
data. For this purpose, the WUI framework contains a set of ba-
∗ Thiswork was partially supported by the German Research Council sic WUIs to manipulate data of basic types, e.g., integers, truth
(DFG) grant Ha 2457/5-2. values, strings, finite sets, and a set of WUI combinators to con-
struct WUIs for complex data types from simpler types similarly
to type constructors in programming languages. For instance, there
are combinators for tuples, lists, union types etc. The framework
ensures that the user inputs only type-correct data, i.e., if the user
Permission to make digital or hard copies of all or part of this work for personal or tries to input illegal data (e.g., incorrect integer constants, empty
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
strings, wrong dates or email addresses), the WUI does not accept
on the first page. To copy otherwise, to republish, to post on servers or to redistribute the data and asks the user to correct the input. Figure 1 shows an
to lists, requires prior specific permission and/or a fee. example of a WUI for a list of persons containing various input er-
PPDP’07 July 14–16, 2007, Wroclaw, Poland. rors. Note that errors can occur not only in individual input fields
Copyright
c 2007 ACM 978-1-59593-769-8/07/0007. . . $5.00 but also as illegal combinations of different fields, like the date in
Figure 1. A WUI for a list of persons containing various input errors
the second row. Thanks to this feature of the WUI framework, the to the principle in web programming that one should never trust
application program need not check the input data and perform ap- user inputs from web browsers even if they are checked by scripts
propriate actions (e.g., providing error forms to correct the input on the client side, since one never knows whether the input comes
etc). This considerably simplifies the task of programming the user from a human using a web browser or another malicious program
interface. [25]). Thus, one is free to select only particular conditions that are
easy to translate into JavaScript. This is the idea used in the follow-
We have already mentioned that type-correct inputs have to be un- ing in order to get a reasonable and practically applicable combina-
derstood in a much broader sense than types used in programming tion of two different worlds of programming.
languages. For instance, strings containing email addresses must
have a particular form, a date like “February 29, 2006” is illegal, In the next section, we review the concepts of Curry, HTML pro-
and two input fields containing a password and the repeated pass- gramming, and JavaScript that are necessary to understand the con-
word must be always identical. Therefore, WUIs can be specified tents of this paper. Section 3 reviews the ideas of WUIs. The basic
together with any computable predicate so that input data is only ideas behind the combination of WUIs and JavaScript are described
accepted if it satisfies the specified predicate. Furthermore, WUIs in Section 4 before the translation of Curry into JavaScript is de-
can be customized in various ways, e.g., to provide application- fined in Section 5. Section 6 introduces some important optimiza-
specific error messages in case of illegal inputs, to use a specific tions. Section 7 describes the current implementation. Section 8
rendering or embed them in web pages with a specific layout, and discusses related work before we conclude in Section 9.
can be easily adapted to user-defined types (see [21] for details).
In order to provide a compact and high-level interface for the WUI 2. Basics: Curry, HTML, JavaScript
construction, a concrete implementation has been performed with
the declarative multi-paradigm language Curry [16, 24]. Various 2.1 Functional Logic Programming
features of Curry, like the treatment of functions as first-order ob- Functional logic languages [15] integrate important features of
jects, logic variables, and strong typing are exploited in this imple- functional and logic languages in order to provide a variety of pro-
mentation, although not all of them are required to be used by the gramming concepts. Modern languages of this kind [16, 24, 28]
programmer constructing WUIs. In particular, logic variables are combine the concepts of demand-driven evaluation and higher-
used as internal references to input fields which are not visible to order functions from functional programming with logic program-
the programmer. ming features like computing with partial information (logic vari-
ables), unification, and nondeterministic search for solutions. This
In this paper we show how to exploit the existence of JavaScript
combination, supported by optimal evaluation strategies [4] and
interpreters in web browsers in order to increase the functionality
new design patterns [5], leads to better abstractions in application
of WUIs. By translating conditions in WUIs into JavaScript pro-
programs, e.g., as shown for programming with databases [12, 18]
grams, one can check user inputs on the client side, i.e., forms with
or dynamic web pages [17, 21]. The declarative multi-paradigm
illegal inputs are not sent to the web server. This feature reduces
Curry [16, 24] is a functional logic language extended by concur-
the number of client/server interactions and provides instantaneous
rent programming concepts and has been used in various applica-
feedback on incorrect inputs on the client side. However, Curry
tions. In the following, we review the elements of Curry relevant for
is a powerful language with advanced programming features (e.g.,
this paper but omit other features not used here (e.g., constraints,
higher-order functions, laziness, logic variables, constraint solving,
search strategies, concurrency, I/O concept, modules). More details
concurrency). Thus, it is not reasonable to translate into JavaScript
about Curry’s computation model and a complete description of all
all possible conditions that can be implemented in Curry, since this
language features can be found in [16, 24].
might finally require to communicate a complete Curry implemen-
tation to the web client. This is not only inefficient (since JavaScript From a syntactic point of view, a Curry program is a functional pro-
is usually interpreted) or impossible (due to space and time limita- gram extended by the possible inclusion of free (logic) variables
tions of the JavaScript interpreter) but also not necessary: the cor- in conditions and right-hand sides of defining rules. Curry has a
rectness of the user input is always checked on the server side (due Haskell-like syntax [30], i.e., (type) variables and function names
usually start with lowercase letters and the names of type and data 2.2 HTML Programming
constructors start with an uppercase letter. The application of f to
Writing programs that generate HTML documents requires a deci-
e is denoted by juxtaposition (“f e”). A Curry program consists
sion about the representation of HTML documents. A textual rep-
of the definition of functions and data types on which the func-
resentation (as often used in CGI scripts written in Perl or with
tions operate. Functions are first-order citizens as in Haskell and
the Unix shell) is very poor since it does not avoid certain syntac-
are evaluated lazily. To provide the full power of logic program-
tical errors (e.g., unbalanced parenthesis) in the generated docu-
ming, functions can be called with partially instantiated arguments
ment. Thus, it is better to introduce an abstraction layer and model
and defined by conditional equations with constraints in the condi-
HTML documents as elements of a specific data type together with
tions. Function calls with free variables are evaluated by a possibly
a wrapper function that is responsible for the correct textual repre-
nondeterministic instantiation of demanded arguments (i.e., argu-
sentation of this data type. Since HTML documents have a tree-like
ments whose values are necessary to decide the applicability of a
structure, they can be represented in functional or logic languages
rule) to the required values in order to apply a rule.
in a straightforward way [9, 17, 29, 34]. For instance, the type of
In general, functions are defined by (conditional) rules of the form HTML expressions is defined in Curry as follows:2
“f t1 . . . tn | c = e” with f being a function, t1 , . . . , tn patterns data HtmlExp =
(i.e., expressions without defined functions) without multiple oc- HtmlText String
currences of a variable, the (optional) condition c is a constraint | HtmlStruct String [(String,String)] [HtmlExp]
(e.g., a conjunction of equations), and e is a well-formed expres-
sion which may also contain function calls, lambda abstractions Thus, an HTML expression is either a plain string or a struc-
etc. A conditional rule can be applied if its left-hand side matches ture consisting of a tag (e.g., b,em,h1,h2,. . . ), a list of attributes
the current call and its condition is satisfiable. (name/value pairs), and a list of HTML expressions contained in
this structure. Thus, the HTML code
E XAMPLE 2.1. The following Curry program defines the data <p>This is an <i>example</i></p>
types of Boolean values and polymorphic lists, and functions to
compute the concatenation of lists and the last element of a list: is represented by the data term
Programs of this intermediate language, also called flat programs, A function definition f (x1 , . . . , xn ) = e is translated into the
can be defined as follows, where we write on for the sequence of following JavaScript function declaration:
objects o1 , . . . , on :6
function f (x1 ,...,xn ) {
Program var r;
P ::= D1 . . . Dm [[r ← e]];
Definition return r;
D ::= f (x1 , . . . , xn ) = e }
6 We have simplified the flat language due to our requirement for eager- Using our translation scheme, the predicate posSum is translated
executable functions. into the following JavaScript code:
function posSum(x1) { function posSum(x1) {
var x2; var x2;
var x3; x3 = x1; switch (x1[0]) {
switch (x3[0]) { case "(,)" : x2 = (x1[1] + x1[2] > 0); break;
case "(,)" : // pair constructor? }
var x4; return x2;
var x5; x5 = x3[1]; }
var x6; x6 = x3[2];
x4 = (x5 + x6); The latter code can be further improved by exploiting the fact that
var x7; x7 = 0; it is the translation of a strongly typed source language. Due to this
x2 = (x4 > x7); break; property, it is not necessary to check the constructor in the switch
} statement, since the argument expression of the switch is always a
return x2; value that belongs to a data type with a single constructor:
}
Removal of record constructors Let T be a type constructor with
a single data constructor, i.e., defined by
Obviously, this schematically generated code has the potential for
many optimizations that should be applied in order to reduce the data T a1 . . . an = C τ1 . . . τm
code size. This will be discussed in the next section.
Then replace “switch (x[0]) {case C: s; break;}” by s.
6. Optimizations E XAMPLE 6.3. Applying the removal of record constructors to the
Due to the translation of expressions into statements, nested expres- code of Example 6.2 combined with a further removal of single
sions are flattened by introducing auxiliary variables. In general, variables yields the final code:
this is necessary to exploit switch statements to implement pattern function posSum(x1) { return (x1[1] + x1[2] > 0); }
matching. As example 5.5 shows, this schematic translation often
introduces variables that are only assigned and used once. There- This code is much smaller and more efficient than the originally
fore, we introduce a code optimization that removes such variables: generated code of Example 5.5 and also similar to a hand-written
code.
Removal of single variables If there is a code sequence (i.e., with
a sequential control flow between the shown points) of the form Apart from these code optimizations, one should also consider the
representation of data types in the generated JavaScript code. Prim-
... var x; ... x = e; ... x ... itive types like numbers or truth values have a direct correspon-
without any other occurrences of x, remove the declaration and dence between Curry and JavaScript. Constructed types are repre-
assignment for x and replace the remaining single occurrence of sented as array structures (see Fig. 2). An alternative representation
x by e. could be objects in JavaScript, but there does not seem to be clear
advantages for one these options. However, the situation is different
This specific combination of constant propagation and liveness for strings. Many input fields contain strings that should be checked
analysis is very effective in our example: according to various conditions. For instance, our small run-time
E XAMPLE 6.1. If we apply the removal of single variables to the system to execute JavaScript programs for WUIs contains the func-
generated code of Example 5.5, we obtain: tion stringValueOf that extracts a string from an input field and
passes it to the corresponding check function (see the example in
function posSum(x1) { Section 4). Since the type of strings is [Char] in Curry, i.e., identi-
var x2; cal to a list of characters in order to reuse all existing polymorphic
var x3; x3 = x1; list functions also for strings, the function stringValueOf must
switch (x3[0]) { convert the input string into a list of characters. However, it is well
case "(,)" : x2 = (x3[1] + x3[2] > 0); break; known that this representation is inefficient compared to a primi-
} tive string representation [11]. The same drawback is present here
return x2; since each character in this list is represented by an (array) ob-
} ject whereas strings are primitive in JavaScript with a much better
representation. For instance, a condition which checks whether an
The motivation to remove only variables with a single occurrence input field contains a non-empty string can be defined in Curry by
is to avoid additional computational work that could be introduced
notEmpty [] = False
by duplicating code. Since all variables in an eager language are
notEmpty (_:_) = True
already evaluated, we can also remove variables with multiple
occurrences that have values identical to other variables: which is translated by our techniques into
Removal of aliasing variables If there is a code sequence (i.e., function notEmpty(x1) {
with a sequential control flow between the declaration and assign- var x2;
ment) of the form switch (x1[0]) {
... var x; ... x = y; ... case "[]" : x2 = false; break;
case ":" : x2 = true; break;
without any other assignment to x, remove the declaration and }
assignment for x and replace all remaining occurrences of x by return x2;
y. }
E XAMPLE 6.2. If we apply the removal of aliasing variables to the Since the transformation of a string into a character list where only
code of Example 6.1, we obtain: the first element is checked could be expensive (we detected per-
WUI analyze - eager-executable compile - JavaScript
specification collect WUI conditions code
include
compile ?
- web server compute -
program HTML form
ceivable computation costs with strings containing several thou- Program Curry JS JSO
sands characters), we have implemented another solution inspired lines bytes lines bytes lines bytes
by Curry’s lazy evaluation strategy: the function stringValueOf posSum 1 21 19 278 3 63
directly returns the JavaScript string without any transformation. isEmail 27 654 183 3050 77 1598
In order to comply with the standard list functions for processing person 71 1624 404 6546 126 2777
strings in Curry, we lazily convert a string into a list if it is de- exam 102 2333 629 10072 211 4613
manded, i.e., in front of a switch statement on lists. Thus, the code
for the function notEmpty is modified as Table 1. Code size of some programs
function notEmpty(x1) {
var x2; Note that the implementation of WUIs, as described in [21], must
if ((typeof(x1) == "string")) { also consider the integration of JavaScript code in the HTML form.
x1 = string2charlist(x1); For this purpose, the individual functions to generate HTML code
} from WUI specifications (they are implicitly contained in the WUI
switch (x1[0]) { specifications but not directly accessible) generate also the calls
case "[]" : x2 = false; break; to the JavaScript code for eager-executable conditions. These calls
case ":" : x2 = true; break; are attached to input fields if possible (in case of text fields with
} onblur events) and also collected for the complete WUI and at-
return x2; tached to the submit button. The check of the complete WUI fol-
} lows an innermost strategy in case of hierarchical data structures
where the function string2charlist converts an empty string (like list of persons containing dates): first, the basic inputs parts
into the empty list [] and a non-empty string into a non-empty list are checked and, if they do not contain an error, the parts con-
consisting of the first character and the remaining string (in place structed from these parts are checked. This strategy is reasonable
of the tail list). since it avoids superfluous error messages related to global proper-
ties if the individual parts contain input errors.
7. Implementation Our current implementation that comes with PAKCS does not inte-
grate an analyzer for eager-executable conditions, i.e., the first step
This section sketches the implementation of our framework that is of the implementation must currently be done by the programmer
visualized in Fig. 3. The complete implementation is available with (the connection of a termination analysis tool for Curry is part of
the current distribution of PAKCS [22]. future work). For this purpose, the WUI programmer can mark a
As discussed in detail in Section 5, it is not intended to translate all condition to be translated into JavaScript by using the WUI func-
possible conditions in WUIs into corresponding JavaScript code. tion withConditionJS instead of withCondition.7 All the re-
Therefore, one has to select the conditions satisfying the criteria maining steps of the implementation are fully automatic and do not
presented in Section 5 before the translation starts. Thus, the com- require any help by the programmer.
pilation of a web page containing WUIs is performed by the fol-
In order to provide an impression of the size of the generated
lowing steps:
JavaScript code, Table 1 contains the results of compiling some
1. The source program is analyzed and eager-executable condi- example programs from Curry into JavaScript. The columns con-
tions in WUIs are marked. tain the sizes of the source Curry program (including all dependent
2. The eager-executable conditions are collected together with the functions but without comments), the generated JavaScript code
functions on which they depend (which might be distributed in without optimization (JS), and the generated JavaScript code in-
various imported modules) into a single Curry program. cluding the optimization presented in Section 6 (JSO). For each
class of programs, the number of code lines and the code size in
3. This Curry program is translated into a JavaScript program bytes is shown. The first three programs are WUI conditions men-
following the methods described in Sections 5 and 6. tioned in this paper, and program exam consists of the conditions
4. The original Curry program is compiled with a standard Curry of a web-based examination management tool. The difference be-
compiler and installed on the web server.
7 The explicit marking of conditions that should be translated into
5. If a client demands a web page containing the WUI, the Curry JavaScript is also useful in the presence of an analyzer for eager-executable
program computes the corresponding HTML form and sends it functions, since there could be situations where eager-executable conditions
to the client together with the generated JavaScript program, as should not be transferred to the client, e.g., if they contain confidential al-
described in Section 4. gorithms.
tween the entries in the columns JS and JSO clearly shows that the to construct type-safe web interfaces. Similarly to WUIs, editors
optimizations of Section 6 are important and effective. for typed values are created in a type-oriented way. However, in
contrast to our framework, the editable data elements are identi-
8. Related Work fied by strings that might cause consistency problems similarly to
scripting languages like Perl or PHP. Furthermore, apart from well-
Web-based user interfaces are important for many modern appli- typedness, validity conditions on input data as in our approach are
cations. In principle, a dynamic web page can be implemented in not supported.
any programming language since the requirements on CGI pro-
grams that generate dynamic web pages are very low due to the The Google Web Toolkit (GWT8 ) is a framework to implement dy-
text-based CGI protocol. Although scripting languages like Perl or namic web pages in Java. GWT contains a compiler to translate the
PHP are quite common for this purpose, they lack support for re- developed Java programs into a set of JavaScript and HTML files.
liable programming (e.g., types, static checking of declarations) so Similarly to our approach, GWT proposes the use of a statically
that various approaches to implement web interfaces with higher- typed language to catch many programming errors at compile time
level programming languages have been developed. Some of them instead of programming in JavaScript. In contrast to our proposal,
are discussed in the following. GWT has no specific support to construct type-safe web forms in a
high-level manner.
One of the early domain-specific languages for web programming
is MAWL [27]. It supports the checking of well-formedness of Ruby on Rails9 is a framework to generate web interfaces to ma-
HTML documents by writing HTML documents with some gaps nipulate data stored in databases from the corresponding database
that are filled by the server before sending the document to the schema. Similarly to our WUIs, Rails reduces the code that must
client. Since these gaps are filled only with simple values, the gen- be explicitly written by generating most of it from the database
eration of documents whose structure depend on complex data is schema. Rails is based on the dynamically-typed, object-oriented
largely restricted. More complex tree structures are supported in language Ruby, whereas we have exploited the strong typing disci-
DynDoc [33] (part of the <bigwig> project [8]) which supports pline of Curry.
higher-order document templates, i.e., the gaps in a document can
be filled with other documents that can also contain gaps. In order 9. Conclusion
to validate user inputs in HTML forms, the <bigwig> project pro-
We have proposed a new framework to construct web-based user
poses PowerForms [7], an extension of HTML with a declarative
interfaces in a declarative way that is combined with features of
specification language to annotate acceptable form inputs. Since
JavaScript in order to exploit existing technologies without efforts
the specification language is based on regular expressions, it is less
for the application programmer. The construction of WUIs is type-
powerful than our approach which supports any computable pred-
oriented, i.e., the programmer selects basic WUI components and
icate on inputs. Similarly to our approach, PowerForms are trans-
combine them with specific combinators in order to obtain a WUI
lated into JavaScript so that input checking is done on the client
that can be applied to manipulate the data of the application do-
side. As a drawback, the implementation of PowerForms com-
main. An important feature of WUIs is the possibility to include
pletely relies on JavaScript so that they cannot be used if JavaScript
computable conditions on input data. Since these conditions are
is disabled. Finally, the <bigwig> project is based on a domain-
checked before the data is transferred to the application program,
specific language for writing dynamic web services while we ex-
the application must only specify such conditions but need not
ploit the features of the existing high-level language Curry.
check their validity or implement the necessary interactions with
Similar to the basic HTML programming library of Curry [17], the user to correct wrong inputs.
there are also libraries to support HTML programming in other In this paper we have shown how to exploit the existing technol-
functional and logic languages. For instance, the PiLLoW library ogy for client-side input checking within this framework but with-
[9] is an HTML/CGI library for Prolog. Since Prolog is not strongly out additional efforts for the application programmer. For this pur-
typed, static checks on the form of HTML documents are not di- pose, we have characterized a class of functions that can be eas-
rectly supported. Furthermore, there is no higher-level support for ily translated into a language like JavaScript with a call-by-value
complex interaction sequences as required in typical user inter- semantics. Conditions in WUIs that are implemented by functions
faces. belonging to this class are automatically translated into correspond-
Meijer [29] developed a CGI library for Haskell that defines a data ing JavaScript code. This code is used on the client side when the
type for HTML expressions together with a wrapper function that user manipulates or submits the application data in a web form gen-
translates such expressions into a textual HTML representation. erated by the WUI description.
However, it does not offer any abstraction for programming se- The advantages of programming with WUIs has been already
quences of interactions (e.g., by event handlers). These must be shown in a previous paper [21] and various applications based on
implemented in the traditional way by choosing strings for identify- this concept. The advantage of the current work is the reuse of the
ing input fields, passing states as hidden input fields etc. Thiemann technology available in almost every web browser without efforts
[34] proposed a representation of HTML documents in Haskell that for the programmer. Instead of programming in different languages,
ensures the well-formedness of documents by exploiting Haskell’s e.g., writing scripts in a dynamically typed, interpreted language
type class system. In [35] he extended this approach by combining like JavaScript, which often leads to unreliable programs and must
it with the ideas of [17] to implement interaction sequences by an be kept in conformance with the application (remember that server-
event handler model. Although his approach also supports typed side input checking is always necessary to avoid security risks),
input fields similarly to our WUIs, it is more restricted. It does not we propose to generate the necessary code from the existing WUI
support arbitrary conditions on input data or type-based combina- specification. In principle, this concept can be also applied to other
tors for input fields, and the layout of the generated web pages is programming languages than Curry. However, it has been demon-
more restrictive (due to the monadic implementation in the func- strated that the combined features of a multi-paradigm language
tional base language).
8 [Link]
The iData toolkit [31, 32] is a framework, implemented with
generic programming techniques in the functional language Clean, 9 [Link]
like Curry can be exploited to provide better APIs for such libraries [12] S. Fischer. A Functional Logic Database Library. In Proc. of the
[17, 21]. ACM SIGPLAN 2005 Workshop on Curry and Functional Logic
Programming (WCFLP 2005), pp. 54–59. ACM Press, 2005.
For future work it would be interesting to provide useful tools for
the automatic termination or complexity analysis. They can be used [13] D. Flanagan. JavaScript: The Definitive Guide. O’Reilly, 5th edition
edition, 2006.
for a better characterization of programs that should be translated
into JavaScript. For instance, functions with a high computational [14] J. Giesl, P. Schneider-Kamp, and R. Thiemann. AProVE 1.2:
complexity should not be executed on the client’s browser, even if Automatic Termination Proofs in the Dependency Pair Framework. In
they are terminating. Furthermore, the compilation into JavaScript Proceedings of the 3rd International Joint Conference on Automated
Reasoning (IJCAR ’06), pp. 281–286. Springer LNCS 4130, 2006.
could be improved. Although the current translation into recursive
JavaScript functions is sufficient in our practical applications, fu- [15] M. Hanus. The Integration of Functions into Logic Programming:
ture applications might demand for better compilation schemes, From Theory to Practice. Journal of Logic Programming, Vol. 19&20,
pp. 583–628, 1994.
e.g., tail recursion optimization. Finally, one could exploit the more
recent Ajax framework to increase the interaction, e.g., by execut- [16] M. Hanus. A Unified Computation Model for Functional and Logic
ing complex conditions on the web browser before submitting the Programming. In Proc. of the 24th ACM Symposium on Principles of
form, or by extending the framework to allow conditions of type Programming Languages (Paris), pp. 80–93, 1997.
“IO Bool”, i.e., which depend on the server’s state and must be [17] M. Hanus. High-Level Server Side Web Scripting in Curry. In
executed on the web server during the user interaction with his web Proc. of the Third International Symposium on Practical Aspects of
browser. Declarative Languages (PADL’01), pp. 76–92. Springer LNCS 1990,
2001.
[18] M. Hanus. Dynamic Predicates in Functional Logic Programs.
Acknowledgments Journal of Functional and Logic Programming, Vol. 2004, No. 5,
The author is grateful to the anonymous referees for their sugges- 2004.
tions and to Bernd Braßel, Sebastian Fischer, and Frank Huch for [19] M. Hanus. CurryBrowser: A Generic Analysis Environment for Curry
their constructive comments on this work. Programs. In Proc. of the 16th Workshop on Logic-based Methods in
Programming Environments (WLPE’06), pp. 61–74, 2006.
References [20] M. Hanus. Reporting Failures in Functional Logic Programs. In Proc.
of the 15th International Workshop on Functional and (Constraint)
[1] E. Albert, M. Hanus, F. Huch, J. Oliver, and G. Vidal. Operational Logic Programming (WFLP 2006), pp. 49–62, 2006.
Semantics for Declarative Multi-Paradigm Languages. Journal of
Symbolic Computation, Vol. 40, No. 1, pp. 795–829, 2005. [21] M. Hanus. Type-Oriented Construction of Web User Interfaces. In
Proceedings of the 8th ACM SIGPLAN International Conference on
[2] S. Antoy. Definitional Trees. In Proc. of the 3rd International Principles and Practice of Declarative Programming (PPDP’06), pp.
Conference on Algebraic and Logic Programming, pp. 143–157. 27–38. ACM Press, 2006.
Springer LNCS 632, 1992.
[22] M. Hanus, S. Antoy, B. Braßel, M. Engelke, K. Höppner,
[3] S. Antoy. Constructor-based Conditional Narrowing. In Proc. of J. Koj, P. Niederau, R. Sadre, and F. Steiner. PAKCS:
the 3rd International ACM SIGPLAN Conference on Principles and The Portland Aachen Kiel Curry System. Available at
Practice of Declarative Programming (PPDP 2001), pp. 199–206. [Link] 2007.
ACM Press, 2001.
[23] M. Hanus and C. Prehofer. Higher-Order Narrowing with Definitional
[4] S. Antoy, R. Echahed, and M. Hanus. A Needed Narrowing Strategy. Trees. Journal of Functional Programming, Vol. 9, No. 1, pp. 33–75,
Journal of the ACM, Vol. 47, No. 4, pp. 776–822, 2000. 1999.
[5] S. Antoy and M. Hanus. Functional Logic Design Patterns. In [24] M. Hanus (ed.). Curry: An Integrated Func-
Proc. of the 6th International Symposium on Functional and Logic tional Logic Language (Vers. 0.8.2). Available at
Programming (FLOPS 2002), pp. 67–87. Springer LNCS 2441, 2002. [Link] 2006.
[6] S. Antoy and M. Hanus. Overlapping Rules and Logic Variables in [25] S.H. Huseby. Innocent Code: A Security Wake-Up Call for Web
Functional Logic Programs. In Proceedings of the 22nd International Programmers. Wiley, 2003.
Conference on Logic Programming (ICLP 2006), pp. 87–101.
Springer LNCS 4079, 2006. [26] T. Johnsson. Lambda Lifting: Transforming Programs to Recursive
Functions. In Functional Programming Languages and Computer
[7] C. Brabrand, A. Møller, M. Ricky, and M.I. Schwartzbach. Power- Architecture, pp. 190–203. Springer LNCS 201, 1985.
Forms: Declarative Client-side Form Field Validation. World Wide
Web Journal, Vol. 3, No. 4, pp. 205–214, 2000. [27] D.A. Ladd and J.C. Ramming. Programming the Web: An
Application-Oriented Language for Hypermedia Services. In 4th
[8] C. Brabrand, A. Møller, and M.I. Schwartzbach. The <bigwig> International World Wide Web Conference, 1995.
Project. ACM Transactions on Internet Technology, Vol. 2, No. 2, pp.
79–114, 2002. [28] F. López-Fraguas and J. Sánchez-Hernández. TOY: A Multiparadigm
Declarative System. In Proc. of RTA’99, pp. 244–247. Springer LNCS
[9] D. Cabeza and M. Hermenegildo. Internet and WWW Pro- 1631, 1999.
gramming using Computational Logic Systems. In Work-
shop on Logic Programming and the Internet, 1996. See also [29] E. Meijer. Server Side Web Scripting in Haskell. Journal of
[Link] Functional Programming, Vol. 10, No. 1, pp. 1–18, 2000.
[10] J. Correas, J.M. Gómez, M. Carro, D. Cabeza, and M. Hermenegildo. [30] S. Peyton Jones, editor. Haskell 98 Language and Libraries—The
A Generic Persistence Model for (C)LP Systems (and Two Useful Revised Report. Cambridge University Press, 2003.
Implementations). In Proc. of the Sixth International Symposium on [31] R. Plasmeijer and P. Achten. The Implementation of iData -
Practical Aspects of Declarative Languages (PADL’04), pp. 104–119. A Case Study in Generic Programming. In Proc. of the 17th
Springer LNCS 3057, 2004. International Workshop on Implementation and Application of
[11] D. Coutts, D. Stewart, and R. Leshchinsky. Rewriting Haskell Functional Languages (IFL 2005). Trinity College, University of
Strings. In Proc. 9th International Symposium on Practical Aspects Dublin, Technical Report TCD-CS-2005-60, 2005.
of Declarative Languages (PADL 2007), pp. 50–64. Springer LNCS [32] R. Plasmeijer and P. Achten. iData for the World Wide Web -
4354, 2007.
Programming Interconnected Web Forms. In Proc. of the 8th [35] P. Thiemann. WASH/CGI: Server-side Web Scripting with Sessions
International Symposium on Functional and Logic Programming and Typed, Compositional Forms. In 4th International Symposium
(FLOPS 2006), pp. 242–258. Springer LNCS 3945, 2006. on Practical Aspects of Declarative Languages (PADL 2002), pp.
[33] A. Sandholm and M.I. Schwartzbach. A Type System for Dynamic 192–208. Springer LNCS 2257, 2002.
Web Documents. In Proc. of the 27th ACM Symposium on Principles [36] P. Wadler. How to Declare an Imperative. ACM Computing Surveys,
of Programming Languages, pp. 290–301, 2000. Vol. 29, No. 3, pp. 240–263, 1997.
[34] P. Thiemann. Modelling HTML in Haskell. In International
Workshop on Practical Aspects of Declarative Languages (PADL’00),
pp. 263–277. Springer LNCS 1753, 2000.