Truly Visual Polymorphic Algebraic Data Structures through Maramafication

12/14/2018 ∙ by Chide Groenouwe, et al. ∙ 0

This paper presents a so-called maramafication of an essential part of functional programming languages such as Haskell or Clean: the construction of fully polymorphic well-typed algebraic data structures based on type definitions with at most one type parameter. As such, this work extends our previous work, in which only a very limited form of polymorphism was present. Maramafication means the design of visual 'twins' of existing programming constructs using spatial metaphors rooted in common sense or inborn spatial intuition, to achieve self-explanatoriness. This is, among others, useful to considerably reduce the gap between programmers and non-programmers in the creation of programs, for educational purposes, for inclusion of non-typical programmers and for invoking enthusiasm among non-programmers.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 7

page 9

page 11

page 19

page 21

page 22

page 24

page 29

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

It would be highly beneficial if non-programmers could co-program software applications. The Marama-paradigm, as introduced in previous work, is a paradigm that is intended to considerably reduce the gap between programmers and non-programmers. The basis of the Marama-paradigm consists of designing ‘twins’ of programming constructs using metaphors rooted in common sense or inborn intuition, making the constructs almost entirely self-explanatory. This work has coined the term internal semantics for this purpose: the semantics of constructs is evident without an external definition. This may lower the threshold for non-programmer participation. Other application areas of maramafication include education and fostering an inclusive society. For example, some dyslexics may have a latent talent for programming that never surfaces in a world dominated by textual programming languages. Some authors have argued that these people would be a great asset to the programmer’s community, because they believe there is a correlation between dyslexia and the capability to think more creatively than the average.

This work coins the term maramafication for this design process. In other words, if such a twin has been designed for a language construct from for example Clean [2] or Haskell [4], it has been ‘maramafied’. In the remainder of this article, the prefix ‘M-’ indicates ‘maramafied’, for example, an M-constructor, is a maramafied constructor.

Related work, among others in the field of visual general purpose programming languages, to the best of our knowledge, does not truly and fully employ this principle of internal semantics. Note that visualisation itself is not equal to having an internal semantics. Many ‘visual’ constructs occurring in visual programming languages are not self-explanatory. What is more, most of such languages do not even visualise most of the programming constructs. They are still ‘contaminated’ with many constructs of a textual nature. Typically, in such programming languages the truly ‘visual’ part consists of boxes connected with arrows, while the content of the boxes contains much textually expressed programming code, such as textually defined typing information and data-structures. Hence, these languages require the user to still largely move within the original not-so-accessible textual programming paradigm. The hardest parts to truly capture with internal semantics are, possibly unconsciously, left in a textual form. In this article, however, we cover such a hard and non-trivial part.

This paper focusses on a fragment of the ‘maramafication-challenge’: it presents a new way to (truly) visually represent fully polymorphic algebraic data structures (ADSs) as they occur in modern functional programming languages, and does so in line with the aforementioned paradigm. The design is modular: it can be adopted straightforwardly into any visual functional programming language.

ADS1[]ADS1[]s are designed in such a way that type consistency is entirely forced by the form of the M-constructs (maramafied constructs). In other words, a user of these constructs cannot create ill-typed values, simply because the ‘pieces will not fit’. In this sense, the approach in this paper is genuinely visual: the semantics of the visual blocks is embodied by their visual structure and spatial manipulation options, and does not require a definition by textual or spoken means. Hence, a beginner using the M-constructs can find out how to program with them, without any prior textual or spoken explanation about how these constructs work.

Another way to phrase it, is that the semantics of the visualisation of polymorphy and datastructures proposed in this paper solely relies on shared human intuition for manipulation of 3D objects.

In this article, the term spatial necessity is coined for the aforementioned property of the visual designs, the property that given the laws of mechanics (as far as they are intuitively understood by the majority of humans) it is only possible to construct something that is correct. An example of such a widely shared intuition on which the spatial necessity design paradigm can rely, is that most people from an already very young age will predict that a ball that is held in the air, and then let lose, will move downward.

The design covers ADSs based on algebraic data type definitions with at most one type-parameter (but is easily extensible with any number of type-parameters), can cope with polymorphic constructors, and can classify a given ADS polymorphically (through ‘typing statements’).

Section 2 presents the textual languages used to show the textual equivalences of the M-constructs. Section 5 introduces a predecessor to this work: Madawipol-: a maramafication of M-constructors that is already sufficiently expressive to deal adequately with recursively defined types [3]. However, Madawipol- does not yet support full parametric polymorphism. Section 5 introduces Madawipol-, an adaptation of Madawipol- that adds parametric polymorphism. Section 6 provides definitions of essential aspects of Madawipol-.

It is important to note that this paper explains the constructs primarily from the perspective of a programming language designer, the targeted readers of this article. The reader has to keep in mind that the targeted users of the language, however, will learn how the constructs work by a playful and wordless exposure to maramafied ADSs or parts thereof only. No textual explanations will be provided. Moreover, the users of the language will use an interactive 3D-editor. The static representation in this article, therefore, required some alternative ways to represent aspects of the design. It is important that the reader does not confuse these with the actual, and more ‘intuitive’, way the language will occur to the user.

2 Textual languages

This section presents the textual languages that are used in this article to show the textual equivalences of the M-constructs presented in this paper. Because the M-constructs covered in this paper only deal with a fragment of a modern functional programming language (FPL) such as Clean or Haskell, this article also defines a textual language that is (isomorphic to) the relevant fragment of such an FPL. The language is called Algepoly1. We suffice with introducing the textual languages by example, their semantics as identical to the corresponding parts of Clean.

2.1 Algepoly1

Example 1 (Algebraic Data Type Definitions).

The following Algebraic Data Type Definitions define a number of algebraic data types: ::WeekendDay = Sat — Sun ::Bool = True — False ::Colour = Red — Blue — Green ::List a = Cons a (List a) — Nil

Note that this paper does not cover a visual counterpart to algebraic data type definitions. However, it is important to include them in the textual language for explanatory and definitory purposes.

