Presenters - Revision history

Thomas Linder Puls: expand native

2019-07-01T13:43:10Z

expand native

← Older revision		Revision as of 15:43, 1 July 2019
Line 151:		Line 151:
	</vip>		</vip>

	The <vp>expand</vp> alternative it used to provide a string <vp>Presentation</vp> for an "non-atomic" value. The value will be presented as <vp>Presentation</vp> and will expand it as it would expand the <vp>Term</vp>. The ~~debuger~~ also ~~obtains~~ the type from <vp>Term</vp>. The <vp>expand</vp> alternative could for example be used for a functor term containing date and time fields like year, month, date, hour and minute; the <vp>Presentation</vp> would be a readable format of the date/time and the <vp>Term</vp> would be the functor term. The presentation will be the readable format, and the debugger will provide an expansion that contains the individual fields (year, etc).		The <vp>expand</vp> alternative it used to provide a string <vp>Presentation</vp> for an "non-atomic" value. The value will be presented as <vp>Presentation</vp> and will expand it as it would natively expand the <vp>Term</vp>. The debugger also in some cases obtain the type from <vp>Term</vp>. The <vp>expand</vp> alternative could for example be used for a functor term containing date and time fields like year, month, date, hour and minute; the <vp>Presentation</vp> would be a readable format of the date/time and the <vp>Term</vp> would be the functor term. The presentation will be the readable format, and the debugger will provide an expansion that contains the individual fields (year, etc).

	==== enclose ====		==== enclose ====

Thomas Linder Puls: vip code

2018-03-19T11:00:38Z

vip code

← Older revision		Revision as of 13:00, 19 March 2018
Line 217:		Line 217:
	There are three kinds of <vp>fieldPresentation</vp>'s:		There are three kinds of <vp>fieldPresentation</vp>'s:

			<vip>
	domains		domains
	fieldPresentation =		fieldPresentation =
Line 222:		Line 223:
	fp_string(string Presentation);		fp_string(string Presentation);
	fp_childOnly(string Name, subLazy Sub).		fp_childOnly(string Name, subLazy Sub).
			</vip>

	The <vp>fp</vp> alternative has a field <vp>Name</vp> and a lazy sub-presentation <vp>Sub</vp> of the field itself. The field <vp>Name</vp> is used by the debugger for labeling the presentation, but it is not used when writing the presentation. <vp>Sub</vp> will be used by the debugger for the corresponding value and it will also be used in when writing the presentation.		The <vp>fp</vp> alternative has a field <vp>Name</vp> and a lazy sub-presentation <vp>Sub</vp> of the field itself. The field <vp>Name</vp> is used by the debugger for labeling the presentation, but it is not used when writing the presentation. <vp>Sub</vp> will be used by the debugger for the corresponding value and it will also be used in when writing the presentation.

Thomas Linder Puls: released

2017-08-09T20:47:38Z

released

← Older revision		Revision as of 22:47, 9 August 2017
Line 1:		Line 1:
	~~{{Template:NonReleased}}~~

	Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attached to a domain and can be used to write (i.e. "present") the values of that domain in a more meaningful way.		Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attached to a domain and can be used to write (i.e. "present") the values of that domain in a more meaningful way.

Thomas Linder Puls: caution

2017-05-02T14:26:04Z

caution

← Older revision		Revision as of 16:26, 2 May 2017
Line 108:		Line 108:

	Notice however that the predicate should not be declared; stating the attribute implicitly implies the predicate declaration.		Notice however that the predicate should not be declared; stating the attribute implicitly implies the predicate declaration.

			==== Cautions ====

			Since presenters are used in the debugging process it is very important that they are kept simple, stateless and efficient. Especially:

			* They should be efficient; long running calculations will affect debug performance.
			* They shoud not have or depend on side-effects; during debugging the presenters may be calculated any number of times in any order.
			* They may not acquire exclusive access to resources (critical sections, mutexes, etc): that may end up blocking the entrire debugging process.
			* They should not start or depend on other threads

	=== Presenter Domain ===		=== Presenter Domain ===

Thomas Linder Puls: typo

