Language Reference/Basic Concepts/Scoping and Visibility - Revision history

Thomas Linder Puls: review

2025-08-20T13:19:16Z

review

← Older revision		Revision as of 15:19, 20 August 2025
Line 3:		Line 3:
	All names (identifiers) in Visual Prolog are syntactically divided into two major groups:		All names (identifiers) in Visual Prolog are syntactically divided into two major groups:

	*Constant names (starting with a lowercase letter)		* Constant names (starting with a lowercase letter)
	*Variable names (starting with an uppercase letter or an underscore)		* Variable names (starting with an uppercase letter or an underscore)

	Constant names (identifiers) are divided into the following categories:		Constant names (identifiers) are divided into the following categories:

	* Type names (i.e. domains and interfaces).		* Type names (i.e., domains and interfaces)
	* Domain carriers (i.e. classes and interfaces).		* Domain carriers (i.e., classes and interfaces)
	* Names without parentheses (i.e. constants, fact variables of non-function type and nullary-functors).		* Names without parentheses (i.e., constants, fact variables of non-function type, and nullary-functors)
	* Value returning names of arity N (i.e. functions, functors and fact-variables of function type).		* Value-returning names of arity N (i.e., functions, functors, and fact variables of function type)
	* Non-value-returning names of arity N (i.e. predicates, facts and fact variables of predicate type).		* Non-value-returning names of arity N (i.e., predicates, facts, and fact variables of predicate type)

	Visual Prolog ~~demands~~ that names do not conflict at the point of declaration, ~~because then it would~~ be ~~impossible to solve~~ the ~~conflict at~~ point of ~~usage~~. Declarations can only conflict if they are in the same scope, because qualification ~~with scope~~ can ~~be used to solve the conflict~~. A name in one category can never ~~be in~~ conflict with a name in another category, but ~~as we shall see~~ a single declaration ~~might~~ place a name in several categories.		Visual Prolog requires that names do not conflict at the point of declaration; otherwise, conflicts cannot be resolved at the point of use. Declarations can only conflict if they are in the same scope, because scope qualification can resolve conflicts. A name in one category can never conflict with a name in another category, but a single declaration can place a name in several categories.

	==== Packages ====		==== Packages ====

	~~The~~ basic units of code organization ~~accepted~~ in Visual Prolog ~~are packages~~. ~~We use packages in Visual Prolog to organize~~ and structuring things. The use of packages ensures homogeneity in structuring principles among different projects. Packages define the standard for tool structuring and ease sharing source code among projects.		Packages are the basic units of code organization in Visual Prolog. They group related interfaces and classes.

	~~The package is a collection of several grouped together interfaces and classes. The package provides some common name to all these interfaces and classes.~~ Each declaration or implementation of ~~each~~ interface or class ~~from~~ a package is placed in a separate file. Each filename ~~(of these files) coincides with~~ the ~~name of a~~ class ~~or an interface~~ that ~~is declared~~ or ~~implemented in this file~~. All package files are stored in the ~~same separate~~ package directory~~. (If a package contains sub-packages, then they~~ are ~~placed~~ in subdirectories of ~~the package~~ directory.)		Each declaration or implementation of an interface or class in a package is placed in a separate file. Each filename matches the interface or class that it declares or implements. All package files are stored in the package directory; subpackages are stored in subdirectories of that directory.

	~~The concept of packages is used for grouping together several linked interfaces and classes.~~ Packages can ~~play a role of some~~ class ~~library~~. ~~Packages~~ can ~~be used~~ in your program instead of ~~direct~~ placing all used interfaces and classes ~~into your~~ program.		Packages can act as class libraries. You can include packages in your program instead of placing all used interfaces and classes directly in the program.

	~~The accepted in Visual Prolog structure of~~ packages and ~~how packages should be~~ included ~~into~~ projects ~~are~~ described in the ~~VDE part of this help.~~ (~~See~~ '''Creating a Package''' in '''Creating New Project Items'''.)		How packages are structured and included in projects is described in the IDE documentation (see '''Creating a Package''' in '''Creating New Project Items''').

	==== Visibility, Shadowing, and Qualification ====		==== Visibility, Shadowing, and Qualification ====

	Most ~~of the~~ scoping rules ~~are already mentioned~~ above~~. This~~ section ~~will complete~~ the picture.		Most scoping rules were introduced above; this section completes the picture.

	An interface definition, a class declaration and a class implementation are scopes (scopes cannot be nested). An implementation (privately) extends the scope of the corresponding class declaration. ~~The visibility~~ is the same '''everywhere''' in a scope. ~~This does especially mean that~~ '''no matter where''' ~~in a scope~~ something is declared, it is visible in the '''whole''' scope.		An interface definition, a class declaration, and a class implementation are scopes (scopes cannot be nested). An implementation (privately) extends the scope of the corresponding class declaration. Visibility is the same '''everywhere''' in a scope; i.e., '''no matter where''' something is declared in the scope, it is visible in the '''whole''' scope.

	Public names from supported interfaces and super-classes are directly (i.e. without qualification) available inside a scope~~, if it~~ is unambiguous ~~where they come from~~. It is illegal to use a name whose origin is ambiguous. ~~All ambiguities~~ in predicate calls can be removed by qualifying the predicate name with the class name (e.g. <vp>cc::p</vp>).		Public names from supported interfaces and super-classes are directly (i.e., without qualification) available inside a scope when their origin is unambiguous. It is illegal to use a name whose origin is ambiguous. Ambiguities in predicate calls can be removed by qualifying the predicate name with the class name (e.g., <vp>cc::p</vp>).

	This qualification is also used to qualify calls of object member predicates of super-classes on the ''current'' object.		This qualification is also used to qualify calls to object member predicates of super-classes on the ''current'' object.

	Visual Prolog has the following shadowing hierarchy:		Visual Prolog has the following shadowing hierarchy:

	* Local		* Local
	* ~~Super~~-~~class & opened scopes~~		* Opened scopes and super-classes

	Opened scopes have the same status as ~~super-classes, so in the sequel we will just say~~ super-classes.		Opened scopes have the same status as super-classes. Local declarations shadow declarations in opened scopes. If two or more opened scopes contain conflicting declarations, you can only access them by using qualification.

	~~The hierarchy means that a local declaration will~~ shadow ~~a super-class declaration. But there is no shadowing between super-classes; all super-classes have equal preference~~. If two or more ~~super classes~~ contain conflicting declarations ~~then these declarations~~ can only ~~be accessed~~ by ~~means of~~ qualification.

	{{Example\|Assume the interface <vp>ixx</vp> and the classes <vp>aa</vp> and <vp>bb</vp>:		{{Example\|Assume the interface <vp>ixx</vp> and the classes <vp>aa</vp> and <vp>bb</vp>:
Line 102:		Line 100:
	end implement cc		end implement cc
	</vip>		</vip>
	Since <vp>cc</vp> inherits <vp>aa</vp> all ~~the~~ predicates in the interface <vp>ixx</vp> are ~~also~~ visible in <vp>cc</vp>. Likewise the <vp>open bb</vp> ~~qualification will make~~ all predicates in <vp>bb</vp> visible in <vp>cc</vp>.}}		Since <vp>cc</vp> inherits <vp>aa</vp>, all predicates in the interface <vp>ixx</vp> are visible in <vp>cc</vp>. Likewise, the <vp>open bb</vp> directive makes all predicates in <vp>bb</vp> visible in <vp>cc</vp>.}}
	<noinclude>{{LanguageReferenceSubarticle\|Basic Concepts/Scoping & Visibility}}</noinclude>		<noinclude>{{LanguageReferenceSubarticle\|Basic Concepts/Scoping & Visibility}}</noinclude>