Example 2 (ADSs).

The following is a comma-separated list of ADSs: True, Blue, Cons True Nil, Red, Cons True (Cons True Nil).

In this paper it is important to be able to talk about algebraic data structures that are still under construction. For this purpose, we add the following construction.

Example 3 (unfinished ADSs).

In unfinished ADSs not all argument positions of constructors have been supplied with arguments, for example: Cons _(Cons True Nil), Cons Red (Cons Green _) The ‘_’ stands for an ‘empty spot’. Such an ‘_’ may only occur at the argument-position of a constructor application.

This paper also deals with polymorphic constructors. These normally do not occur in languages such as Clean as ‘stand-alone’ constructors. To be able to talk about them in isolation, Algepoly1 contains the following constructs.

Example 4.

The following statement: Cons:[List Bool] is in a spoken phrase expressed as “the ‘Cons’ of ‘List Bool’.”. Such a statement only makes sense in the context of an algebraic data type definition, in which the constructor has been defined. Lets assume that this algebraic data type definition is the one in example 1. Then this statement expresses that ‘Cons’ is the constructor that one would get by substituting ‘Bool’ for the type-parameter in the given algebraic data type definition. In this case that would be the ‘Cons’ with the following type: ‘Bool (List Bool) -> List Bool’. Another way to phrase it, is that it is the instance of ‘Cons’ with result-type ‘List Bool’.

Another instance of ‘Cons’ is Cons:[List (List a)] “the ‘Cons’ of List (List a).” This instance of ‘Cons’ is, clearly, polymorphic.

2.2 Algepoly1

For didactic purposes, it turned out to be useful to introduce a slight extension of the language Algepoly1: Algepoly1 (the ‘+’ stands for ‘too flexible’). It allows constructors to have any type, including the most general polymorphic result-type ‘a’ and non-polymorphic argument-types, or no results or arguments at all. (Hence, they are reminiscent of generalised algebraic data types [8].) Note that the language itself is not intended for use in a real language. It is ‘too flexible’ and would lead to type-technical and semantical difficulties. It serves as a way to create ‘minimal examples’ to demonstrate certain behaviours of M-constructors. Note that the notation of the type is written down in the opposite order of what is commonly used, which one can witness by the reversed direction of the arrow. The result type is written down first, then the arrow follows, and finally the argument types are provided. This has been done for convenience: the result and the arguments are now in the same order as they appear when the constructor is applied, both in the textual version as in the maramafied version.

The following defines Algepoly1 by means of examples.

Example 5.

The following definition: Red: Colour ¡- defines a constructor ‘Red’ that has no arguments and result type ‘Colour’. SimpleFemCons: ¡- Colour defines a constructor ‘SimpleFemCons’ that has one argument with type ‘Colour’, and that does not produce a result.

FlexiCons: a ¡- a defines a constructor with one argument with the most general polymorphic type ‘a’ and a result with the same type. More examples: PolyCons: SimpleType a ¡- a SimplePairCons: ¡- a a

3 Madawipol- by example

Madawipol-, created in our previous work, is a maramafication that covers ADSs based on algebraic data type definitions with at most one type parameter, and can cope with a limited form of polymorphic constructors: those without arguments [3]. This section suffices with defining Madawipol- by example, among other due to space limitations, but also because the successor Madawipol- is the focus of this paper. For an elaborate formal definition of Madawipol-, see [3]. Throughout the online version of this document, clicking any image shows an online high resolution version of it, which can be zoomed into. The reader is strongly recommended to follow these links to investigate the figures in much more detail. The same holds for many textual descriptions. For off-line readers there is an additional ‘appendix’-document that contains an enlarged version of each figure, either to print or to store locally. It is available from the same location as this article.

Figure 1 shows examples of the simplest possible ADSs: atomic ADSs. In particular, note the form of the joints. The values of type ‘Bool’ have the same joint-form, while ‘Sat’ has another. Every type-constructor has a unique form associated with it, its type-constructor form. In this case, ‘Bool’ corresponds with the triangle in the figure, and ‘WeekendDay’ with the pentagon in the figure. (The type-constructor forms have to comply with some additional conditions, these are covered in [3].) The square form around them is not explicitly part of the type. It is the alignment square, needed to align joints correctly when fitting them together.

= to —X[1,c,m]—X[1,c,m]—X[1,c,m]— & & True’ & ‘False’ & ‘Sat
Figure 1: Atomic algebraic data structures. Important: all images are clickable and lead to zoomable high resolution versions.

To provide examples of molecular ADSs (ADSs with constructors that take arguments), section 3 introduces all M-constructors that belong to the type ‘List Bool’ and ‘List (List Bool)’. Note that Madawipol- does not yet support polymorphism for constructors with arguments. Therefore, it can only provide non-polymorphic instantiations of ‘Cons’. M-Nil, however, is polymorphic. (Note that “M-Nil” is an example of the notation of specific M-constructors.) Hence, it can be shared among the different instantiations of ‘Cons’. This explains why there is only one M-Nil in section 3.

Note the forms of the three joints of M-Cons:[List Bool]. It has one male joint, that corresponds with the result-type ‘List Bool’, and two female joints, one corresponding to the type ‘Bool’, and the other to ‘List Bool’. The circle corresponds with the type-constructor ‘List’. It is an essential aspect of the design that joint-forms that correspond with a complex type, such as ‘List Bool’, are compositionally related to their textual form. The 2D projection of the joint-form along a line perpendicular to the bottom of the joint, is called the type-form. I.e. it is the 2D form one sees when viewing a joint along a line of sight that is perpendicular to the bottom of the joint. This is an adequate abstraction. After all, if one assumes that male and female joints have matching heights and depths, the only aspect that determines whether they fit is the type-form. The textual type can be read from the type-form by starting with the outermost form (skipping the alignment square) and then walking one’s way to the adjacent one, all the way down to the center form, while reading out loud the type-constructor that is associated with each form. The reader is invited to verify that all joints of M-Cons:[List (List Bool)] also comply with this structure. A polymorphic type, such as ‘List a’, is created by leaving the space within the innermost type-constructor form empty. The joint of M-Nil is an example.