2017-05-02T13:00:40Z

typo

← Older revision		Revision as of 15:00, 2 May 2017
Line 1:		Line 1:
	{{Template:NonReleased}}		{{Template:NonReleased}}

	Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is ~~attched~~ to a domain and can be used to write (i.e. "present") the values of that domain is a more meaningful way.		Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attached to a domain and can be used to write (i.e. "present") the values of that domain in a more meaningful way.

	{{Example\|A map object from the class <vp>mapM_redBlack</vp> is written as the address of the object. So this code:		{{Example\|A map object from the class <vp>mapM_redBlack</vp> is written as the address of the object. So this code:
Line 10:		Line 10:
	M:set(1, "a"),		M:set(1, "a"),
	stdio::writef("M = %\n", M).</vip>		stdio::writef("M = %\n", M).</vip>
	will ~~write~~ simply write the address of the map object:		will simply write the address of the map object:
	<pre>		<pre>
	M = 01757F78		M = 01757F78
Line 33:		Line 33:
	[[Image:presenter-variables.png]]}}		[[Image:presenter-variables.png]]}}

	As you can see ~~int he~~ example above the presenter not only affect the writing of the map object it also alters the way it is expanded in the window. The map above is actually an object that contains a fact with a red-black-tree which contains the actual mapping of <vp>1</vp> to <vp>"a"</vp>, but all these details are hidden in favor of a much more semantically meaningful presentation.		As you can see in the example above the presenter not only affect the writing of the map object it also alters the way it is expanded in the window. The map above is actually an object that contains a fact with a red-black-tree which contains the actual mapping of <vp>1</vp> to <vp>"a"</vp>, but all these details are hidden in favor of a much more semantically meaningful presentation.

	If you need access to the low-level expansion of something in the debugger you can right click the value and switch on "Native View". This will affect all values of that type; which will get an extra child node which contains the "native" (i.e. unpresented) view of the value.		If you need access to the low-level expansion of something in the debugger you can right click the value and switch on "Native View". This will affect all values of that type; which will get an extra child node which contains the "native" (i.e. unpresented) view of the value.
Line 43:		Line 43:
	Any text-mode <vp>outputStream</vp> can present a value of a domains that has presenters attached. This can be done either by calling the predicate <vp>present</vp> or by using <vp>"%p"</vp> in a format string. The <vp>present</vp> predicate works like the <vp>write</vp> predicate except that all values are written using the attached presenters rather than in the default/built-in way. Likewise, a value corresponding to <vp>"%p"</vp> in a format string will be written using the attached presenters.		Any text-mode <vp>outputStream</vp> can present a value of a domains that has presenters attached. This can be done either by calling the predicate <vp>present</vp> or by using <vp>"%p"</vp> in a format string. The <vp>present</vp> predicate works like the <vp>write</vp> predicate except that all values are written using the attached presenters rather than in the default/built-in way. Likewise, a value corresponding to <vp>"%p"</vp> in a format string will be written using the attached presenters.

	<vp>string::~~preset~~(V)</vp> will return a string with the presentation of <vp>V</vp>, and <vp>string::format</vp> will (and any other predicate that uses format strings) can also use <vp>"%p"</vp> for presentation.		<vp>string::present(V)</vp> will return a string with the presentation of <vp>V</vp>, and <vp>string::format</vp> will (and any other predicate that uses format strings) can also use <vp>"%p"</vp> for presentation.

	As mentioned below presenters works on (deeply) nested terms regardless of whether the surrounding term has attached presenters or not.		As mentioned below presenters works on (deeply) nested terms regardless of whether the surrounding term has attached presenters or not.
Line 56:		Line 56:
	stdio::writef("T = %p\n", T).		stdio::writef("T = %p\n", T).
	</vip>		</vip>
	The tuple domain does not have a presenter attached, so it is written like an ordinary functor term. Maps and sets on the other hand ~~does~~ have presenters attached so they will be written using them. The output looks like this:		The tuple domain does not have a presenter attached, so it is written like an ordinary functor term. Maps and sets on the other hand do have presenters attached so they will be written using them. The output looks like this:
	<pre>		<pre>
	T = tuple([1 -> "a", 7 -> "q"], ["A", "fence", "fox", "jumped", "over", "the"])		T = tuple([1 -> "a", 7 -> "q"], ["A", "fence", "fox", "jumped", "over", "the"])