Thomas Linder Puls: Header level

2025-08-19T15:10:15Z

Header level

← Older revision		Revision as of 17:10, 19 August 2025
Line 26:		Line 26:
	The accepted in Visual Prolog structure of packages and how packages should be included into projects are described in the VDE part of this help. (See '''Creating a Package''' in '''Creating New Project Items'''.)		The accepted in Visual Prolog structure of packages and how packages should be included into projects are described in the VDE part of this help. (See '''Creating a Package''' in '''Creating New Project Items'''.)

	===== Visibility, Shadowing, and Qualification =====		==== Visibility, Shadowing, and Qualification ====

	Most of the scoping rules are already mentioned above. This section will complete the picture.		Most of the scoping rules are already mentioned above. This section will complete the picture.

Thomas Linder Puls: Header level

2025-08-19T15:09:56Z

Header level

← Older revision		Revision as of 17:09, 19 August 2025
Line 16:		Line 16:
	Visual Prolog demands that names do not conflict at the point of declaration, because then it would be impossible to solve the conflict at point of usage. Declarations can only conflict if they are in the same scope, because qualification with scope can be used to solve the conflict. A name in one category can never be in conflict with a name in another category, but as we shall see a single declaration might place a name in several categories.		Visual Prolog demands that names do not conflict at the point of declaration, because then it would be impossible to solve the conflict at point of usage. Declarations can only conflict if they are in the same scope, because qualification with scope can be used to solve the conflict. A name in one category can never be in conflict with a name in another category, but as we shall see a single declaration might place a name in several categories.

	===== Packages =====		==== Packages ====

	The basic units of code organization accepted in Visual Prolog are packages. We use packages in Visual Prolog to organize and structuring things. The use of packages ensures homogeneity in structuring principles among different projects. Packages define the standard for tool structuring and ease sharing source code among projects.		The basic units of code organization accepted in Visual Prolog are packages. We use packages in Visual Prolog to organize and structuring things. The use of packages ensures homogeneity in structuring principles among different projects. Packages define the standard for tool structuring and ease sharing source code among projects.