Also note the form of the three joints of M-Cons:[List (List Bool)].

= to —X[1,c,m]X[1,c,m]—X[1,c,m]— & & & &  Cons:[List Bool]’ (2 perspectives)   & ‘Nil:[List a] & &  Cons:[List (List Bool)]’ (2 perspectives)   &
Figure 2: Several M-constructors.

Section 3 shows a number of molecular ADSs built with the M-constructors introduced so far. The reader can try to verify that all M-constructors indeed fit together, and lead to a well-typed result.

Madawipol- is type-safe. Figure 4 gives a simple example. The power of Madawipol-  however, lies in how it enforces type-safety of more complex types, such as types that consist of more than one type-constructor, polymorphic types, and recursively defined types. This is the non-trivial part of the design. With the compositional translation of textual types into type-forms, as illustrated in the aforementioned, every type can be translated into a type-form that behaves type-safely, and that reflects the relation between both. We challenge the reader to create a type-incorrect value with the M-constructors provided so far. For example, (s)he can try to: join the male joint of M-Cons:[List (List Bool)] with a female joint of M-Cons:[List Bool] (fails); M-True into M-Cons:[List (List Bool)] (fails). The reader can also add the M-constructors of other instantiations of ‘List a’, such as ‘List (List WeekendDay)’, and then try: male M-Cons:[List (List Bool)] into the side female joint of M-Cons:[List (List Sat))] (fails).

Polymorphic types are also type-safe: try fitting M-Nil into the side female joint of any instantiation of M-Cons (always succeeds); M-Nil into the top female joint of M-Cons:[List Bool] (fails).

= to —X[1,c,m]X[1,c,m]X[1,c,m]— & &   A maramafied value of type ‘List Bool’ (3 perspectives)   to —X[1,c,m]X[1,c,m]— &       A value of type ‘List (List Bool)’ (3 perspectives)  
Figure 3: Several values with a ‘List’-type.
Figure 4: Type-safety: ‘Weekendday’ does not fit into a list of booleans.

[3] contains more examples of Madawipol-.

4 Polymorphic surfaces

A part of Madawipol- consists of so called polymorphic surfaces. These surfaces do not exist as independent objects within Madawipol-, but are, among other things, integrated into polymorphic M-constructors. However, for clarity this section explains the polymorphic surfaces in isolation. The most central part of the explanations focus on the laws that govern the behaviour of the polymorphic surfaces. The reader is recommended to first try to guess what happens in the figures, and after that read the accompanying explanation.

Figure 5 shows a gray surface in the center of which a polymorphic surface  is attached. (Note that the figure has to be read as a comic strip.) has a side with a red colour (in the figure at the top-side) and a side with a blue colour (in the figure at the bottom-side). To demonstrate the behaviour of , a gray cylinder is moved into it. As can be seen in the figure, the part of that touches moves downwards with the cylinder. The part that is not touched by , however, moves in the opposite direction over the same distance. does not tear in the process, and remains attached to the gray surface. In that sense it behaves as an elastic surface.

Figure 5: A comic strip showing a polymorphic surface interacting with a cylinder, seen from three perspectives

Figure 6 demonstrates mimicking. A gray surface contains two polymorphic surfaces: (left) and (right). A cylinder is moved into . mimics the behaviour of .

Figure 6: Mimicking polymorphic surfaces interacting with a cylinder, seen from three perspectives

Figure 7 demonstrates that mimicking is confined to polymorphic surfaces attached to the same object. Each gray surface contains two polymorphic surfaces. However, only the polymorphic surface that is on the same gray surface, mimics the behaviour of the polymorphic surface that receives a cylinder.

Figure 7: Two pairs of polymorphic surfaces, interacting with a cylinder, seen from three perspectives. Each pair is connected to one, separate object.

Figure 8 shows two polymorphic surfaces. (left) and (right). ’s orientation is the opposite of . One can derive this from the orientation of the colours: in , red is on top, in it is on the bottom. mimics the behaviour of , and because of its orientation, the movement is also reversed with respect to the gray surface. Note that this figure is a natural consequence of the laws already exposed in previous figures. It does not introduce any new laws, but is included for clarity.

Figure 8: Mimicking polymorphic surfaces interacting with a cylinder, seen from three perspectives. The polymorphic surfaces are oriented reversed with respect to each other.

4.1 Differentiation of polymorphic surfaces

Some terminology is needed for explanations in the rest of this article. If a polymorphic surface is fully deformed it is differentiated. The opposite notion is ‘undifferentiated’. A polymorphic surface always starts in a fully undifferentiated state: a perfectly flat surface as indicated in the examples before. A polymorphic surface can also be partially differentiated, as will be shown in later examples. The parts of a polymorphic surface that are differentiated are called differentiated regions. The opposite notion is ‘differentiated region’. A part of a polymorphic surface that is differentiated as a consequence of mimicking another surface, is called a mimicking region.

If a region of a polymorphic surface is not mimicking another surface, nor being deformed by an object that is pushed into it then that region is called a free region. In the examples provided so far, each polymorphic surface started out as a completely free region, while no free regions were left once insertion of an object started. Note that the region of the polymorphic surface that moves in the opposite direction of the regions being touched by the inserted object, is not a free region either: although it does not touch the inserted object it is clearly being deformed.

4.2 Law: mimicking regions are rigid

A law that is not demonstrated in this article is that mimicking regions of a polymorphic surface behave like rigid (non-deformable) forms with respect to the objects onto which it exerts a force. As a consequence, if such a mimicking region exerts a force onto an undifferentiated region of another polymorphic surface, the latter will start to deform as well and become differentiated. Another consequence is that if the other surface is already differentiated, and does not have a matching form, the forms will not fit into each other and movement will halt.

4.3 Law: free regions return to an undifferentiated state

