Grammar
Japanese version
Contents
In LiLFeS the following is treated as token
- TypeName, Feature Name, Variable Name
- Numeric (integer and float)
- String (characters within "")
- Comment
- ?-, :- and <-
- Symbol (any 1 byte non alpha-numeric character) but for the above 5
Comments can be used in the following ways:
- %/* ... are comments ... */ (nesting not
possible)
- % till end of line will be treated as comment (excluding above
case)
As mentioned in chapter 3, all constants in LiLFeS are treated as TYPE. Also
predicates becomes subtype of pred. Alphanueric, whitespace, 2 byte characters
etc... can be used as strings, only quote needs to be delimited with '
- starting with lower case alphanumeric or 2 byte character
- alphanumeric, underscore(_) or 2 byte character
to use quote ', delimit it with '
Types that can be used in Program |
head_subject_schema
Tokyo Univ
'ABC' % type ABC
'Good morning!' % type Good morning!
'don''t' % type don't
|
Feature Name can be any string which is alphanumeric (valid characters are
alphanumeric, underscope, 2byte char). Like Type, strings within quotes can also
be used. it is necessary to add \ suffix. White space or newline character is
not allowed between the name and \.
Features that can be used in
Program |
F1\
feature\
'Let me see...'\
|
variable can be any string starting with $ (valid characters are
uppercase alphanumeric, underscore, 2 byte char)
Variables that can be used in
Program |
X
$VAR
$1
$VARIABLE
|
All predicates and types have to be defined as supertype. It is not possible to
use the same name more than two times.
Type <-
[ supertype1
, supertype2,cc
] + [
Feature1\ Type1(Priority1),
Feature2\ Type2(
Priority2),...].
|
Type Definition |
(1) | p <- pred.
| (2) | Square <- [Rectangle , Rhombus].
| (3) | employ <- [act] + [EMPLOYER\, EMPLOYEE\].
| (4) | book <- [bot] + [TITLE\string(-5),AUTHOR\name(10),PUBLISHER\co(20)]. | |
|
Left hand side of <- is the new type. The right hand side can be
multiple supertypes separated by +. If the supertype is only one then [] can be
omitted (e.g., 1). It is possible to separate multiple types by comma (e.g.,
2). If feature are to be added, its priority can be omitted. if Type is
omitted it will be treated as bot. the order of features will be alphabetical if
priority is omitted. e.g., 3 it will be EMPLOYEE, EMPLOYER. In e.g., 4 it will
be TITLE, AUTHOR, PUBLISHER based on the priority specified.
Feature can be defined as shown:
FEATURE AVM
|
employ & EMPLOYER\"John" & EMPLOYEE\"Mary"
|
|~employ ~|
| EMPLOYEE:"Mary" |
|_EMPLOYER:"John"_|
|
Racing Horse & Name\ Dance in the Dark &
Lineage\ 'Hail to Reason' &
Father\'(Stud Horse & Name\Sunday Science &
Lineage\ 'Hail to Reason')
|
|~Racing Horse ~|
| Name: Dance in the Dark |
| Lineage:Hail to Reason |
| |~Stud Horse ~| |
| Father:| Name :Sunday Science | |
| |_Lineage: Hail to Reason_| |
|_Mother:bot _|
|
Unification is
(Type or variable) = (Type
or variable)
|
Unification Result
|
X = man
| X can be used instead of Man
|
Equilateral = Rectangle
| Not possible
|
$Horse & Lineage\$1 = Father\Lineage\$1
| $Horse will be horse with same Father and Lineage
|
Predicate is same syntax as in Prolog
Predicate Name( Param1, Param2, ...) |
Same syntax as Prolog
(1) | Predicate .
|
(2) | Predicate :-
structure1 , structure2,.... .
|
(3) | :- structure .
|
query
?-
structure1
, structure2 ,....
?- is not a prompt. Unlike Prolog, LiLFeS is not interpreted.
difference in ?- & :- |
> p <- [pred]. q <- [pred].
> a <- [bot]. b <- [bot].
> p(a,b).
> p(X,X) :- q(X).
> p(b).
> ?- p(X,Y), q(Y).
X: a
Y: b
Enter ';' for more choices, otherwise press ENTER --> ;
X: [$1] b
Y: [$1] ...
Enter ';' for more choices, otherwise press ENTER --> ;
no
(in case of query, variable's values are shown, inputting ; will backtrack)
> :- p(X,Y), X=Y, q(Y), print(Y).
b
(direct execution, nothing is displayed. only print output is shown
and thus one can print only selected variables but cannot backtrack)
|
An example Module in LiLFeS is shown below:
LiLFeS Program |
:- module("list:reverse").
:- module_interface.
% read required modules
:- ensure_loaded("append").
% make the scope global
reverse <- [pred].
:- module_implementation.
% make the scope local
reverse_sub <- [pred].
% Predicate Definition
reverse_sub([], $X, $X).
reverse_sub([$A|$B], $C, $D) :-
reverse_sub($B, [$A|$C], $D).
reverse($X, $Y) :-
reverse($X, [], $Y).
|
module, module_interface, module_implementation etc. are predefined keywords and
are also referred to as directives, which can be used to write programs.
First the module name has to be specified in the file. The module name can be
anything, but the "/" in file path is to be converted to
":". For example, if LILFES_PATH is ~/lilfes/ Cand module is ~/lilfes/list/reverse.lil
then the module name will be list:reverse.
Next is the module_interface which
defines the global scope of the module. for example reverse predicate is
global. This can be accessed from other modules without module path i.e., list:reverse.
Finally
is the module_implementation which defines the local scope of the modules. In
order to view reverse_sub, the full path has to be specified such as
list:reverse:reverse_sub.
In order to use predicates from other modules,
use ensure_loaded directive to load the module. In the above example,
list:append module is loaded and all predicates defined in that module can be
used in this program. ensure_loaded can be used both in module_interface
or module_implementation.
List
List can be defined as: (list subtype)
[Element1
, Element2 , ...]
|
[Head |
Tail List]
|
Numeric
integer, float subtype
String
String is any character enclosed within " " is of string subtype.
Don't care
variables starting with underscore (_) are treated as Don't care and
will always succeed in unification. Hence predicates which are not referred to
can be preceded by _ to ignore them. The unification part is exactly same as
trying to unify with bot.
Inference
, is AND ; is OR
p(a) = q(x), q(y) ; r(z).
will become:
p(a) = q(x), q(y).
p(a) = r(z).
if
Condition1 , Condition2
, ... -> Predicate on success; Predicate
on failure
|
P :- Q -> R ; S.
will be treated as
P :- Q , ! , R.
P :- S.
if |
> p <- [pred].
> check <- [pred].
> a <- [bot].
> b <- [bot].
> p(a).
> check(X) :- p(X) -> strprintln("succeed") ; strprintln("failed").
> ?- check(a).
succeed
; (Current occupation: 9 heap, 3 stack, 10 trail cell(s), 39 instructions)
yes
> ?- check(b).
failed
; (Current occupation: 9 heap, 3 stack, 8 trail cell(s), 62 instructions)
yes
|
Negative
Like Prolog, using \+, the failure of a predicate can be negated to success
Negative |
> p <- [pred].
> a <- [bot].
> b <- [bot].
> p(a).
> ?- \+ p(a).
; (Current occupation: 15 heap, 23 stack, 16 trail cell(s), 101 instructions)
no
> ?- \+ p(b).
; (Current occupation: 11 heap, 3 stack, 10 trail cell(s), 122 instructions)
yes
|
Unification not possible cases
It is possible to allow unification not possible cases by using \= which
is opposite of = , and can be used when unification fails. Note,
the left hand side value and \= should have a white space. If there is no white
space, it will be treated as feature.
Unification not possible |
> mammal <- bot.
> birl <- bot.
> cat <- mammal.
> ?- mammal \= cat.
; (Current occupation: 10 heap, 20 stack, 16 trail cell(s), 12 instructions)
no
> ?- mammal \= bird.
; (Current occupation: 10 heap, 3 stack, 12 trail cell(s), 27 instructions)
yes
|
Prev: Types and Features
Next: Error Messages
Table of Contents
LiLFeS Documents
LiLFeS Home Page
Tsujii Lab.