Line 180:		Line 180:
	</vip>		</vip>

	The <vp>structured</vp> alternative is used for structured terms. The <vp>SubPresenter</vp> will produce a number of sub-presentations. When writing the presentation each of the sub-presentations will be written ~~dilimited~~ by <vp>Delimiter</vp>. Typically the delimiter is ", " so that the resulting presentations are written comma separated. This is for example used when presenting sets.		The <vp>structured</vp> alternative is used for structured terms. The <vp>SubPresenter</vp> will produce a number of sub-presentations. When writing the presentation each of the sub-presentations will be written delimited by <vp>Delimiter</vp>. Typically the delimiter is ", " so that the resulting presentations are written comma separated. This is for example used when presenting sets.

	To avoid calculating very large/deep presentations during debugging, the structured presenters uses lazy evaluation of the sub-presenters. This is achieved by letting the presentation contain functions that can calculate the presentation rarther than the presentation itself. So during debugging the presentation of a term will only expand to a certain level. Inside that level there will be functions the debugger can choose to call if further expansion is required. But if further expansion is not required the calculation will be skipped. For this reason the debugger can deal efficiently with very large terms. On the downside this complicates the coding of presenters somewhat.		To avoid calculating very large/deep presentations during debugging, the structured presenters uses lazy evaluation of the sub-presenters. This is achieved by letting the presentation contain functions that can calculate the presentation rarther than the presentation itself. So during debugging the presentation of a term will only expand to a certain level. Inside that level there will be functions the debugger can choose to call if further expansion is required. But if further expansion is not required the calculation will be skipped. For this reason the debugger can deal efficiently with very large terms. On the downside this complicates the coding of presenters somewhat.
Line 216:		Line 216:
	fp_childOnly(string Name, subLazy Sub).		fp_childOnly(string Name, subLazy Sub).

	The <vp>fp</vp> alternative has a field <vp>Name</vp> and a lazy sub-presentation <vp>Sub</vp> of the field itself. The field <vp>Name</vp> is used by the debugger for ~~labling~~ the presentation, but it is not used when writing the presentation. <vp>Sub</vp> will be used by the debugger for the corresponding value and it will also be used in when writing the presentation.		The <vp>fp</vp> alternative has a field <vp>Name</vp> and a lazy sub-presentation <vp>Sub</vp> of the field itself. The field <vp>Name</vp> is used by the debugger for labeling the presentation, but it is not used when writing the presentation. <vp>Sub</vp> will be used by the debugger for the corresponding value and it will also be used in when writing the presentation.

	The <vp>fp_string</vp> will only appear in the writing of the presentation, the debugger will not include an <vp>fp_string</vp> when expanding the presentation.		The <vp>fp_string</vp> will only appear in the writing of the presentation, the debugger will not include an <vp>fp_string</vp> when expanding the presentation.
Line 239:		Line 239:
	</vip>		</vip>

	To simplify the ~~explanaition~~ it is worth expanding the <vp>fieldPresenter</vp> and <vp>subPresentation</vp> definitions into the <vp>subLazy</vp> domain:		To simplify the explanation it is worth expanding the <vp>fieldPresenter</vp> and <vp>subPresentation</vp> definitions into the <vp>subLazy</vp> domain:

	<vip>		<vip>