All examples provided thus far, also work in the reverse direction. When objects are taken out again, the polymorphic surfaces move back to their original position. These examples can simply be obtained by reading the comic strips in the reverse order. The underlying law is formulated as follows: free regions return to their undifferentiated state. In other words: any region of a polymorphic surface that is not being pushed by a shape, nor mimicking another surface, returns to its undifferentiated state.

4.4 Experimentation

Note that a quite extensive experimental study has been carried out to test the understandability of the laws mentioned in this section among secondary school students with promising results.

5 Madawipol- by example

As said, Madawipol- extends Madawipol- with complete parametric polymorphism, i.e. it also covers polymorphic M-constructors with arguments, such as ‘Cons:[List a]’.

For clarity, in some of the following examples the correspondence between parts of the visual and the textual representation is shown. It is essential to note that these are not put there for definitory purposes: for a user of Madawipol-

 the semantics is contained in the construction possibilities of the building blocks. The correspondence is merely put here to provide the reader of this paper, who is probably well-versed in textual functional languages, a quick insight into the fact that these visualisations indeed exhibit the same relevant behaviours as their textual counterparts.

The essential building block of the extension is formed by polymorphic surfaces, covered in section 4.

In Madawipol-, polymorphic surfaces are part of polymorphic M-constructors. For didactic purposes it easier to first illustrate important aspects of how they function within M-constructors in maramafications of the ‘flexible textual language’ Algepoly1. It allows ‘minimal examples’111https://en.wikipedia.org/wiki/Minimal_Working_Example to be more minimal.

For the sake of simplicity and the purpose of this article, the type-constructor forms in this section have been chosen such that 2D cross-sections provide all information needed. This simplifies the creation of examples in static 2D media, such as this article. These cross-sections, however, are not intended as viable alternatives for the 3D models. Among other things, it is harder to discern the different type-constructor forms in them. For example, the human visual apparatus will immediately recognise a circle that contains a triangle, as two separate objects with a distinct form, while the ‘ridges and edges’ in the 2D cross-sections give it much less to hold on. The users, however, will work with the 3D models.

To achieve the situation that 2D cross-sections contain all information needed, fig. 9 redefines the forms of several type-constructors that have been defined earlier. The latter can be interpreted as viewing a male joint along a line of sight that is perpendicular to the bottom of the joint. We remind the reader that in the electronic version of this document, each image contains clickable links that lead to much higher resolution versions of the image.

Colour Bool List
Figure 9: Several type-constructor forms.

Figure 10 provides a cross-sectional view on several M-constructors with these types. The cross-section is made such that it cuts halfway through each joint. Note the red and the blue lines indicating the orientation of each polymorphic surface. These lines, in reality have no thickness as they are part of the same surface. As a compromise, these parallel lines are drawn such that the center of the combined lines aligns with the real line. Specifically in later figures, where M-constructors are joined, and up to four lines stack up, this is a workable compromise.

In the remainder of this article, the prefix ‘M-’ indicates ‘maramafied’. For example, the M-constructor (maramafied constructor) of ‘FlexiCons’ from example 5 is indicated with M-‘FlexiCons’.

Before starting with the elucidating examples, fig. 10 provides an overview of all M-constructors used in the examples, for later reference.

M-Red M-SimpleFemCons M-FlexiCons M-PolyCons Colour <- <- Colour a <- a SimpleType a <- a M-True M-Cons M-SimplePairCons Bool <- List a <- a (List a) <- a a
Figure 10: Overview of M-constructors. Their name and type are written beneath them.

The rest of this section introduces the behaviours of these M-constructors by providing examples. It will indicate for each example whether it “introduces a new law”, or whether it merely “illustrates existing laws”. The latter type of examples should be perfectly predictable and are, among other things, added to allow the reader to verify his or her understanding.

5.1 Reverse reading of examples

Let the reader be reminded that all examples provided in the following sections also work in the reverse direction, following the law that has been explained in section 4.3.

5.2 Law: mimicking polymorphic surfaces (intra-M-constructor type-propagation)

(Implications of existing laws.) Section 5.2 demonstrates type propagation within a M-constructor, i.e. intra M-constructor type-propagation. Simply by following the laws of polymorphic surfaces from section 4, and the chosen forms of the joints, the type propagation takes place as expected in these examples. It first shows an M-FlexiCons (left) and an M-Red (right). The corresponding textual versions have been defined in example 5. The fixed male joint of M-Red moves into the (polymorphic) female joint of M-FlexiCons. As expected, the polymorphic surface in the male joint of M-FlexiCons mimics the polymorphic surface that is being manipulated: the one in the female joint. As a consequence of the inverted orientation of the polymorphic surface of the female joint with respect to the male joint, the form of the male joint will become the exact inverse of the female joint when it mimics the latter. The male joint of M-FlexiCons has now taken the exact shape of the male joint of M-Red. This is perfectly consistent with the typing information expressed in the textual versions of the constructors, and is a first step in illustrating how type-information propagates through M-constructors. Note that this also partially explains why an undifferentiated polymorphic surfaces is positioned halfway the joint, and why the polymorphic surface moves in two directions at the same time.

= to —X[1,c,m]—X[1,c,m]— &   M-FlexiCons:[a<-a] receives M-Red:[Colour<-].   &   M-SimpleFemCons:[<-Colour] receives M-FlexiCons:[a<-a])   &   M-SimplePairCons:[<-a a] receives M-Red:[Colour<-]  
Figure 11: Comic-strips demonstrating intra-M-constructor type-propagation.

The rest of section 5.2 illustrates that the intra-M-constructor propagation takes place as expected, whether it is propagation from a male joint to a female joint, from a female joint to a male joint, or from a female joint to a female joint.

5.3 Inter-M-constructor type propagation

(Illustrates existing laws.) Figure 12 shows how type-information propagates through several M-constructors: i.e. inter-M-constructor type propagation. M-Red moves into the right M-FlexiCons . The polymorphic surface at the left of , mimics the other one of . The right polymorphic surface of (the right ) touches the changing polymorphic surface, and responds by following the laws that were introduced in section 4. Therefore, it gets exactly the same shape as the changing polymorphic surface. The left polymorphic surface of mimics the right polymorphic surface of . This results in a final situation that is, type-wise, in perfect agreement with the textual counterparts of the M-constructors. The figure also demonstrates that mimicking regions of a polymorphic surface act as rigid objects (also see section 4.2).

