SEKE 2012 Proceedings - Knowledge Systems Institute

however, does not allow variables for head predicates in
clauses [13]. H igher-order programming can be done in
standard Prolog, but requires special features, such as the ‘call’
predicate. [14]
(5) non-atomic characters – Character representation is not
part of the core language, but defined as a syntax extension.
There are no built-in character functions, but instead these
would be defined in a library.
(6) non-atomic symbols – Non-atomic symbols eliminate the
need for built-in decimal numbers, since they can be easily
defined through library utilities.
(7) flat sequences – Sequences in axiomatic language are
completely "flat" compared with the underlying head/tail “dot”
representation of Prolog and Lisp.
(8) string variables – T hese provide pattern matching and
metalanguage support. String variables can yield an infinite set
of most-general unifications. For example, ($ a) unifies with (a
$) with the assignments of $ = '', 'a', 'a a', ....
(9) metalanguage – T he flexible syntax and higher-order
capability makes axiomatic language well-suited to metaprogramming,
language-oriented programming [15], and
embedded domain-specific languages [16]. T his language
extensibility is sim ilar to that of Racket [17], but axiomatic
language is smaller.
(10) no built-in arithmetic or other functions – The minimal
nature and extensibility of axiomatic language means that basic
arithmetic and other functions are provided through a library
rather than built-in. But this also means that such functions
have explicitly defined semantics and are more amenable to
formal proof.
(11) explicit definition of approximate arithmetic – Since there
is no built-in floating point arithmetic, approximate arithmetic
must also be defined in a library. But this means symbolically
defined numerical results would always be identical down to
the last bit, regardless of future floating point hardware.
(12) negation – In axiomatic language a form of negation-asfailure
could be defined on encoded axioms.
(13) no non-logical operations such as cut – This follows from
there being no procedural interpretation in axiomatic language.
(14) no meta-logical operations such as v ar, setof, findall –
These could be defined on encoded axioms.
(15) no assert/retract – A set of axioms is static. Modifying
this set must be done “outside” the language.
VI. CONCLUSIONS
A tiny logic programming language intended as a pure
specification language has been described. T he language
defines infinite sets of symbolic expressions which are
interpreted to represent the external behavior of programs. The
programmer is expected to write specifications without concern
about efficiency.
Axiomatic language should provide increased programmer
productivity since specifications (such as the earlier sort
definition) should be smaller and more readable than the
corresponding implementation algorithms. Furthermore, these
definitions should be more general and reusable than
executable code that is c onstrained by efficiency. N ote that
most of the axioms of this paper could be considered reusable
definitions suitable for a library. Axiomatic language has finegrained
modularity, which encourages the abstraction of the
general parts of a solution from specific problem details and
minimizes boilerplate code. The metalanguage capability
should enable programmers to define a rich set of specification
tools.
The challenge, of course, is the efficient implementation of
the programmer's specifications. [18] Higher-order definitions
and the metalanguage capability are powerful tools for software
specification, but make program transformation essential. The
difficult problem of transformation should be helped, however,
by the extreme simplicity and purity of the language, such as
the absence of non-logical operations, built-in functions, state
changes, and in put/output. Future work will address the
problem of transformation.
REFERENCES
[1] L. Prechelt, “An empirical comparison of seven programming
languages,” IEEE Computer, vol. 33, no. 10, pp. 23-29, October 2000.
[2] U. Wiger, “Four-fold increase in productivity and quality”, Ericsson
Telecom AB, 2001.
[3] http://www.axiomaticlanguage.org
[4] W. W. Wilson, “Beyond Prolog: software specification by grammar,”
ACM SIGPLAN Notices, vol. 17, #9, pp. 34-43, September 1982.
[5] W. Chen, M. Kifer, D. S. Warren, “HiLog: a foundation for higher-order
logic programming,” in J. of Logic Programming, vol. 15, #3, pp. 187-
230, 1993.
[6] J. Backus, “Can programming be liberated from the von Neumann style?
A functional style and its algebra of programs,” CACM, vol. 21, #8, pp.
613–641, August 1978.
[7] S. Peyton Jones, “Tackling the Awkward Squad: monadic input/output,
concurrency, exceptions, and foreign-language calls in Haskell”,
Engineering Theories of Software Construction, ed. T. Hoare, M. Broy,
R. Steinbruggen, IOS Press, pp. 47-96, 2001.
[8] A. Pettorossi, M. Proietti, R. Giugno, “Synthesis and transformation of
logic programs using unfold/fold proofs,” J. Logic Programming, vol.
41, 1997.
[9] P. Wadler, “How to declare an imperative,” ACM Computing Surveys,
vol. 29, #3, pp. 240-263, September, 1997.
[10] K. L. Clark, Micro-Prolog: Programming in Logic, Prentice Hall, 1984.
[11] Allegro Prolog, http://www.franz.com/support/documentation/8.2/doc/
prolog.html.
[12] The XSB Research Group, http://www.cs.sunysb.edu/~sbprolog/
index.html.
[13] D. S. Warren, K. Sagonas, private communication, 2000.
[14] L. Naish, “Higher-order logic programming in Prolog,” Proc. Workshop
on Multi-Paradigm Logic Programming, pp. 167-176, JICSLP’96, Bonn,
1996.
[15] M. Ward, “Language oriented programming”, Software Concepts and
Tools, vol. 15, pp. 147-161, 1994.
[16] P. Hudak, “Building domain-specific embedded languages,” ACM
Computing Surveys, vol. 28, #4es, December 1996.
[17] S. Tobin-Hochstadt, V. St-Amour, R. Culpepper, M. Flatt, M. Felleisen,
“Languages as Libraries”, PLDI’11, 2011.
[18] P. Flener, Achievements and Prospects of Program Synthesis, LNAI
2407, pp. 310-346, 2002.
490