Line 274:		Line 274:
	).		).
	</vip>		</vip>
			Basically there are two named fields which are terms (a "Name" field which has the value <vp>"a"</vp> and a "Value" field which have the value <vp>1</vp>), when written these fields are comma separated <vp>", "</vp> and finally they are enclosed in <vp>"p("</vp> and <vp>")"</vp>.
	Basically there are two named fields which are terms (a "Name" field which has the value <vp>"a"</vp> and a "Value" field which have the value <vp>1</vp>), when written these fields are comma separated <vp>", "</vp> and finally they are enclosed in <vp>"p("</vp> and <vp>")"</vp>.		Basically there are two named fields which are terms (a "Name" field which has the value <vp>"a"</vp> and a "Value" field which have the value <vp>1</vp>), when written these fields are comma separated <vp>", "</vp> and finally they are enclosed in <vp>"p("</vp> and <vp>")"</vp>.

	The writing will look like a normal functor term <vp>p("a", 1)</vp> and the debugger is able expand it to the two named fields.		The writing will look like a normal functor term <vp>p("a", 1)</vp> and the debugger is able expand it to the two named fields.

	It is worth noticing that this presentation will give the same result (both when writing and in ~~teh~~ debugger):		It is worth noticing that this presentation will give the same result (both when writing and in the debugger):
	<vip>		<vip>
	constants		constants
Line 294:		Line 295:
	</vip>		</vip>

	A <vp>sequence</vp> sub-presenter is used for presenting values have a varying number of sub-presentations, for ~~eaxmple~~ a set can have from any number of sub-presentations (including none at all). When the debugger expands a <vp>sequence</vp> presentation it will at first only show a limited number of the sub-presentations. That way the debugger will not suddenly be expanding a set that contains millions of elements. Expanding such a large set is rarely interesting, since it will both take a very long time to do and since it will also give result that is too large to comprehend anyway.		A <vp>sequence</vp> sub-presenter is used for presenting values have a varying number of sub-presentations, for example a set can have from any number of sub-presentations (including none at all). When the debugger expands a <vp>sequence</vp> presentation it will at first only show a limited number of the sub-presentations. That way the debugger will not suddenly be expanding a set that contains millions of elements. Expanding such a large set is rarely interesting, since it will both take a very long time to do and since it will also give result that is too large to comprehend anyway.

	The <vp>sequencePresenter</vp> is defined like this:		The <vp>sequencePresenter</vp> is defined like this:
Line 385:		Line 386:
	}}		}}

	~~Sould~~ you need/want to enclose ~~your~~ a comma separated sequence in something else than "[" and "]", then you can use the predicate <vp>presenter::mkPresenter_setElements</vp> instead.		Should you need/want to enclose a comma separated sequence in something else than "[" and "]", then you can use the predicate <vp>presenter::mkPresenter_setElements</vp> instead.

	{{Example\|This would enclose a list in "{" and "}":		{{Example\|This would enclose a list in "{" and "}":
Line 397:		Line 398:
	}}		}}

	Similar predicates ~~exists~~ for map-like constructions:		Similar predicates exist for map-like constructions:

	<vip>		<vip>

Thomas Linder Puls: typo

2017-05-02T12:47:44Z

typo