= to —X[1,c,m]—
Figure 12: Two already joined M-FlexiConses receive an M-Red. The result’s textual equivalent is ‘FlexiCons (FlexiCons Red)’.

5.4 Law: scaling of polymorphic surfaces

(Introduces a new law.) Figure 13 demonstrates scaling of polymorphic surfaces. The polymorphic surface at the left () is smaller than the one at the right (). As expected, mimics

, however its vertical size is scaled down. The scaling factor is, in this case, equal to the ratio between the sizes of both polymorphic surfaces. This scaling process, a linear transformation to be precise, plays the central role in the maramafication of the application of type constructors (i.e. creating joints of types such as ‘

(SimpleType a)’ or ‘(SimpleType (List (SimpleType a)))’. For example, the joint that corresponds with ‘(SimpleType a)’ consists of an alignment square (the two outer ‘pins’), the type-constructor ‘SimpleType’ (the inner two ‘pins’), and the type parameter ‘a’ (the scaled down polymorphic surface). This will be explained in more detail in sections 6.3 and 6.2.

= to —X[1,c,m]—
Figure 13: PolyCons Red’.

5.5 Joining ‘super’- and ‘sub’types

(Introduces a new law.) Section 5.5 shows an example of joining polymorphic surfaces where the female joint is a strict super-type of the male joint. In other words, the types are different, yet unifiable. In the figure, a female joint with type ‘a’ is connected with a male joint with type ‘SimpleType a’. As one can see, the undifferentiated region of a polymorphic surface that meets an undifferentiated region of the polymorphic surface of the opposing joint, remains in an undifferentiated state. The rest of the polymorphic surface takes the shape of the opposing joint.

(Implications of existing laws.) It also demonstrates that the M-constructors can fully deal with recursively defined types. (These are types in which a type-constructor occurs both in the left-hand side and the right-hand side of the algebraic data type definition, such as in the definition of ‘PolyCons’.) The left-most joint takes the shape that corresponds with the type ‘SimpleType (SimpleType a)’. The reader is invited to verify that if yet another M-PolyCons would be inserted in the right M-PolyCons, it would lead to the left-most joint taking the form M-‘SimpleType (SimpleType (SimpleType a))’. The notation M-‘Type’ means the type-form of the given type.

Section 5.5 introduces an additional law.

= to —X[1,c,m]— PolyCons (PolyCons Red)
Figure 15: PolyCons (PolyCons Red)
Figure 16: Cons (Cons Red _) (Cons (Cons _ _) _)
Figure 17: M-True into M-‘a’.
Figure 14: PolyCons (PolyCons _)

4 Polymorphic surfaces

A part of Madawipol- consists of so called polymorphic surfaces. These surfaces do not exist as independent objects within Madawipol-, but are, among other things, integrated into polymorphic M-constructors. However, for clarity this section explains the polymorphic surfaces in isolation. The most central part of the explanations focus on the laws that govern the behaviour of the polymorphic surfaces. The reader is recommended to first try to guess what happens in the figures, and after that read the accompanying explanation.

Figure 5 shows a gray surface in the center of which a polymorphic surface  is attached. (Note that the figure has to be read as a comic strip.) has a side with a red colour (in the figure at the top-side) and a side with a blue colour (in the figure at the bottom-side). To demonstrate the behaviour of , a gray cylinder is moved into it. As can be seen in the figure, the part of that touches moves downwards with the cylinder. The part that is not touched by , however, moves in the opposite direction over the same distance. does not tear in the process, and remains attached to the gray surface. In that sense it behaves as an elastic surface.

Figure 5: A comic strip showing a polymorphic surface interacting with a cylinder, seen from three perspectives

Figure 6 demonstrates mimicking. A gray surface contains two polymorphic surfaces: (left) and (right). A cylinder is moved into . mimics the behaviour of .

Figure 6: Mimicking polymorphic surfaces interacting with a cylinder, seen from three perspectives

Figure 7 demonstrates that mimicking is confined to polymorphic surfaces attached to the same object. Each gray surface contains two polymorphic surfaces. However, only the polymorphic surface that is on the same gray surface, mimics the behaviour of the polymorphic surface that receives a cylinder.

Figure 7: Two pairs of polymorphic surfaces, interacting with a cylinder, seen from three perspectives. Each pair is connected to one, separate object.

Figure 8 shows two polymorphic surfaces. (left) and (right). ’s orientation is the opposite of . One can derive this from the orientation of the colours: in , red is on top, in it is on the bottom. mimics the behaviour of , and because of its orientation, the movement is also reversed with respect to the gray surface. Note that this figure is a natural consequence of the laws already exposed in previous figures. It does not introduce any new laws, but is included for clarity.

Figure 8: Mimicking polymorphic surfaces interacting with a cylinder, seen from three perspectives. The polymorphic surfaces are oriented reversed with respect to each other.

4.1 Differentiation of polymorphic surfaces

Some terminology is needed for explanations in the rest of this article. If a polymorphic surface is fully deformed it is differentiated. The opposite notion is ‘undifferentiated’. A polymorphic surface always starts in a fully undifferentiated state: a perfectly flat surface as indicated in the examples before. A polymorphic surface can also be partially differentiated, as will be shown in later examples. The parts of a polymorphic surface that are differentiated are called differentiated regions. The opposite notion is ‘differentiated region’. A part of a polymorphic surface that is differentiated as a consequence of mimicking another surface, is called a mimicking region.

If a region of a polymorphic surface is not mimicking another surface, nor being deformed by an object that is pushed into it then that region is called a free region. In the examples provided so far, each polymorphic surface started out as a completely free region, while no free regions were left once insertion of an object started. Note that the region of the polymorphic surface that moves in the opposite direction of the regions being touched by the inserted object, is not a free region either: although it does not touch the inserted object it is clearly being deformed.

4.2 Law: mimicking regions are rigid

A law that is not demonstrated in this article is that mimicking regions of a polymorphic surface behave like rigid (non-deformable) forms with respect to the objects onto which it exerts a force. As a consequence, if such a mimicking region exerts a force onto an undifferentiated region of another polymorphic surface, the latter will start to deform as well and become differentiated. Another consequence is that if the other surface is already differentiated, and does not have a matching form, the forms will not fit into each other and movement will halt.

4.3 Law: free regions return to an undifferentiated state

All examples provided thus far, also work in the reverse direction. When objects are taken out again, the polymorphic surfaces move back to their original position. These examples can simply be obtained by reading the comic strips in the reverse order. The underlying law is formulated as follows: free regions return to their undifferentiated state. In other words: any region of a polymorphic surface that is not being pushed by a shape, nor mimicking another surface, returns to its undifferentiated state.

4.4 Experimentation

Note that a quite extensive experimental study has been carried out to test the understandability of the laws mentioned in this section among secondary school students with promising results.

5 Madawipol- by example

As said, Madawipol- extends Madawipol- with complete parametric polymorphism, i.e. it also covers polymorphic M-constructors with arguments, such as ‘Cons:[List a]’.

For clarity, in some of the following examples the correspondence between parts of the visual and the textual representation is shown. It is essential to note that these are not put there for definitory purposes: for a user of Madawipol-

 the semantics is contained in the construction possibilities of the building blocks. The correspondence is merely put here to provide the reader of this paper, who is probably well-versed in textual functional languages, a quick insight into the fact that these visualisations indeed exhibit the same relevant behaviours as their textual counterparts.

The essential building block of the extension is formed by polymorphic surfaces, covered in section 4.

In Madawipol-, polymorphic surfaces are part of polymorphic M-constructors. For didactic purposes it easier to first illustrate important aspects of how they function within M-constructors in maramafications of the ‘flexible textual language’ Algepoly1. It allows ‘minimal examples’111https://en.wikipedia.org/wiki/Minimal_Working_Example to be more minimal.

For the sake of simplicity and the purpose of this article, the type-constructor forms in this section have been chosen such that 2D cross-sections provide all information needed. This simplifies the creation of examples in static 2D media, such as this article. These cross-sections, however, are not intended as viable alternatives for the 3D models. Among other things, it is harder to discern the different type-constructor forms in them. For example, the human visual apparatus will immediately recognise a circle that contains a triangle, as two separate objects with a distinct form, while the ‘ridges and edges’ in the 2D cross-sections give it much less to hold on. The users, however, will work with the 3D models.

To achieve the situation that 2D cross-sections contain all information needed, fig. 9 redefines the forms of several type-constructors that have been defined earlier. The latter can be interpreted as viewing a male joint along a line of sight that is perpendicular to the bottom of the joint. We remind the reader that in the electronic version of this document, each image contains clickable links that lead to much higher resolution versions of the image.

Colour Bool List
Figure 9: Several type-constructor forms.

Figure 10 provides a cross-sectional view on several M-constructors with these types. The cross-section is made such that it cuts halfway through each joint. Note the red and the blue lines indicating the orientation of each polymorphic surface. These lines, in reality have no thickness as they are part of the same surface. As a compromise, these parallel lines are drawn such that the center of the combined lines aligns with the real line. Specifically in later figures, where M-constructors are joined, and up to four lines stack up, this is a workable compromise.

In the remainder of this article, the prefix ‘M-’ indicates ‘maramafied’. For example, the M-constructor (maramafied constructor) of ‘FlexiCons’ from example 5 is indicated with M-‘FlexiCons’.

Before starting with the elucidating examples, fig. 10 provides an overview of all M-constructors used in the examples, for later reference.

M-Red M-SimpleFemCons M-FlexiCons M-PolyCons Colour <- <- Colour a <- a SimpleType a <- a M-True M-Cons M-SimplePairCons Bool <- List a <- a (List a) <- a a
Figure 10: Overview of M-constructors. Their name and type are written beneath them.

The rest of this section introduces the behaviours of these M-constructors by providing examples. It will indicate for each example whether it “introduces a new law”, or whether it merely “illustrates existing laws”. The latter type of examples should be perfectly predictable and are, among other things, added to allow the reader to verify his or her understanding.

5.1 Reverse reading of examples

Let the reader be reminded that all examples provided in the following sections also work in the reverse direction, following the law that has been explained in section 4.3.

5.2 Law: mimicking polymorphic surfaces (intra-M-constructor type-propagation)

(Implications of existing laws.) Section 5.2 demonstrates type propagation within a M-constructor, i.e. intra M-constructor type-propagation. Simply by following the laws of polymorphic surfaces from section 4, and the chosen forms of the joints, the type propagation takes place as expected in these examples. It first shows an M-FlexiCons (left) and an M-Red (right). The corresponding textual versions have been defined in example 5. The fixed male joint of M-Red moves into the (polymorphic) female joint of M-FlexiCons. As expected, the polymorphic surface in the male joint of M-FlexiCons mimics the polymorphic surface that is being manipulated: the one in the female joint. As a consequence of the inverted orientation of the polymorphic surface of the female joint with respect to the male joint, the form of the male joint will become the exact inverse of the female joint when it mimics the latter. The male joint of M-FlexiCons has now taken the exact shape of the male joint of M-Red. This is perfectly consistent with the typing information expressed in the textual versions of the constructors, and is a first step in illustrating how type-information propagates through M-constructors. Note that this also partially explains why an undifferentiated polymorphic surfaces is positioned halfway the joint, and why the polymorphic surface moves in two directions at the same time.

= to —X[1,c,m]—X[1,c,m]— &   M-FlexiCons:[a<-a] receives M-Red:[Colour<-].   &   M-SimpleFemCons:[<-Colour] receives M-FlexiCons:[a<-a])   &   M-SimplePairCons:[<-a a] receives M-Red:[Colour<-]  
Figure 11: Comic-strips demonstrating intra-M-constructor type-propagation.