Thomas Linder Puls: Header level

2025-08-19T15:09:42Z

Header level

← Older revision		Revision as of 17:09, 19 August 2025
Line 1:		Line 1:
	===== Name Categories =====		==== Name Categories ====

	All names (identifiers) in Visual Prolog are syntactically divided into two major groups:		All names (identifiers) in Visual Prolog are syntactically divided into two major groups:

Thomas Linder Puls: moved Language Reference/Basic Concepts/Scoping & Visibility to Language Reference/Basic Concepts/Scoping and Visibility

2017-07-04T08:17:47Z

moved Language Reference/Basic Concepts/Scoping & Visibility to Language Reference/Basic Concepts/Scoping and Visibility

← Older revision	Revision as of 10:17, 4 July 2017
(No difference)

Thomas Linder Puls: Visibility, Shadowing, and Qualification (example)

2017-07-04T08:15:23Z

Visibility, Shadowing, and Qualification (example)

← Older revision		Revision as of 10:15, 4 July 2017
Line 45:		Line 45:
	The hierarchy means that a local declaration will shadow a super-class declaration. But there is no shadowing between super-classes; all super-classes have equal preference. If two or more super classes contain conflicting declarations then these declarations can only be accessed by means of qualification.		The hierarchy means that a local declaration will shadow a super-class declaration. But there is no shadowing between super-classes; all super-classes have equal preference. If two or more super classes contain conflicting declarations then these declarations can only be accessed by means of qualification.

	{{Example\|Assume the interface <vp>aa</vp> and ~~the class~~ <vp>~~aa_class~~</vp>:		{{Example\|Assume the interface <vp>ixx</vp> and the classes <vp>aa</vp> and <vp>bb</vp>:
	<vip>interface aa		<vip>
	predicates		interface ixx
	p1 : ~~() procedure~~ ().
	p2 : ~~() procedure~~ ().		predicates
	p3 : ~~() procedure~~ ().		p1 : ().
	end interface		p2 : ().
	class ~~aa_class~~ : aa		p3 : ().
	end class~~</vip>~~
	~~Also assume the~~ class ~~<vp>bb_class</vp>:~~		end interface ixx
	~~<vip>class bb_class~~
	predicates		%========================
	p3 : ~~() procedure~~ ().
	p4 : () ~~procedure~~ ().		class aa : ixx
	end class ~~bb_class~~</vip>		end class aa
	In ~~the~~ context ~~of these classes~~ consider the implementation of a class <vp>~~cc_class~~</vp>
	<vip>implement ~~cc_class~~ inherits ~~aa_class~~		%========================
	open ~~bb_class~~
	~~predicates~~		class bb
	p2 ~~: () procedure~~ ().
	p5 : () ~~procedure~~ ().		predicates
	clauses		p3 : ().
	new() :-		p4 : ().
	p1(), % ~~aa_class~~::p1		p5 : ().
	p2(), % cc::p2 (shadows ~~aa_class~~::p2)
	~~aa_class~~::p2(), % ~~aa_class~~::p2		end class bb
	p3(), % Illegal ambiguous call: ~~aa_class~~::p3 or ~~bb_class~~::p3		</vip>
	~~aa_class~~::p3(), % ~~aa_class~~::p3
	~~bb_class~~::p3(), % ~~bb_class~~::p3		The class <vp>aa</vp> creates objects of type <vp>ixx</vp>, whereas the class <vp>bb</vp> does not create objects at all.
	p4(), % ~~bb_class~~::p4
	p5(), % cc::p5		In this context consider the implementation of a class <vp>cc</vp>:
	end implement ~~cc_class~~</vip>}}
			<vip>
			implement cc inherits aa
			open bb

			clauses
			p2(). % reimplementation of ixx::p2

			predicates
			p5 : ().
			clauses
			p5().

			clauses
			new() :-
			p1(), % aa::p1
			p2(), % cc::p2 (shadows aa::p2)
			aa::p2(), % aa::p2
			p3(), % Illegal ambiguous call: aa::p3 or bb::p3
			aa::p3(), % aa::p3
			bb::p3(), % bb::p3
			p4(), % bb::p4
			p5(). % cc::p5 (shadows bb::p5)

			end implement cc
			</vip>
			Since <vp>cc</vp> inherits <vp>aa</vp> all the predicates in the interface <vp>ixx</vp> are also visible in <vp>cc</vp>. Likewise the <vp>open bb</vp> qualification will make all predicates in <vp>bb</vp> visible in <vp>cc</vp>.}}
	<noinclude>{{LanguageReferenceSubarticle\|Basic Concepts/Scoping & Visibility}}</noinclude>		<noinclude>{{LanguageReferenceSubarticle\|Basic Concepts/Scoping & Visibility}}</noinclude>

