<!--
  - Authors:
  -   Seif Haridi (seif@sics.se)
  -   Nils Franzen (nilsf@sics.se)
  -
  - Copyright:
  -   Seif Haridi, Nils Franzen, 1998
  -
  - Last change:
  -   $Date: 1999-08-26 15:59:09 +0200 (Thu, 26 Aug 1999) $ by $Author: nilsf $
  -   $Revision: 11928 $
  -
  - This file is part of Mozart, an implementation
  - of Oz 3
  -    http://www.mozart-oz.org
  -
  - See the file "LICENSE" or
  -    http://www.mozart-oz.org/LICENSE.html
  - for information on usage and redistribution
  - of this file, and for a DISCLAIMER OF ALL
  - WARRANTIES.
  -
  -->

<CHAPTER ID="chapter.basics">
  <TITLE>Basics</TITLE>
  <P>We will initially restrict ourselves to the sequential
  programming style of Oz. At this stage you may think of Oz
  computations as performed by a sequential process that executes one
  statement after the other. We call this process a
  <EM>thread</EM>. This thread has access to the <EM>store</EM>. It is
  able to manipulate the store by reading, adding, and updating
  information stored in the store. Information is accessed through the
  notion of <EM>variables</EM>. A thread can access information only
  through the variables visible to it, directly or indirectly. Oz
  variables are <EM>single-assignment</EM> variables or more
  appropriately logic variables. In imperative languages like C and
  Java, a variable can be assigned multiple times. In contrast, single
  assignment variables can be assigned only once. This notion is known
  from many languages including dataflow languages and concurrent logic
  programming languages. A single assignment variable has a number of
  phases in its lifetime. Initially it is introduced with unknown value,
  and later it might be assigned a value, in which case the variable
  becomes <EM>bound</EM>. Once a variable is bound, it cannot itself be
  changed. A <EM>logic variable</EM> is a single assignment variable that
  can also be equated with another variable. Using logic variables does
  not mean that you cannot model state-change because a variable, as you
  will see later, could be bound to a cell, which is stateful, i.e., the
  content of a cell can be changed.</P>

  <P>A thread executing the statement: <<<local X Y Z in S end>>>
  
  <P>will introduce three single assignment variables <<X>>, <<Y>>,
  <<Z>> and execute the statement <<S>> in the scope of these
  variables. A variable normally starts with an upper-case letter,
  possibly followed by an arbitrary number of alphanumeric
  characters. Variables may also be presented textually as any string of
  printable characters enclosed within back-quote characters,
  e.g. <<`this $ is a variable`>>. Before the execution of <<S>> the
  variables declared will not have any associated values. We say that
  the variables are <EM>unbound</EM>. Any variable in an Oz program must
  be introduced, except for certain pattern matching constructs to be
  shown later.
  
  <P>Another form of declaration is: <<<declare X Y Z in S>>>

  <P>This is an open-ended declaration that makes <<X>>, <<Y>>, and
  <<Z>> visible globally in <<S>>, as well as in all statements that follow
  <<S>> textually, unless overridden again by another variable
  declaration of the same textual variables. <<X>>, <<Y>>, <<Z>> are
  global variables.</P>


  <SECTION><TITLE>Primary Oz Types</TITLE>
  <P><FIGURE ID="TypeHier" CLASS="Figure">
    <CAPTION>Oz Type Hierarchy</CAPTION>
    <P>
    <PICTURE.CHOICE DISPLAY>
    <PICTURE.EXTERN TO="image33.gif" TYPE=gif>
    </PICTURE.CHOICE>
  </FIGURE>

  <P>Oz is a dynamically typed language. <PTR TO="TypeHier"> shows the
  type hierarchy of Oz. Any variable, if it ever gets a value, will be
  bound to a value of one of these types. Most of the types seem
  familiar to experienced programmers, except probably <EM>Chunk</EM>,
  <EM>Cell</EM>, <EM>Space</EM>, <EM>FDInt</EM> and <EM>Name</EM>. We
  will discuss all of these types in due course. For the impatient
  reader here are some hints. The <EM>Chunk</EM> data type allows users
  to introduce new abstract data types. <EM>Cell</EM> introduces the
  primitive notion of state-container and state
  modification. <EM>Space</EM> will be needed for advanced problem
  solving using search techniques. <EM>FDInt</EM> is the type of finite
  domain that is used frequently in constraint programming, and
  constraint satisfaction. <EM>Name</EM> introduces anonymous unique
  unforgeable tokens.

  <P>The language is dynamically-typed in the sense that when a variable
  is introduced, its type as well as its value are unknown. Only when
  the variable is bound to an Oz value, does its type become determined.