← Older revision		Revision as of 14:47, 2 May 2017
Line 1:		Line 1:
	{{Template:NonReleased}}		{{Template:NonReleased}}

	Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attched to a domain an can be used to write (i.e. "present") the values of that domain is a more meaningful way.		Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attched to a domain and can be used to write (i.e. "present") the values of that domain is a more meaningful way.

	{{Example\|A map object from the class <vp>mapM_redBlack</vp> is written as the address of the object. So this code:		{{Example\|A map object from the class <vp>mapM_redBlack</vp> is written as the address of the object. So this code:

Thomas Linder Puls: initial

2017-05-02T12:24:07Z

initial

New page

{{Template:NonReleased}}

Visual Prolog can write any value, but often the printed version of a value is not very useful. An object is for example written as the address of the object. A presenter is a predicate that is attched to a domain an can be used to write (i.e. "present") the values of that domain is a more meaningful way.

{{Example|A map object from the class <vp>mapM_redBlack</vp> is written as the address of the object. So this code:
<vip>
clauses
run() :-
M = mapM_redBlack::new(),
M:set(1, "a"),
stdio::writef("M = %\n", M).</vip>
will write simply write the address of the map object:
<pre>
M = 01757F78
</pre>
The using <vp>"%p"</vp> in the format string instead of just <vp>"%"</vp> will write the map using the presenter that is attached to the map classes:
<vip>
clauses
run() :-
M = mapM_redBlack::new(),
M:set(1, "a"),
stdio::writef("M = %p\n", M).
</vip>
and then the output will look like this:
<pre>
M = [1 -> "a"]
</pre>
}}

Presenters are however also used in the debugging process to provide more expressive/simpler presentations in the Variables Window (and in similar contexts).

{{Example|The map above will appear like this in the Variables Window:
[[Image:presenter-variables.png]]}}

As you can see int he example above the presenter not only affect the writing of the map object it also alters the way it is expanded in the window. The map above is actually an object that contains a fact with a red-black-tree which contains the actual mapping of <vp>1</vp> to <vp>"a"</vp>, but all these details are hidden in favor of a much more semantically meaningful presentation.

If you need access to the low-level expansion of something in the debugger you can right click the value and switch on "Native View". This will affect all values of that type; which will get an extra child node which contains the "native" (i.e. unpresented) view of the value.

The notion of presenters is relatively complex due to the double role it serves both as plain text presentation and as recipe for expansion in the debugger. Subsequently, it can be difficult to write a good presenter for a complex domain.

=== Presenting ===

Any text-mode <vp>outputStream</vp> can present a value of a domains that has presenters attached. This can be done either by calling the predicate <vp>present</vp> or by using <vp>"%p"</vp> in a format string. The <vp>present</vp> predicate works like the <vp>write</vp> predicate except that all values are written using the attached presenters rather than in the default/built-in way. Likewise, a value corresponding to <vp>"%p"</vp> in a format string will be written using the attached presenters.

<vp>string::preset(V)</vp> will return a string with the presentation of <vp>V</vp>, and <vp>string::format</vp> will (and any other predicate that uses format strings) can also use <vp>"%p"</vp> for presentation.

As mentioned below presenters works on (deeply) nested terms regardless of whether the surrounding term has attached presenters or not.

{{Example|This code uses presenters for the writing <vp>T</vp>:
<vip>
clauses
run() :-
M = mapP_redBlack::new():insertList([tuple(7, "q"), tuple(1, "a")]),
S = setP_redBlack::new():insertList(["A", "fox", "jumped", "over" , "the", "fence"]),
T = tuple(M, S),
stdio::writef("T = %p\n", T).
</vip>
The tuple domain does not have a presenter attached, so it is written like an ordinary functor term. Maps and sets on the other hand does have presenters attached so they will be written using them. The output looks like this:
<pre>
T = tuple([1 -> "a", 7 -> "q"], ["A", "fence", "fox", "jumped", "over", "the"])
</pre>
The presentation of a set looks like a list, and the presentation of a string is quoted.
}}

=== Attaching presenters ===

If a presenter predicate has not been attached to a domain, then the domain will use a default presenter predicate instead. The default presenter predicate will present the value in the standard way (i.e. like <vp>write</vp>) however subterms will be presented using their presenter. So presenters works on deeply nested in values (regardless of whether the outer terms have presenters or not).

The presenter for a domain is a predicate which is attached to the domain using a <vp>presenter/1</vp> attribute in the domain definition:

{{Example|The predicate present_tree is attached as presenter to the tree domain like this:
<vip>
domains
tree =
empty;
node(tree L, string Value, tree R) [presenter(present_tree)].
</vip>}}

The presenter predicate is (i.e. must be) a function from a <vp>Value</vp> in the domain (i.e. <vp>Type</vp>) to a <vp>Presentation</vp>, as specified by the PFC domain <vp>presenter::presenter</vp>:

<vip>
domains
presenter{Type} = (Type Value) -> presentation Presentation.</vip>

{{Example|So the <vp>present_tree</vp> predicate must be declared like this:
<vip>
class predicates
present_tree : presenter::presenter{tree}.
</vip>
}}

Objects can also be presented. A presenter is attached by using the <vp>presenter/0</vp> attribute in the domain definition:

{{Example|To attach a presenter to <vp>myInterface</vp> you supply the <vp>presenter/0</vp> attribute:<vip>
interface myInterface
[presenter]
...
end interface myInterface
</vip>
}}

For objects the presenter predicate is always named <vp>presenter</vp> corresponding to this declaration (in the interface):

<vip>
predicates
presenter : () -> presenter::presentation Presentation.
</vip>

Notice however that the predicate should not be declared; stating the attribute implicitly implies the predicate declaration.

=== Presenter Domain ===

The <vp>presentation</vp> domain (also defined in the <vp>presenter</vp> class) looks like this:

<vip>
domains
presentation =
noExpand(string Presentation, any Term);
expand(string Presentation, any Term);
structured(string Delimiter, subPresenter SubPresenter);
enclose(string Opening, string Closing, presentation Presentation);
functor(functorDescr FunctorDescr, any* SubTerms).
</vip>

==== noExpand ====

<vip>
domains
presentation =
noExpand(string Presentation, any Term);
...
</vip>

The <vp>noExpand</vp> alternative is used to provide a string <vp>Presentation</vp> for an "atomic" value. The value will be presented as <vp>Presentation</vp> and the debugger will not show any children of the value. The <vp>Term</vp> is used by the debugger to obtain a type of the term. The <vp>noExpand</vp> alternative could for example be used for a number that represent a time; the <vp>Presentation</vp> would be a readable format of the time and the <vp>Term</vp> would be the "raw" time value. The presentation will be the readable format, and the debugger will not provide any expansion of the term (but Native View can be used to see the actual value).

==== expand ====

<vip>
domains
presentation =
expand(string Presentation, any Term);
...
</vip>

The <vp>expand</vp> alternative it used to provide a string <vp>Presentation</vp> for an "non-atomic" value. The value will be presented as <vp>Presentation</vp> and will expand it as it would expand the <vp>Term</vp>. The debuger also obtains the type from <vp>Term</vp>. The <vp>expand</vp> alternative could for example be used for a functor term containing date and time fields like year, month, date, hour and minute; the <vp>Presentation</vp> would be a readable format of the date/time and the <vp>Term</vp> would be the functor term. The presentation will be the readable format, and the debugger will provide an expansion that contains the individual fields (year, etc).

==== enclose ====

<vip>
domains
presentation =
...
enclose(string Opening, string Closing, presentation Presentation);
...
</vip>

The <vp>enclose</vp> is used to surround a presentation by <vp>Opening</vp> and <vp>Closing</vp> strings. This is for example used to surround the presentation of a set with "[" and "]" to result in a list-like presentation. The debugger simply consider the nested <vp>Presentation</vp>.

==== functor ====

<vip>
domains
presentation =
...
functor(functorDescr FunctorDescr, any* SubTerms).
</vip>
The <vp>functor</vp> alternative is specially designed to be used internally by the compiler runtime system, because the <vp>FunctorDescr</vp>'s are terms that are layed-out as contants by the compiler. The <vp>functor</vp> alternative will create a presentation that corresponds to a functor term which has <vp>SubTerms</vp> as sub-terms.
The alternative is partly redundant, because the same thing could have been expressed using <vp>structured</vp> and <vp>enclose</vp> alternatives.

==== structured ====

<vip>
domains
presentation =
...
structured(string Delimiter, subPresenter SubPresenter);
...
</vip>

The <vp>structured</vp> alternative is used for structured terms. The <vp>SubPresenter</vp> will produce a number of sub-presentations. When writing the presentation each of the sub-presentations will be written dilimited by <vp>Delimiter</vp>. Typically the delimiter is ", " so that the resulting presentations are written comma separated. This is for example used when presenting sets.

To avoid calculating very large/deep presentations during debugging, the structured presenters uses lazy evaluation of the sub-presenters. This is achieved by letting the presentation contain functions that can calculate the presentation rarther than the presentation itself. So during debugging the presentation of a term will only expand to a certain level. Inside that level there will be functions the debugger can choose to call if further expansion is required. But if further expansion is not required the calculation will be skipped. For this reason the debugger can deal efficiently with very large terms. On the downside this complicates the coding of presenters somewhat.

There are two kinds of <vp>subPresenter</vp>'s:

<vip>
domains
subPresenter =
fixed(fieldPresentation* FieldPresentations);
sequence(sequencePresenter Sequence).
</vip>

==== fixed (structured) ====

<vip>
domains
subPresenter =
fixed(fieldPresentation* FieldPresentations);
...
</vip>

used for presenting values that have a fixed number of "Field" sub-presentations. This could for example be the presentation of a certain functor alternative, since such a functor term has a certain (fixed) number of sub-terms. Which result in a fixed number of sub-presentations.

When the debugger expands a <vp>fixed</vp> presentation all the sub-presentations will be shown, because they are considered all part of the expanded term.

A <vp>fixed</vp> sub-presenter consist of a list of <vp>fieldPresentation</vp>'s each describing one of the fields.

There are three kinds of <vp>fieldPresentation</vp>'s:

domains
fieldPresentation =
fp(string Name, subLazy Sub);
fp_string(string Presentation);
fp_childOnly(string Name, subLazy Sub).

The <vp>fp</vp> alternative has a field <vp>Name</vp> and a lazy sub-presentation <vp>Sub</vp> of the field itself. The field <vp>Name</vp> is used by the debugger for labling the presentation, but it is not used when writing the presentation. <vp>Sub</vp> will be used by the debugger for the corresponding value and it will also be used in when writing the presentation.

The <vp>fp_string</vp> will only appear in the writing of the presentation, the debugger will not include an <vp>fp_string</vp> when expanding the presentation.

The <vp>fp_childOnly</vp> does not take part in the writing of the presentation, it will only be used as a child by the debugger.

So to summarize, the <vp>fp_string</vp> alternative only show-up in the writing, the <vp>fp_childOnly</vp> only show-up as a child when the debugger expands the presentation and finally the <vp>fp</vp> will both show up in the writing and as a child.

The <vp>subLazy</vp> domain is a little complex:

<vip>
domains
subLazy = subPresentation{fieldPresenter}.

domains
fieldPresenter = function{presentation}.

domains
subPresentation{Presentation} =
pres(Presentation Presentation);
term(any Term).
</vip>

To simplify the explanaition it is worth expanding the <vp>fieldPresenter</vp> and <vp>subPresentation</vp> definitions into the <vp>subLazy</vp> domain:

<vip>
domains
subLazy =
pres(function{presentation} Presentation);
term(any Term).
</vip>

So effectively a <vp>subLazy</vp> term is either (<vp>pres</vp>) a function returning a presentation or a (<vp>term</vp>) term. The function need only be called if the presentation is required and likewise the term need only be presented if its presentation is required.

{{Example|Consider the following functor domain and a constant of that domain:
<vip>
domains
pair = p(string Name, integer Value).

constants
t : pair = p("a", 1).
</vip>

This term would be a sensible presentation of <vp>t</vp> (we assume that the <vp>presenter</vp> scope is <vp>open</vp>):
<vip>
constants
t_presentation : presentation =
enclose("p(", ")",
structured(", ",
fixed(
[
fp("Name", term(toAny("a"))),
fp("Value", term(toAny(1)))
]
)
)
).
</vip>
Basically there are two named fields which are terms (a "Name" field which has the value <vp>"a"</vp> and a "Value" field which have the value <vp>1</vp>), when written these fields are comma separated <vp>", "</vp> and finally they are enclosed in <vp>"p("</vp> and <vp>")"</vp>.

The writing will look like a normal functor term <vp>p("a", 1)</vp> and the debugger is able expand it to the two named fields.

It is worth noticing that this presentation will give the same result (both when writing and in teh debugger):
<vip>
constants
t_presentation2 : presentation = functor(functorDescr("p", ["Name", "Value"]), [toAny("a"), toAny(1)]).
</vip>
}}

==== sequence (structured) ====

<vip>
domains
subPresenter =
...;
sequence(sequencePresenter Sequence).
</vip>

A <vp>sequence</vp> sub-presenter is used for presenting values have a varying number of sub-presentations, for eaxmple a set can have from any number of sub-presentations (including none at all). When the debugger expands a <vp>sequence</vp> presentation it will at first only show a limited number of the sub-presentations. That way the debugger will not suddenly be expanding a set that contains millions of elements. Expanding such a large set is rarely interesting, since it will both take a very long time to do and since it will also give result that is too large to comprehend anyway.

The <vp>sequencePresenter</vp> is defined like this:

<vip>
domains
sequencePresenter = function_nd{sub Presentation}.

domains
sub = subPresentation{presentation}.

domains
subPresentation{Presentation} =
pres(Presentation Presentation);
term(any Term).
</vip>

Here it is worth expanding <vp>subPresentation</vp> into the <vp>sub</vp> domain:

<vip>
domains
sequencePresenter = function_nd{sub Presentation}.

domains
sub =
pres(presentation Presentation);
term(any Term).
</vip>

So a <vp>sequencePresenter</vp> is a nondeterministic predicate that returns presentations (<vp>pres</vp>) or terms (<vp>term</vp>). The nondeterministic predicate can be used to achieve the step-wise expansion of the children (though it is necessary to start from scratch to obtain more children).

{{Example|Consider a list term:
<vip>
constants
l : integer* = [1, 2, 3, 4, 5, 6, 7].
</vip>
This term would be a sensible presentation of that <vp>l</vp>:
<vip>
class facts
l_presentation : presentation :=
enclose("[", "]",
structured(", ",
sequence(
{ () = term(toAny(V)) :-
V in [1, 2, 3, 4, 5, 6, 7]
}))).
</vip>
Basically the presentation is a sequence presentation with a nondeterministic predicate that returns the <vp>term</vp>s in the list, these sub presentations are comma separated <vp>", "</vp> and finally enclosed in "[" and "]".
}}

=== Support predicates ===

The predicate <vp>outputStreamSupport::writePresentation</vp> can be used to test (or use) presenters which are not attached to a domain.

{{Example|This predicate will write a presentation to <vp>stdio::outputStream</vp>:
<vip>
class predicates
test : (presenter::presentation P).
clauses
test(P) :-
outputStreamSupport::writePresentation(stdio::outputStream, P),
stdio::nl.
</vip>
}}

These predicates (in the <vp>presenter</vp> class):
<vip>
predicates
present : presenter{any Any}.
present_native : presenter{any Any}.

predicates
present_term : presenter{Type}.
present_term_native : presenter{Type}.
</vip>
Will return the presentation of terms.

The <vp>presenter</vp> class contains a number of support predicates that can be used to make presenters.

The predicate <vp>presenter::mkPresenter_set</vp> will create a "set" presentation (i.e. comma separated and enclosed in "[" and "]") of the elements returned by a nondeterministic predicate.

{{Example|This would be a sensible presenter for the list domain:
<vip>
class predicates
presenter_list : presenter{list{A}}.
clauses
presenter_list(List) = mkPresenter_set({ = V :- V in List }).
</vip>
The list domain does however already have such a presenter, and besides that it would be impossible to state an attribute for the list domain, because it is predefined.
}}

Sould you need/want to enclose your a comma separated sequence in something else than "[" and "]", then you can use the predicate <vp>presenter::mkPresenter_setElements</vp> instead.

{{Example|This would enclose a list in "{" and "}":
<vip>
class predicates
presenter_list_brace : presenter{list{A}}.
clauses
presenter_list_brace(List) = enclose("{", "}", mkPresenter_setElements({ = V :- V in List })).
</vip>
The list domain does however already have such a presenter, and besides that it would be impossible to state an attribute for the list domain, because it is predefined.
}}

Similar predicates exists for map-like constructions:

<vip>
predicates
mkPresenter_map : (function_nd{tuple{Key, Value}} GetAll_nd) -> presentation Map.
mkPresenter_mapElements : (string MapSymbol, function_nd{tuple{Key, Value}} GetAll_nd) -> presentation Map.
</vip>

The <vp>MapSymbol</vp> is inserted between the key and value; in <vp>mkPresenter_map</vp> it is <vp>" -> "</vp>.