The rest of section 5.2 illustrates that the intra-M-constructor propagation takes place as expected, whether it is propagation from a male joint to a female joint, from a female joint to a male joint, or from a female joint to a female joint.

5.3 Inter-M-constructor type propagation

(Illustrates existing laws.) Figure 12 shows how type-information propagates through several M-constructors: i.e. inter-M-constructor type propagation. M-Red moves into the right M-FlexiCons . The polymorphic surface at the left of , mimics the other one of . The right polymorphic surface of (the right ) touches the changing polymorphic surface, and responds by following the laws that were introduced in section 4. Therefore, it gets exactly the same shape as the changing polymorphic surface. The left polymorphic surface of mimics the right polymorphic surface of . This results in a final situation that is, type-wise, in perfect agreement with the textual counterparts of the M-constructors. The figure also demonstrates that mimicking regions of a polymorphic surface act as rigid objects (also see section 4.2).

= to —X[1,c,m]—
Figure 12: Two already joined M-FlexiConses receive an M-Red. The result’s textual equivalent is ‘FlexiCons (FlexiCons Red)’.

5.4 Law: scaling of polymorphic surfaces

(Introduces a new law.) Figure 13 demonstrates scaling of polymorphic surfaces. The polymorphic surface at the left () is smaller than the one at the right (). As expected, mimics