<!--
  <SECTION><TITLE>Hello World</TITLE>
  <P>Let us do like everybody else. If you are unfamiliar with Oz, here
  is your first Oz program. Start your Mozart system. You typically
  start it by typing the command <FILE>mozart</FILE> and pressing
  <KEY>RETURN</KEY>. This will start the Oz Programming Interface
  OPI having the <NAME TYPE=TOOL>EMACS</NAME> editor as your
  interface. You will see two buffers. The upper buffer is called
  <EM>Oz</EM>, where you can enter programs and the lower buffer is
  called <EM>Oz Compiler</EM> where you can see the result of compiling
  Oz programs. There is also a third buffer <EM>Oz Emulator</EM> showing
  the status of the emulator. This buffer is the standard input and
  standard output of the emulator.
  You may switch between the compiler and the emulator
  buffer through the Oz pull-down menu that appears in your 
  <NAME TYPE=TOOL>EMACS menu</NAME> bar. Use the entry 
  <EM>Show/Hide</EM> to switch between the compiler
  and the emulator buffer.

  <P>If you feed the program shown below: <<<{Show 'Hello World'}>>>

  <P>It will print the string 'Hello World' in your standard output. In
  fact, the main reason for showing this program is to get you
  accustomed with one of the unconventional syntactic aspects of Oz,
  namely the syntax of <EM>procedure calls/applications</EM>.
  <<{Show 'Hello World'}>> is a procedure application of <<Show>> on
  the single
  atom argument <<'Hello World'>>. <<Show>> is actually a pre-declared
  global variable in your initial environment that got bound to the
  printing procedure when the <<System>> module was loaded at the start
  of the Oz system. Procedure application in Oz syntactically follows
  other functional languages, e.g. Scheme, with the exception of using
  braces instead of parentheses.

  <P>The Mozart system provides a number of interesting tools that are
  accessible through the Oz menu, or that can be called from your Oz
  Program. Instead of using <<Show>> try <<Browse>>.

  <P CLASS=WARNING>You can learn about the Mozart programming system, its 
  programming interface and associated tools by looking to the 
  documentation on the web <REF.EXTERN 
  TO="http://www.mozart-oz.org">http://www.mozart-oz.org</REF.EXTERN>.
-->


<SECTION><TITLE>Adding Information</TITLE>
<P>In Oz, there are few ways of adding information to the store or
(said differently) of binding a variable to a value. The most common
form is using the <EM>equality</EM> infix operator <<=>>. For example,
given that the variable <<X>> is declared the following statement:
<<<X = 1>>>

<P>will bind the unbound variable <<X>> to the integer <<1>>, and add
this information to the store. Now, if <<X>> is already assigned the
value <<1>>, the operation is considered as performing a test on
<<X>>. If <<X>> is already bound to an incompatible value, i.e. to any
other value different from <<1>>, a proper <EM>exception</EM> will be
raised. Exception handling is described later.

<SECTION><TITLE>Data Types with Structural Equality</TITLE>
<P>The hierarchy starting from <EM>Number</EM> and <EM>Record</EM> in
<PTR TO="TypeHier"> defines the data types of Oz whose members
(values) are equal only if they are structurally similar. For example
two numbers are equal if they have the same type, or one is a subtype
of the other, and have the same value. For example, if both are
integers and are identical numbers or both are lists and their head
elements are identical as well as their respective tail
lists. Structural equality allows values to be equivalent even if they
are replicas occupying different physical memory location.

<SECTION><TITLE>Numbers</TITLE>
<P>The following program, introduces three variables <<I>>,<<F>> and
<<C>>. It assigns <<I>> an integer, <<F>> a float, and <<C>> the
character <KEY>t</KEY> in this order. It then displays the list
consisting of <<I>>,<<F>>, and <<C>>.
<<<
local I F C in
   I = 5
   F = 5.5
   C = &amp;t
   {Browse [I F C]}
end
>>>

<P>Oz supports binary, octal, decimal and hexadecimal notation for
integers, which can be arbitrary large. An octal starts with a leading
<KEY>0</KEY>, and a hexadecimal starts with a leading <KEY>0x</KEY> or
<KEY>0X</KEY>. Floats are different from integers and must have
decimal points. Other examples of floats are shown where <<~>> is
unary minus: <<<~3.141   4.5E3    ~12.0e~2>>>

