Modula-2 Reloaded

A Modern Typesafe & Literate Programming Notation

Site Menu

Project

Specification

Implementation

Recommendations

Reference

Needs Updating

Work in Progress

Wastebasket

Wiki Manual

edit SideBar

Associative Array Types

WiP.AssociativeArrayTypes History

Hide minor edits - Show changes to output

2015-09-16 14:08 by trijezdci -
Added lines 1-2:
!!! === This page is now outdated ===
Restore
2010-04-09 17:54 by benjk -
Changed line 76 from:
PROCEDURE [FOR] nextValue ( dict : Dictionary; VAR key : ARRAY OF CHAR; value : <valueType> );
to:
PROCEDURE [FOR] nextValue ( dict : Dictionary; VAR key : ARRAY OF CHAR; VAR value : <valueType> );
Restore
2010-04-09 17:52 by benjk -
Changed lines 76-77 from:
PROCEDURE [FOR] nextValue ( dict : Dictionary; VAR key : ARRAY OF CHAR ) : <valueType>;
to:
PROCEDURE [FOR] nextValue ( dict : Dictionary; VAR key : ARRAY OF CHAR; value : <valueType> );
Added lines 83-84:

Example: [[WiP/TypeSampleCollection]]
Restore
2010-04-09 17:31 by benjk -
Changed line 76 from:
PROCEDURE [FOR] nextValue ( dict : Dictionary; key : ARRAY OF CHAR ) : <valueType>;
to:
PROCEDURE [FOR] nextValue ( dict : Dictionary; VAR key : ARRAY OF CHAR ) : <valueType>;
Restore
2010-04-09 17:30 by benjk -
Changed line 11 from:
*obtain entry count: [@entryCount := LENGTH(dict);@] or [@entryCount := COUNT(dict);@]
to:
*obtain entry count: [@entryCount := COUNT(dict);@]
Deleted lines 27-36:

!!!!@@LENGTH@@ or @@COUNT@@

Regardless of how associative array types would be constructed, the user syntax to obtain the number of entries stored in an associative array would either repurpose the existing pervasive function @@LENGTH@@ or it would require a new pervasive function @@COUNT@@.

[@entryCount := LENGTH(dict);@]

[@entryCount := COUNT(dict);@]

The latter would certainly be clearer. A pervasive function @@COUNT@@ could also be useful in combination with enumeration and @@SET@@ types.
Restore
2010-04-09 17:28 by benjk -
Added line 10:
*iterate over all entries: [@FOR item IN dict DO ... END;@]
Added lines 85-86:

PROCEDURE [FOR] nextValue ( dict : Dictionary; key : ARRAY OF CHAR ) : <valueType>;
Restore
2010-04-09 14:58 by benjk -
Changed lines 107-118 from:
[@DEFINITION MODULE PatriciaTrie;

TYPE PatriciaTrie = OPAQUE; (* any unspecified opaque type is considered a collection *)

TYPE PatriciaTrie = OPAQUE DICTIONARY; (* alternatively this, or ... *)

TYPE PatriciaTrie = DICTIONARY; (* another possible alternative *)

TYPE PatriciaTrie = OPAQUE COLLECTION; (* yet another alternative *)

TYPE PatriciaTrie = COLLECTION; (* yet another alternative *)
to:
[@DEFINITION MODULE SearchTree;

TYPE SearchTree = OPAQUE; (* any unspecified opaque type is considered a collection *)

TYPE SearchTree = OPAQUE DICTIONARY; (* alternatively this, or ... *)

TYPE SearchTree = DICTIONARY; (* another possible alternative *)

TYPE SearchTree = OPAQUE COLLECTION; (* yet another alternative *)

TYPE SearchTree = COLLECTION; (* yet another alternative *)
Changed line 121 from:
END PatriciaTrie.@]
to:
END SearchTree.@]
Restore
2010-04-09 13:27 by benjk -
Deleted lines 97-98:

to introduce a new reserved word @@DICTIONARY@@ or @@COLLECTION@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that make them indistinguishable from the built in variant.
Restore
2010-04-09 13:07 by benjk -
Changed line 105 from:
TYPE Dictionary = COLLECTION OF ValueType;@]
to:
TYPE Dictionary = COLLECTION OF ValueType; (* alternative *)@]
Restore
2010-04-09 13:06 by benjk -
Changed line 97 from:
The built in type constructor would be the convenient general use tool, like @@CARDINAL@@, @@INTEGER@@ and @@REAL@@ for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined @@BCD@@, @@COMPLEX@@ and vector types are for numerics.
to:
The built in type constructor would be the convenient general use tool, like @@CARDINAL@@, @@INTEGER@@ and @@REAL@@ for numerics, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for more specialised uses, just like library defined @@BCD@@, @@COMPLEX@@ and vector types are for numerics.
Restore
2010-04-09 13:02 by benjk -
Changed line 99 from:
to introduce a new reserved word @@DICTIONARY@@ or @@COLLECTION@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that makes them indistinguishable from the built in variant.
to:
to introduce a new reserved word @@DICTIONARY@@ or @@COLLECTION@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that make them indistinguishable from the built in variant.
Restore
2010-04-09 13:00 by benjk -
Changed lines 40-41 from:
Associative array types could be constructed by extending the @@ARRAY@@ type constructor syntax and semantics. In any case it is assumed that the retrieval key for associative arrays will always be of type @@ARRAY OF CHAR@@.
to:
Associative array types could be constructed by extending the @@ARRAY@@ type constructor syntax and semantics. In any case it is assumed that the retrieval key for associative arrays will always be of type @@ARRAY@@ @@OF@@ @@CHAR@@.
Changed line 97 from:
The built in type constructor would be the convenient general use tool, like @@CARDINAL@@, @@INTEGER@@ and @@REAL@@ for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined BCD, complex and vector types are for numerics.
to:
The built in type constructor would be the convenient general use tool, like @@CARDINAL@@, @@INTEGER@@ and @@REAL@@ for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined @@BCD@@, @@COMPLEX@@ and vector types are for numerics.
Restore
2010-04-09 12:59 by benjk -
Changed line 97 from:
The built in type constructor would be the convenient general use tool, like CARDINAL, INTEGER and REAL for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined BCD, complex and vector types are for numerics.
to:
The built in type constructor would be the convenient general use tool, like @@CARDINAL@@, @@INTEGER@@ and @@REAL@@ for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined BCD, complex and vector types are for numerics.
Restore
2010-04-09 12:58 by benjk -
Changed lines 59-60 from:
Another alternative would be ...
to:
Other alternatives would be ...
Changed lines 65-67 from:
but these would require a new reserved word.
to:
[@TYPE Dictionary = COLLECTION OF ValueType;@]

any of these would require a new reserved word.
Restore
2010-04-09 12:55 by benjk -
Changed lines 97-98 from:
to introduce a new reserved word @@ASSOCIATIVE@@ or @@DICTIONARY@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that makes them indistinguishable from the built in variant.
to:
to introduce a new reserved word @@DICTIONARY@@ or @@COLLECTION@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that makes them indistinguishable from the built in variant.
Changed lines 101-102 from:
[@TYPE Dictionary = DICTIONARY OF ValueType;@]
to:
[@TYPE Dictionary = DICTIONARY OF ValueType;

TYPE Dictionary = COLLECTION OF ValueType;@]
Added lines 114-117:

TYPE PatriciaTrie = OPAQUE COLLECTION; (* yet another alternative *)

TYPE PatriciaTrie = COLLECTION; (* yet another alternative *)
Restore
2010-04-09 12:48 by benjk -
Changed line 103 from:
Library defined variant ...
to:
Library defined complement ...
Restore
2010-04-09 12:47 by benjk -
Changed line 101 from:
[@TYPE Dictionary = DICTIONARY OF Employee;@]
to:
[@TYPE Dictionary = DICTIONARY OF ValueType;@]
Restore
2010-04-09 12:46 by benjk -
Changed lines 99-100 from:
The builtin associative array constructor could use a new reserved word ...
to:
Builtin associative array constructor ...
Changed line 103 from:
and the library variant could use the same reserved word to declare the new type as a collection type so that the compiler can make sense of the bindings supplied ...
to:
Library defined variant ...
Restore
2010-04-09 12:44 by benjk -
Deleted line 111:
Restore
2010-04-09 12:43 by benjk -
Changed lines 107-109 from:
TYPE PatriciaTrie = OPAQUE DICTIONARY; (* either this *)

TYPE PatriciaTrie = DICTIONARY; (* or this, without OF *)
to:
TYPE PatriciaTrie = OPAQUE; (* any unspecified opaque type is considered a collection *)

TYPE PatriciaTrie = OPAQUE DICTIONARY; (* alternatively this, or ... *)

TYPE PatriciaTrie = DICTIONARY; (* another possible alternative *)
Restore
2010-04-09 12:35 by benjk -
Changed lines 93-94 from:
The best solution might be to introduce a new reserved word @@ASSOCIATIVE@@ or @@DICTIONARY@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that makes them indistinguishable from the built in variant.
to:
The best solution might be a combined approach.

The built in type constructor would be the convenient general use tool, like CARDINAL, INTEGER and REAL for numeric types, and library defined collection types that use bindings to provide the same syntax as used with the built in variant would be for specialised uses, just like library defined BCD, complex and vector types are for numerics.

to introduce a new reserved word @@ASSOCIATIVE@@ or @@DICTIONARY@@ to facilitate the ease of use of a builtin type constructor whilst at the same time allow library defined abstract data types to define bindings that makes them indistinguishable from the built in variant.

The builtin associative array constructor could use a new reserved word ...
Added lines 103-104:
and the library variant could use the same reserved word to declare the new type as a collection type so that the compiler can make sense of the bindings supplied ...
Changed lines 107-109 from:
TYPE PatriciaTrie = OPAQUE DICTIONARY;
to:
TYPE PatriciaTrie = OPAQUE DICTIONARY; (* either this *)

TYPE PatriciaTrie = DICTIONARY; (* or this, without OF *)
Restore