, however its vertical size is scaled down. The scaling factor is, in this case, equal to the ratio between the sizes of both polymorphic surfaces. This scaling process, a linear transformation to be precise, plays the central role in the maramafication of the application of type constructors (i.e. creating joints of types such as ‘

(SimpleType a)’ or ‘(SimpleType (List (SimpleType a)))’. For example, the joint that corresponds with ‘(SimpleType a)’ consists of an alignment square (the two outer ‘pins’), the type-constructor ‘SimpleType’ (the inner two ‘pins’), and the type parameter ‘a’ (the scaled down polymorphic surface). This will be explained in more detail in sections 6.3 and 6.2.

= to —X[1,c,m]—
Figure 13: PolyCons Red’.

5.5 Joining ‘super’- and ‘sub’types

(Introduces a new law.) Section 5.5 shows an example of joining polymorphic surfaces where the female joint is a strict super-type of the male joint. In other words, the types are different, yet unifiable. In the figure, a female joint with type ‘a’ is connected with a male joint with type ‘SimpleType a’. As one can see, the undifferentiated region of a polymorphic surface that meets an undifferentiated region of the polymorphic surface of the opposing joint, remains in an undifferentiated state. The rest of the polymorphic surface takes the shape of the opposing joint.

(Implications of existing laws.) It also demonstrates that the M-constructors can fully deal with recursively defined types. (These are types in which a type-constructor occurs both in the left-hand side and the right-hand side of the algebraic data type definition, such as in the definition of ‘PolyCons’.) The left-most joint takes the shape that corresponds with the type ‘SimpleType (SimpleType a)’. The reader is invited to verify that if yet another M-PolyCons would be inserted in the right M-PolyCons, it would lead to the left-most joint taking the form M-‘SimpleType (SimpleType (SimpleType a))’. The notation M-‘Type’ means the type-form of the given type.

Section 5.5 introduces an additional law.

= to —X[1,c,m]— PolyCons (PolyCons Red)
Figure 15: PolyCons (PolyCons Red)
Figure 16: Cons (Cons Red _) (Cons (Cons _ _) _)
Figure 17: M-True into M-‘a’.
Figure 14: PolyCons (PolyCons _)

5 Madawipol- by example

As said, Madawipol- extends Madawipol- with complete parametric polymorphism, i.e. it also covers polymorphic M-constructors with arguments, such as ‘Cons:[List a]’.

For clarity, in some of the following examples the correspondence between parts of the visual and the textual representation is shown. It is essential to note that these are not put there for definitory purposes: for a user of Madawipol-

 the semantics is contained in the construction possibilities of the building blocks. The correspondence is merely put here to provide the reader of this paper, who is probably well-versed in textual functional languages, a quick insight into the fact that these visualisations indeed exhibit the same relevant behaviours as their textual counterparts.

The essential building block of the extension is formed by polymorphic surfaces, covered in section 4.

In Madawipol-, polymorphic surfaces are part of polymorphic M-constructors. For didactic purposes it easier to first illustrate important aspects of how they function within M-constructors in maramafications of the ‘flexible textual language’ Algepoly1. It allows ‘minimal examples’111https://en.wikipedia.org/wiki/Minimal_Working_Example to be more minimal.

For the sake of simplicity and the purpose of this article, the type-constructor forms in this section have been chosen such that 2D cross-sections provide all information needed. This simplifies the creation of examples in static 2D media, such as this article. These cross-sections, however, are not intended as viable alternatives for the 3D models. Among other things, it is harder to discern the different type-constructor forms in them. For example, the human visual apparatus will immediately recognise a circle that contains a triangle, as two separate objects with a distinct form, while the ‘ridges and edges’ in the 2D cross-sections give it much less to hold on. The users, however, will work with the 3D models.

To achieve the situation that 2D cross-sections contain all information needed, fig. 9 redefines the forms of several type-constructors that have been defined earlier. The latter can be interpreted as viewing a male joint along a line of sight that is perpendicular to the bottom of the joint. We remind the reader that in the electronic version of this document, each image contains clickable links that lead to much higher resolution versions of the image.

Colour Bool List
Figure 9: Several type-constructor forms.

Figure 10 provides a cross-sectional view on several M-constructors with these types. The cross-section is made such that it cuts halfway through each joint. Note the red and the blue lines indicating the orientation of each polymorphic surface. These lines, in reality have no thickness as they are part of the same surface. As a compromise, these parallel lines are drawn such that the center of the combined lines aligns with the real line. Specifically in later figures, where M-constructors are joined, and up to four lines stack up, this is a workable compromise.

In the remainder of this article, the prefix ‘M-’ indicates ‘maramafied’. For example, the M-constructor (maramafied constructor) of ‘FlexiCons’ from example 5 is indicated with M-‘FlexiCons’.

Before starting with the elucidating examples, fig. 10 provides an overview of all M-constructors used in the examples, for later reference.

M-Red M-SimpleFemCons M-FlexiCons M-PolyCons Colour <- <- Colour a <- a SimpleType a <- a M-True M-Cons M-SimplePairCons Bool <- List a <- a (List a) <- a a
Figure 10: Overview of M-constructors. Their name and type are written beneath them.

The rest of this section introduces the behaviours of these M-constructors by providing examples. It will indicate for each example whether it “introduces a new law”, or whether it merely “illustrates existing laws”. The latter type of examples should be perfectly predictable and are, among other things, added to allow the reader to verify his or her understanding.

5.1 Reverse reading of examples

Let the reader be reminded that all examples provided in the following sections also work in the reverse direction, following the law that has been explained in section 4.3.

5.2 Law: mimicking polymorphic surfaces (intra-M-constructor type-propagation)

(Implications of existing laws.) Section 5.2 demonstrates type propagation within a M-constructor, i.e. intra M-constructor type-propagation. Simply by following the laws of polymorphic surfaces from section 4, and the chosen forms of the joints, the type propagation takes place as expected in these examples. It first shows an M-FlexiCons (left) and an M-Red (right). The corresponding textual versions have been defined in example 5. The fixed male joint of M-Red moves into the (polymorphic) female joint of M-FlexiCons. As expected, the polymorphic surface in the male joint of M-FlexiCons mimics the polymorphic surface that is being manipulated: the one in the female joint. As a consequence of the inverted orientation of the polymorphic surface of the female joint with respect to the male joint, the form of the male joint will become the exact inverse of the female joint when it mimics the latter. The male joint of M-FlexiCons has now taken the exact shape of the male joint of M-Red. This is perfectly consistent with the typing information expressed in the textual versions of the constructors, and is a first step in illustrating how type-information propagates through M-constructors. Note that this also partially explains why an undifferentiated polymorphic surfaces is positioned halfway the joint, and why the polymorphic surface moves in two directions at the same time.

= to —X[1,c,m]—X[1,c,m]— &   M-FlexiCons:[a<-a] receives M-Red:[Colour<-].   &   M-SimpleFemCons:[<-Colour] receives M-FlexiCons:[a<-a])   &   M-SimplePairCons:[<-a a] receives M-Red:[Colour<-]  
Figure 11: Comic-strips demonstrating intra-M-constructor type-propagation.

