<programming> One of a sequence of copies of a program, each
	incorporating new modifications.  Each version is usually
	identified by a number, commonly of the form X.Y where X is
	the major version number and Y is the release number.
	Typically an increment in X (with Y reset to zero) signifies a
	substantial increase in the function of the program or a
	partial or total re-implementation, whereas Y increases each
	time the progam is changed in any way and re-released.

	Version numbers are useful so that the user can know if the
	program has changed ({bugs} have been fixed or new functions
	added) since he obtained his copy and the programmer can tell
	if a bug report relates to the current version.  It is thus
	always important to state the version when reporting bugs.
	Statements about compatibility between different software
	components should always say which versions they apply to.

	See {change management}.

	(1997-12-07)

<language, programming> (Or "source", or rarely "source
	language") The form in which a computer program is written by
	the programmer.  Source code is written in some formal
	programming language which can be compiled automatically into
	{object code} or {machine code} or executed by an
	{interpreter}.

	(1995-01-05)

<language, text> An {SGML}, {HTML}, or {XML} {token}
	representing the beginning (start tag: "<p ...>") or end (end
	tag: "</p>") of an {element}.  In normal SGML {syntax} (and
	always in {XML}), a tag starts with a "<" and ends with an
	">".

	In {HTML} jargon, the term "tag" is often used for an
	"{element}".

	(2001-01-31)

<programming> (Or "released version", "baseline") A version of
	a piece of software which has been made public (as opposed to
	a version that is in development, or otherwise unreleased).

	A release is either a {major release}, a {revision}, or a
	{bugfix}.

	Pre-release versions may be called {alpha test}, or {beta
	test} versions.

	See {change management}.

	(1996-08-04)

<programming> (See below for synonyms) A data structure for
	storing items which are to be accessed in last-in first-out
	order.

	The operations on a stack are to create a new stack, to "push"
	a new item onto the top of a stack and to "pop" the top item
	off.  Error conditions are raised by attempts to pop an empty
	stack or to push an item onto a stack which has no room for
	further items (because of its implementation).

	Most processors include support for stacks in their
	{instruction set architectures}.  Perhaps the most common use
	of stacks is to store {subroutine} arguments and return
	addresses.  This is usually supported at the {machine code}
	level either directly by "jump to subroutine" and "return from
	subroutine" instructions or by {auto-increment} and
	auto-decrement {addressing modes}, or both.  These allow a
	contiguous area of memory to be set aside for use as a stack
	and use either a special-purpose {register} or a general
	purpose register, chosen by the user, as a {stack pointer}.

	The use of a stack allows subroutines to be {recursive} since
	each call can have its own calling context, represented by a
	stack frame or {activation record}.  There are many other
	uses.  The programming language {Forth} uses a data stack in
	place of variables when possible.

	Although a stack may be considered an {object} by users,
	implementations of the object and its access details differ.
	For example, a stack may be either ascending (top of stack is
	at highest address) or descending.  It may also be "full" (the
	stack pointer points at the top of stack) or "empty" (the
	stack pointer points just past the top of stack, where the
	next element would be pushed).  The full/empty terminology is
	used in the {Acorn Risc Machine} and possibly elsewhere.

	In a list-based or {functional language}, a stack might be
	implemented as a {linked list} where a new stack is an empty
	list, push adds a new element to the head of the list and pop
	splits the list into its head (the popped element) and tail
	(the stack in its modified form).

	At {MIT}, {pdl} used to be a more common synonym for stack,
	and this may still be true.  {Knuth} ("The Art of Computer
	Programming", second edition, vol. 1, p. 236) says:

	  Many people who realised the importance of stacks and queues
	  independently have given other names to these structures:
	  stacks have been called push-down lists, reversion storages,
	  cellars, dumps, nesting stores, piles, last-in first-out
	  ("LIFO") lists, and even yo-yo lists!

	[{Jargon File}]

	(1995-04-10)

<programming, operating system> (Or "application", "app") A
	complete, self-contained program that performs a specific
	function directly for the user.  This is in contrast to system
	software such as the {operating system} {kernel}, {server}
	processes and libraries which exists to support application
	programs.

	Editors for various kinds of documents, {spreadsheets}, and
	text formatters are common examples of applications.  Network
	applications include clients such as those for {FTP},
	{electronic mail}, {telnet} and {WWW}.

	The term is used fairly loosely, for instance, some might say
	that a client and server together form a distributed
	application, others might argue that editors and compilers
	were not applications but tools for building applications.

	One distinction between an application program and the
	operating system is that applications always run in "user
	mode" (or "non-privileged mode"), while operating systems and
	related utilities may run in "supervisor mode" (or "privileged
	mode").

	The term may also be used to distinguish programs which
	communicate via a {graphical user interface} from those which
	are executed from the {command line}.

	(1994-11-28)

1. A discrepancy between a computed, observed, or measured
	value or condition and the true, specified, or theoretically
	correct value or condition.

	2. <programming> A mental mistake made by a programmer that
	may result in a program {fault}.

	3. (verb) What a program does when it stops as result of a
	programming error.

	(2000-03-28)