Home

Language

Syntactic Sugar

Types

Rationale

Design Patterns

Origins

FAQ

Libraries

Future plans

Contact:

mczard@poczta.onet.pl

Design Patterns

The Harpoon language is only a tool and as such can be used properly or not. This section describes how to design data structures correctly in typical situations.

List of Sections Design Pattern

When you need a collection of named entities, first solution that comes to mind is to use record. This however can be an improper decision. Records should be used only to group values describing a single entity, such as a book or other stuff that would typically be contained in one row of a table in relational model.

A different solution should be used for applications similar to the one known from the windows .ini files, where descriptions are organized in sections - i.e. when there is an open set of named entities, each of which could be used separately. In such situations, in Harpoon, one should use a list of tagged descriptions:

.ini	.hrp
[Language] Name = English [Ocr Setting] Resolution = 0 Document Size = 2 [Scan Setting] Scan Mode = 1 Resolution = 0 Path = C:\windows\twain_32	Scanner { Language( name = "English" ) OcrSetting( resolution = 0 document_size = 2 ) ScanSetting( scan_mode = 1 resolution = 0 path = "C:\\windows\\twain_32" ) }

Header-Body Design Pattern

In programming languages there are many constructs consisting from a header and a body - for example conditional loops and definitions of functions and classes. This schema can be mirrored in Harpoon by using a pair connected with a colon:

C++	.hrp
while ( k != 0 ) { ... }	while ( k != 0 ): { ... }
if ( is_lowercase(s) ) printf(s);	if is_lowercase(s) : printf(s)

Note:

Assuming the construct is contained in a list, the joining colon could actually be removed, although it would split the construct into two separate entities, which would have to be interpreted as a single one on some higher level.