The rest of section 5.2 illustrates that the intra-M-constructor propagation takes place as expected, whether it is propagation from a male joint to a female joint, from a female joint to a male joint, or from a female joint to a female joint.

5.3 Inter-M-constructor type propagation

(Illustrates existing laws.) Figure 12 shows how type-information propagates through several M-constructors: i.e. inter-M-constructor type propagation. M-Red moves into the right M-FlexiCons . The polymorphic surface at the left of , mimics the other one of . The right polymorphic surface of (the right ) touches the changing polymorphic surface, and responds by following the laws that were introduced in section 4. Therefore, it gets exactly the same shape as the changing polymorphic surface. The left polymorphic surface of mimics the right polymorphic surface of . This results in a final situation that is, type-wise, in perfect agreement with the textual counterparts of the M-constructors. The figure also demonstrates that mimicking regions of a polymorphic surface act as rigid objects (also see section 4.2).

= to —X[1,c,m]—
Figure 12: Two already joined M-FlexiConses receive an M-Red. The result’s textual equivalent is ‘FlexiCons (FlexiCons Red)’.

5.4 Law: scaling of polymorphic surfaces

(Introduces a new law.) Figure 13 demonstrates scaling of polymorphic surfaces. The polymorphic surface at the left () is smaller than the one at the right (). As expected, mimics

, however its vertical size is scaled down. The scaling factor is, in this case, equal to the ratio between the sizes of both polymorphic surfaces. This scaling process, a linear transformation to be precise, plays the central role in the maramafication of the application of type constructors (i.e. creating joints of types such as ‘

(SimpleType a)’ or ‘(SimpleType (List (SimpleType a)))’. For example, the joint that corresponds with ‘(SimpleType a)’ consists of an alignment square (the two outer ‘pins’), the type-constructor ‘SimpleType’ (the inner two ‘pins’), and the type parameter ‘a’ (the scaled down polymorphic surface). This will be explained in more detail in sections 6.3 and 6.2.

= to —X[1,c,m]—
Figure 13: PolyCons Red’.

5.5 Joining ‘super’- and ‘sub’types

(Introduces a new law.) Section 5.5 shows an example of joining polymorphic surfaces where the female joint is a strict super-type of the male joint. In other words, the types are different, yet unifiable. In the figure, a female joint with type ‘a’ is connected with a male joint with type ‘SimpleType a’. As one can see, the undifferentiated region of a polymorphic surface that meets an undifferentiated region of the polymorphic surface of the opposing joint, remains in an undifferentiated state. The rest of the polymorphic surface takes the shape of the opposing joint.

(Implications of existing laws.) It also demonstrates that the M-constructors can fully deal with recursively defined types. (These are types in which a type-constructor occurs both in the left-hand side and the right-hand side of the algebraic data type definition, such as in the definition of ‘PolyCons’.) The left-most joint takes the shape that corresponds with the type ‘SimpleType (SimpleType a)’. The reader is invited to verify that if yet another M-PolyCons would be inserted in the right M-PolyCons, it would lead to the left-most joint taking the form M-‘SimpleType (SimpleType (SimpleType a))’. The notation M-‘Type’ means the type-form of the given type.

Section 5.5 introduces an additional law.

= to —X[1,c,m]— PolyCons (PolyCons Red)
Figure 15: PolyCons (PolyCons Red)
Figure 16: Cons (Cons Red _) (Cons (Cons _ _) _)
Figure 17: M-True into M-‘a’.
Figure 14: PolyCons (PolyCons _)