<P>In Oz, there is no automatic type conversion, so <<5.0 = 5>> will
raise an exception. Of course, there are primitive procedures for
explicit type conversion. These and many others can be found in
<PTR TO="schulte98">. Characters are a subtype of integers in the range of
<<0, ..., 255>>. The standard ISO 8859-1 coding is used (not
Unicode). Printable characters have external representation,
e.g. <<&0>> is actually the integer <<48>>, and <<&amp;a>> is <<97>>. Some
control characters have also a representation e.g. <<&\n>> is a new
line. All characters can be written as <<&\>><EM>ooo</EM>, where
<EM>o</EM> is an octal digit.

<P>Operations on characters, integers, and floats can be found in the
library modules
<ref.extern to="ozdoc:base" key="section.text.characters"/<<Char>>/,
<ref.extern to="ozdoc:base" key="section.numbers.floats"/<<Float>>/, and
<ref.extern to="ozdoc:base" key="section.numbers.integers"/<<Int>>/.
Additional generic
operations on all numbers are found in the module
<ref.extern to="ozdoc:base" key="section.numbers.general"/<<Number>>/.

<SECTION><TITLE>Literals</TITLE>
<P>Another important category of atomic types, i.e. types whose
members have no internal structure, is the category of
literals. Literals are divided into atoms and names. An Atom is
symbolic entity that has an identity made up of a sequence of
alphanumeric characters starting with a lower case letter, or
arbitrary printable characters enclosed in quotes. For example:
<<<a   foo   '='   ':='   'OZ 3.0'   'Hello World'>>>

<P>Atoms have an ordering based on lexicographic ordering.  

<P>Another category of elementary entities is <<Name>>. The only way
to create a name is by calling the procedure <<{NewName X}>> where
<<X>> is assigned a new name that is guaranteed to be worldwide
unique. Names cannot be forged or printed. As will be seen later,
names play an important role in the security of Oz programs. A subtype
of <<Name>> is <<Bool>>, which consists of two names protected from
being redefined by having the reserved keywords <<true>> and
<<false>>. Thus a user program cannot redefine them, and mess up all
programs relying on their definition. There is also the type <<Unit>>
that consists of the single name <<unit>>. This is used as
synchronization token in many concurrent programs.
<<<
local X Y B in
   X = foo
   {NewName Y}
   B = true
   {Browse [X Y B]}
end
>>>


<SECTION><TITLE>Records and Tuples</TITLE>
<P>Records are structured compound entities. A record has a
<EM>label</EM> and a fixed number of components or arguments. There
are also records with a variable number of arguments that are called
<EM>open records</EM>. For now, we restrict ourselves to 'closed'
records. The following is a record:

<<<tree(key: I value: Y left: LT right: RT)>>>

<P>It has four arguments, and the label <<tree>>. Each argument
consists of a pair <EM>Feature:Field</EM>, so the features of the
above record are <<key>>, <<value>>, <<left>>, and <<right>>. The
corresponding fields are the variables <<I>>,<<Y>>,<<LT>>, and
<<RT>>. It is possible to omit the features of a record reducing it to
what is known from logic programming as a compound term. In Oz, this
is called a <EM>tuple</EM>. So, the following tuple has the same label
and fields as the above record:

<<<tree(I Y LT RT)>>>

<P>It is just a syntactic notation for the record:

<<<tree(1:I 2:Y 3:LT 4:RT)>>>

<P>where the features are integers starting from <<1>> up to the
number of fields in the tuple. The following program will display a
list consisting of two elements one is a record, and the other is
tuple having the same label and fields:

<<<
declare T I Y LT RT W in
T = tree(key:I value:Y left:LT right:RT)
I = seif
Y = 43
LT = nil
RT = nil
W = tree(I Y LT RT)
{Browse [T W]}
>>>

<P>The display will show:

<<<
[tree(key:seif value:43 left:nil right:nil)
 tree(seif 43 nil nil)]
>>>


<SECTION><TITLE>Operations on records</TITLE>
<P>We discuss some basic operations on records. Most operations are
found in the module
<ref.extern to="ozdoc:base" key="section.records.records"/<<Record>>/.
To select a field of a record component, we use the infix dot
operator, &eg; <code/?{Record}.?{Feature}/
<<<
% Selecting a Component
{Browse T.key}
{Browse W.1}
% will show seif twice in the browser
seif
seif
>>>

<P>The <EM>arity</EM> of a record is a list of the features of the
record sorted lexicographically. To display the arity of a record we
use the procedure <<Arity>>. The procedure application <<{Arity R X}>>
will execute once <<R>> is bound to a record, and will bind <<X>> to
the arity of the record. Executing the following statements