Thomas Linder Puls: subarticle

2013-02-12T09:18:58Z

subarticle

← Older revision		Revision as of 11:18, 12 February 2013
Line 77:		Line 77:
	p5(), % cc::p5		p5(), % cc::p5
	end implement cc_class</vip>}}		end implement cc_class</vip>}}
	<noinclude>~~[[Category:Language Reference Subarticle]]~~</noinclude>		<noinclude>{{LanguageReferenceSubarticle\|Basic Concepts/Scoping & Visibility}}</noinclude>

Thomas Linder Puls: Iine

2012-10-25T15:42:34Z

Iine

← Older revision		Revision as of 17:42, 25 October 2012
Line 77:		Line 77:
	p5(), % cc::p5		p5(), % cc::p5
	end implement cc_class</vip>}}		end implement cc_class</vip>}}

	<noinclude>[[Category:Language Reference Subarticle]]</noinclude>		<noinclude>[[Category:Language Reference Subarticle]]</noinclude>

Thomas Linder Puls: Example Template

2012-10-24T11:55:00Z

Example Template

← Older revision		Revision as of 13:55, 24 October 2012
Line 45:		Line 45:
	The hierarchy means that a local declaration will shadow a super-class declaration. But there is no shadowing between super-classes; all super-classes have equal preference. If two or more super classes contain conflicting declarations then these declarations can only be accessed by means of qualification.		The hierarchy means that a local declaration will shadow a super-class declaration. But there is no shadowing between super-classes; all super-classes have equal preference. If two or more super classes contain conflicting declarations then these declarations can only be accessed by means of qualification.

	''Example''		{{Example\|Assume the interface <vp>aa</vp> and the class <vp>aa_class</vp>:

	Assume the interface <vp>aa</vp> and the class <vp>aa_class</vp>:
	<vip>interface aa		<vip>interface aa
	predicates		predicates
Line 78:		Line 76:
	p4(), % bb_class::p4		p4(), % bb_class::p4
	p5(), % cc::p5		p5(), % cc::p5
	end implement cc_class</vip>		end implement cc_class</vip>}}

	<noinclude>[[Category:Language Reference Subarticle]]</noinclude>		<noinclude>[[Category:Language Reference Subarticle]]</noinclude>

Thomas Linder Puls: Categorized

2008-10-29T19:54:07Z

Categorized

← Older revision		Revision as of 21:54, 29 October 2008
Line 79:		Line 79:
	p5(), % cc::p5		p5(), % cc::p5
	end implement cc_class</vip>		end implement cc_class</vip>

			<noinclude>[[Category:Language Reference Subarticle]]</noinclude>