<<<
% Getting the Arity of a Record
local X in {Arity T X} {Browse X} end
local X in {Arity W X} {Browse X} end
>>>

<P>will display

<<<
[key left right value]
[1 2 3 4]
>>>

<P>Another useful operation is conditionally selecting a field of a
record. The operation <<CondSelect>> takes a record <<R>>, a feature
<<F>>, and a default field-value <<D>>, and a result argument
<<X>>. If the feature <<F>> exists in <<R>>, <<X>> is bound to
<<R.F>>, otherwise <<X>> is bound to the default value
<<D>>. <<CondSelect>> is not really a primitive operation. It is
definable in Oz. The following statements:

<<<
% Selecting a component conditionally
local X in {CondSelect W key eeva X} {Browse X} end
local X in {CondSelect T key eeva X} {Browse X} end
>>>

<P>will display

<<<
eeva
seif
>>>

<P>A common infix tuple-operator used in Oz is <<#>>. So, <<1#2>> is a
tuple of two elements, and observe that <<1#2#3>> is a single tuple of
three elements:

<<<
'#'(1 2 3)
>>>

<P>and not the pair <<1#(2#3)>>.   With the <<#>> operator, you cannot
directly write an empty or a single element tuple.  Instead, you must
fall back on the usual prefix record syntax:
the empty tuple must be written <<'#'()>> or just <<'#'>>, and a single
element tuple <<'#'(X)>>.

<P>The operation <<{AdjoinAt R1 F X R2}>> binds <<R2>> to the record
resulting from adjoining the field <<X>> to <<R1>> at feature
<<F>>. If <<R1>> already has the feature <<F>>, the resulting record
<<R2>> is identical to <<R1>> except for the field <<R1.F>> whose
value becomes <<X>>. Otherwise the argument <<F:X>> is added to <<R1>>
resulting in <<R2>>.

<P>The operation <<{AdjoinList R LP S}>> takes a record <<R>>, a list
of feature-field pairs, and returns in <<S>> a new record such that:

<LIST>
<ITEM>The label of R is equal to the label of S.
<ITEM>S has the components that are specified in LP in addition to
all components in R that do not have a feature occurring in LP.
</LIST>

<P>This operation is of course defined by using <<AdjointAt>>.

<<<
local S in 
   {AdjoinList tree(a:1 b:2) [a#3 c#4] S}
   {Show S}
end
% gives S=tree(a:3 b:2 c:4)
>>>

<SECTION><TITLE>Lists</TITLE>
<P>As in many other symbolic programming languages, e.g. Scheme and
Prolog, <EM>lists</EM> form an important class of data structures in
Oz. The category of lists does not belong to a single data type in
Oz. They are rather a conceptual structure. A list is either the atom
<<nil>> representing the empty list, or is a tuple using the infix
operator <<|>> and two arguments which are respectively the head and
the tail of the list. Thus, a list of the first three positive
integers is represented as:

<<<1|2|3|nil>>>

<P>Another convenient special notation for a <EM>closed list</EM>,
 &ie; a list with a determined number of elements is:

<<<[1 2 3]>>>

<P>The above notation is used only for closed list, so a list whose
first two elements are <<1>> and <<2>>, but whose tail is the variable
<<X>> looks like:

<<<1|2|X>>>

<P>One can also use the standard record notation for lists:

<<<'|'(1 '|'(2 X))>>>

<P>Further notational variant is allowed for lists whose elements
correspond to character codes. Lists written in this notation are
called <EM>strings</EM>, e.g.

<<<"OZ 3.0">>>

<P>is the list

<<<[79 90 32 51 46 48]>>>

<P>or equivalently

<<<[&amp;O &amp;Z &amp;  &amp;3 &amp;. &amp;0]>>>

<SECTION><TITLE>Virtual Strings</TITLE>
<P>A virtual string is a special tuple that represents a string with
virtual concatenation, i.e. the concatenation is performed when really
needed. Virtual strings are used for I/O with files, sockets, and
windows. All atoms, except <<nil>> and <<'#'>>, as well as numbers,
strings, or <<'#'>>-labeled tuples can be used to compose virtual
strings. Here is one example:

<<<123#"-"#23#" is "#100>>>

<P>represents the string

<<<"123-23 is 100">>>

<P CLASS=WARNING>For each data type discussed in section, there is a
corresponding module in the Mozart system. The modules define
operations on the corresponding data type. You may find more about
these operations in <REF.EXTERN TO="ozdoc:base">The Oz
Base Environment documentation</REF.EXTERN>

</CHAPTER>

