A Model for Naturalistic Programming with Implementation

Featured Application

A general-purpose naturalistic language can be used to develop software systems using a syntax closer to natural languages, but formal enough to avoid ambiguity. This is useful for tasks such as requirement transformation, maintenance and software evolution.

Abstract

While the use of natural language for software development has been proposed since the 1960s, it was limited by the inherent ambiguity of natural languages, which people resolve using reasoning in a text or conversation. Programming languages are formal general-purpose or domain-specific alternatives based on mathematical formalism and which are at a remove from natural language. Over the years, various authors have presented studies in which they attempted to use a subset of the English language for solving particular problems. Each author approached the problem by covering particular domains, rather than focusing on describing general elements that would help other authors develop general-purpose languages, instead focusing even more on domain-specific languages. The identification of common elements in these studies reveals characteristics that enable the design and implementation of general-purpose naturalistic languages, which requires the establishment of a programming model. This article presents a conceptual model which describes the elements required for designing general-purpose programming languages and which integrates abstraction, temporal elements and indirect references into its grammar. Moreover, as its grammar resembles natural language, thus reducing the gap between problem and solution domains, a naturalistic language prototype is presented, as are three test scenarios which demonstrate its characteristics.

1. Introduction

For a number of decades, programmers have sought the means by which to employ natural languages in software development [1]; however, the use of these languages is limited by the inability of computers to detect and resolve ambiguities, the resolution of which requires the human cognitive process. In response to this limitation, various authors have proposed mechanisms for defining controlled and formalized versions of a natural language that can be processed by a computer without ambiguity.

Various paradigms, including object-oriented programming (OOP) and model-driven architecture (MDA), have, in recent years, enabled a form of software development in which abstractions are modularly defined. The client uses natural language to describe its requirements, which are adapted into formal language and then dispersed or grouped by force into a programming language, which requires correct documentation explaining the context in detail. Often, the programmer’s lack of discipline or the software’s delivery times result in deficient or non-existent code documentation, complicating software maintenance and evolution.

A programming paradigm must both be generic enough to express abstractions regardless of domain and, at the same time, describe enough expressive elements to support general purpose languages. While OOP defines encapsulated abstractions without considering the domain, it lacks the mechanisms necessary to encapsulate non-functional requirements scattered among abstractions, which, in turn, implies a transformation of client requirements [2]. Aspect-oriented programming (AOP) allows encapsulating dispersed code; however, since requirements are defined in natural language, transformations are still required to adapt them to the paradigm. Therefore, although AOP contributes to solving modularity problems, it does not afford expressiveness in terms of client requirements [3].

Biermann and Ballard [4] described limiting factors for the use of natural languages for programming, stating that natural languages have a wide range of syntax and semantics, which forces programmers to learn both a large number of grammatical constructions and their respective semantics. Another limitation is that natural languages, although more expressive, are more verbose and require more characters than a traditional programming language. Finally, as natural languages are ambiguous, clear and precise instructions are required to solve a problem. Given that complex syntax can be solved using subsets of a natural language and that these subsets facilitate verbose but self-documented instructions which obviate further documentation, ambiguity is a limiting factor that could persist in an English subset if an adequate syntax is not established or, on the contrary, efforts are made to make it the least verbose possible.

Ambiguity occurs because computers lack the efficient mechanisms to resolve it completely. This requires a correct subset of a natural language to be defined which, thus, must be “naturalistic”. Naturalistic programming is based on this principle and, as in natural languages, a naturalistic programming language must be capable of making reference not only to objects, functions or aspects, but also to other instructions, using instructions such as “the first word in the previous paragraph” [5]. Naturalistic programming provides mechanisms for complementing already existing abstractions, thus requiring programmers to develop software that is closer to a natural language, but with the restrictions of a formal language, thanks to expressive grammar.

This article presents a conceptual model based on that proposed by Lopes, who theorized on the integration of structural, temporal and reflexive indirect references into programming languages [5]. The conceptual model includes the use of noun phrases, the distinction between plural and singular nouns for data collection, and a flexible definition of sentences that enables the simulation of a form of ellipsis in instructions, as well as providing a context for sentences in the form of circumstances. In addition, Knöll et al. [6] stated that, in natural languages, noun phrases are used as indirect references and show how these references can be used in the definition of naturalistic programming languages.

This conceptual model led to the design of a general-purpose programming language called SN, which enables the use of indirect and temporal references as in natural languages, while at the same time being formal enough to eliminate ambiguities and describe abstractions using a subset of the English language. A basic Application Programming Interface (API) was designed from this language, as were several test scenarios in order to verify program correctness in terms of syntax, and, finally, a questionnaire was implemented to evaluate its code expressiveness in terms of the English language.

This article comprises the following sections: Section 2 presents the background and related studies; Section 3 presents the conceptual model proposed; Section 4 describes the naturalistic language SN; Section 5 presents a description of the compiler and the challenges that emerged at the design stage; Section 6 presents three test scenarios; Section 7 discusses the statistical results of students’ assessment of the expressiveness of the SN prototype language; and finally, Section 8 presents the conclusions and possible research lines for the future.

2. Background

In [7], the authors describes programming models as a set of properties that enable the design of a programming language, stating that a functional model is that which possesses the minimum elements required to define a programming language as an implementation of a universal Turing machine. They described a functional model as having the following elements: a lack of side-effects, which implies referential transparency and, therefore, immutable control structures; recursion as a functional mechanism to solve repetitive operations; and the ability to define a system of types for the use of lambda calculus.

Booch et al. [8] defined the elements they identified for the object model as: abstraction; encapsulation; modularity; and hierarchy. For these authors, abstraction is the capacity to take the most relevant elements for the system, while encapsulation consists of hiding the internal details of an object and offering a controlled mechanism to access them, and modularity is the ability to divide an abstraction into smaller units. Finally, hierarchy is the classification and ordering of abstractions where inheritance, a term which describes a relationship where a class “is a” type of another class, and aggregation, where a class “is part” of another class, are observed.

In [2], the authors defined AOP as a complementary paradigm focused on encapsulating non-functional requirements. As a complementary paradigm, AOP serves to support other paradigms, notably AspectJ, which is a language complementary to Java. The authors described the following elements in the join point model: join point, which is an identifiable execution point in the code; pointcut, which is a mechanism for specifying and quantifying join points; and advice, which is the additional functionality that is added to the join point. It should be noted that advice encapsulates a non-functional requirement that is applied to a join point through the pointcut.

Videira Lopes et al. [5] opened a discussion on the elements that are observed in the natural languages and can be added to AOP to describe abstractions with a level of expressiveness closer to English, while maintaining the formality of a traditional programming language. The authors stated that three types of references are observed in anaphoric relations: structural references; temporal references; and reflexive references. Anaphora is a natural language property that enables an entity (real or abstract) to be related to a pronoun or noun phrase without losing context. Traditional programming languages provide support only for explicit structural references such as “out.println(str)”, but not for indirect references such as “execute all methods”, and do not support reflexive references such as “execute the previous three instructions” and temporal references such as “execute the method before printing the string”. On the other hand, the authors stated that, while AspectJ uses a rudimentary form of temporal reference, it lacks the capacity to describe information taken from the context, in which a reflexive and temporal reference such as the last operation, which makes reference to any previous operation regardless of its context, could help to define expressiveness mechanisms closer to natural language.

Unlike anaphoras, cataphoras refer to elements described later in the same text, with both comprising endophoras, which are indirect references defined in the same text. On the other hand, exophoras refer to elements that are defined in another text. Endophoras and exophoras enable deixis, which consists of the use of indirect references whose meaning depends on the context in which they are used. As deixis is mainly observed in the form of pronouns or noun phrases, the same sentence can exist in different texts with their own context [9].

In this article, the concept of “entity” is used as a means of describing an identifiable “thing” using a signifier as a type, which, in turn, is a noun or adjective. (In semiotics, a signifier is defined as a component of the linguistic sign, which is formed by three elements: a referent, which is a real or abstract ‘thing’; a signifier, which is the symbolic representation of the referent; and a meaning, which is the representation of a mental idea [10]. On the other hand, Ferdinand de Saussure mentioned that, as there are signs without a referent, he only considered the signifier and the meaning [11].) Types are directly related to indirect references, because the use of noun phrases implies typing and, therefore, knowledge of the entity to which reference is made.

A noun phrase is group of words whose nucleus is a noun and which optionally contains one or more adjectives and a determiner, such as the first element [12]. A verb phrase is a group of words whose nucleus is a verb with direct and indirect compliments and a preposition, while complements to a verb phrase can also be noun phrases. Noun and verb phrases form the grammatical subject and predicate of a sentence [13].

Naturalistic programming is a paradigm based on the use of elements from the natural languages for the design of more expressive programming languages that are closer to said natural language. Videira Lopes et al. [5] described the advantages and limiting factors of both the natural languages and the programming languages currently used in software development. Their article mentions that natural languages are of little use given their ambiguity, while programming languages are difficult to maintain if the code is inadequately documented, as, due to their formality, the requirements have been transformed and adapted to the language. As a solution, the authors proposed a middle ground, namely a formal programming language featuring elements from both natural languages and anaphoric references.

Another detail to be taken into account is that mentioned by Clark et al. [14], namely that a programming language based on a formal representation of a natural language could belong to one of two categories, either formalist or naturalist. A formalist language lacks ambiguities because it focuses on computers processing it correctly, while the ambiguities of a naturalist language are resolved by means of mechanisms taken from artificial intelligence, meaning that ambiguities remain in the grammar. Based on both definitions, a naturalist language can be implemented with a broader subset of a natural language than a formalist language. In addition, it should be noted that, although, based on [14], the definition of “formalist” is closer to the approach reported here, the present article adheres to the “naturalistic” definition addressed in [5,12].

Scala is a multi-paradigm programming language that combines functional programming with OOP. As its code is compiled to obtain Java bytecode, the bytecode generated with Java and Scala is interchangeable [15]. For Scala, everything is an object, including primitive types and methods, enabling a method to be assigned to one variable or used as a parameter in another.

Finally, the term programming semantics describes the relationship between natural language structures and basic programming structures, where noun phrases are data structures, verbs are functions and adjectives are properties, as defined by Liu and Lieberman [16], Mihalcea et al. [17]. The present article differs from these definitions, in that nouns are treated as basic abstractions and adjectives as complementary features, while a noun phrase is a refinement that results from combining a noun with one or more adjectives, which introduce the attribute to define properties. In addition, as the SN language reported in this article produces Scala code, the mapping between the source code and a programmatic equivalent is carried out automatically. Programmatic semantics must not be confused with formal semantics, which are the mathematical and precise representation of the meaning of a programming language [18]. The present article only covers programmatic semantics, as the compiler generates Scala and AspectJ code as an intermediate language and their formal semantics are already validated [19,20].

Related Work

The following are the highlights from a comprehensive review reported in [21]: Pegasus is presented in [12] as a tool that enables the development of software that functions through a natural language entry based on a mechanism that resembles the human brain. Attempto Controlled English (ACE) is presented in [22,23,24,25] as a formalized version of the English language that can be transformed into first order logic. Computer-Processable Language (CPL) is presented in [14,26] as a natural controlled language developed with a naturalistic focus and featuring an embedded unambiguous language called CPL-Lite. Metafor is presented in [27] as a tool that was envisaged to support novice programmers by enabling them to describe a problem in natural language and then returning Python code sketches. Natural Language Computer (NLC) is presented in [4] as a programming language focused on the management of arrays that appear on the screen by using a subset from the English language to resolve the expressiveness problems of the C language. Macho is presented in [28,29] as a tool that enables the generation of source code based on a simple sentence in English. Presented in [30,31], Natural Language Command Interpreter (NLCI) is a tool focused on generating executable code from an entry in English and is based on an ontology generated from an API. As already mentioned in the survey, while these languages propose solutions from the perspective of natural language, none provide a programming model that describes the elements required for the design of general-purpose naturalistic programming languages.

3. Conceptual Model

In [21], various research articles dealing with the implementation of languages with naturalistic characteristics are reviewed, noting that the authors focused on resolving particular problems and mainly used nouns and verbs. Apart from nouns and adjectives, humans express themselves using pronouns, which are words that replace a noun or phrase and whose use depends on the context; however, the studies reported using, in general, the neutral pronouns it and this for singular words, and these or those for plurals. They observed that few studies made use of noun phrases, complementing them with adjectives when a noun with more specific characteristics was required. Based on the foregoing, it can be inferred that the relevant entities for software development resemble not only nouns but also noun phrases that result from the specialization generated by adjectives and to which, ideally, reference can be made via pronouns or, even, the noun phrases themselves. The use of phrases and pronouns enables indirect reference to be made to previously (or subsequently) defined entities, a common feature of natural languages. In contrast, in programming languages, identifiers are used to store values and references, while working directly with types would allow these languages to work with indirect references aside from pronouns such as “it”, as in the case of languages such as Haskell. Working with types enables the creation of instructions where identifiers are not used, which is common in natural languages, where types are used and identifiers are reserved for elements to be highlighted. For example, append a string to a file [6].

Another property of natural languages is their capacity to describe things non-sequentially or as a consequence of something, a concept defined as a circumstance, thus enabling situations to be associated with contexts. To solve circumstances in programming, some languages define events as objects associated with others for executing a process derived from an action. The disadvantage is that events require one object to be associated with another, leading to inexpressive definitions from an English language perspective. The AspectJ join point model is similar to the concept of circumstances, because it defines a context for a join point by means of advice. The disadvantage is that, as the join points are based on Java syntax, a change in method signature requires a review of the aspect code.

Based on the elements described above, a naturalistic language is composed of nouns, adjectives, verbs, circumstances and phrases, with said elements contributing to ensure that the language uses syntax closer to the English language and with a sufficiently elevated level of formality in order to avoid ambiguities in the code. A naturalistic syntax also requires mechanisms that enable the verification of the lines of code that are found before or after the execution of an instruction. Based on the foregoing, the minimum elements considered for the definition of a naturalistic conceptual model for the design of general purpose programming languages are as follows:

• A noun as a base abstraction that is either singular or plural.
• An adjective as a complement to the noun.
• A verb as an action undertaken by a noun.
• A circumstance as a determinant that responds to events.
• A phrase used to define instructions with a complexity beyond that of the subject and the predicate.
• The element must enable the definition of instructions in terms of those elements previously described (anaphoras).
• As types are defined explicitly and statically, they are used in the construction of instructions comprising phrases.
• The conceptual model is implemented via a textual language that offers a level of expressiveness similar to a natural language, but which is formalized in order to avoid ambiguity.

In the English language, nouns are used to describe entities, while adjectives complement nouns by providing particular features. Nouns and adjectives are combined in noun phrases, which, in sentences, function both as the grammatical subject and as a direct and indirect complement to the verb. Verbs define actions that affect entities and are combined with direct and indirect objects to form the predicate of a sentence. If a noun, adjective or verb requires a context, its execution is associated with a sentence by means of a circumstance. The use of phrases results in more complex instructions that enable reference to be made by means of types, be they nouns or adjectives, depending on the context, which function as indirect references (anaphoras).

Some of the desirable, but not required, elements are listed below:

• Complete support for the deixis, which implies that the instructions are defined according to the elements that are described not only before but also after the same text.
• Support for identifiers that enable work with the abstractions by means of direct references.
• Property-based typing, which requires the classification of a noun based on its properties, and, therefore, has the capacity to add new properties to an abstraction when it is created.

The use of full deixis enables reference not only to previously defined elements but also to elements later defined in the same text (cataphoric references). Using indirect references enables work without identifiers, although these do enable elements to be highlighted when there are many entities of the same type. Finally, it has been observed that typing in OOP is only allowed via classes, interfaces or mixins (in some object-oriented languages, a mixin is a class used for defining methods and fields that can be used by other classes without being in the same hierarchy, thus avoiding the diamond problem [32]); therefore, it is proposed that an entity be classified not only with nouns and adjectives but also by means of specific properties that do not exist in other entities of the same type, as reported in [6].

This section describes circumstances, sentences, indirect references and explicit typing, with other model elements described in Appendix A.

3.1. Circumstance

A circumstance is defined as the set of things that occur around a fact, expressed as a sentence, that affect the meaning of the sentence in some way. In the conceptual model proposed, a circumstance provides mechanisms for describing the manner in which the noun and the elements that comprise it interact with other nouns, in order that the programmer can correctly express ideas and restrictions for instances without them being dispersed. Given that this study proposes an approach in which a noun is complemented with adjectives in order to create instances, a circumstance enables the establishment of restrictions that are based on which adjectives are permitted, which adjectives are required, and which adjectives are not permitted for the composition. A circumstance is a sentence which enables a noun to be instantiated, wherein a value is assigned to an attribute of the noun, or which enables the execution of a verb to be established in accordance with another.

3.2. Sentence

The combination of a verb and a noun (or phrases that contain them as a nucleus) results in a sentence with a particular meaning that depends on the definitions both of the verb and the noun, further to the manner in which the behavior of the latter is modified by an adjective. The conceptual model describes grammatically imperative instructions with an elliptic subject (in natural languages, an elliptic subject is a grammatical subject which is omitted from a sentence without losing its context) and which are in the second person with the “orders” directed at the system, and indicative instructions in the third person, which have a grammatical subject. It should be noted that these grammatical modes are only evident for humans, as a computer cannot distinguish them due to its lack of reasoning. One example of an imperative instruction is add 5 to result, while an example of an indicative instruction is the System prints the Number.

In the present study, interrogative instructions are a special case because, although, in theory, there are no problems working with them in an implementation, they are not considered for the design of the SN language proposed here.

3.3. Indirect Reference

The conceptual model integrates the use of indirect references to describe elements previously defined in the code or defined at another site, as is the case with exophoras. These references function as a replacement for identifiers, which are considered optional elements in the implementation of the conceptual model. Nouns act as types that serve to create instances, while, at the same time, the type is used as a mechanism for referring to said instances thanks to the use of pronouns, numerals or ordinals. Similarly, the properties of a noun serve as a mechanism for selecting particular abstractions, with the instruction the Number with 50 as value thus functioning as an indirect reference for a number with a value of 50.

To obtain a set of Numbers, reference can be made to each number based on various criteria: the first Number; the 3rd Number; the last Number; or, even it, which refers to the last number used or derived from a particular operation.

3.4. Explicit Typing

The model presented in this article requires explicit typing due to the fact that, in natural languages, people express their ideas in accordance with types, referring to things such as the House, my House, the first House, or all Houses, instead of the House H. This means that every entity defined is, in turn, a noun whose type was clearly defined and whose properties either serve to identify it or are combined with adjectives that represent particular properties that provide it with some characteristic that distinguishes said entity from other similar ones. For example, the House with “green” as color can be defined as the Green House, where the property color directly becomes the adjective Green. Finally, a type is expected to form a hierarchy that requires specialization, meaning that a base noun serves as a general element from which types will be generated and which will thus provide more concrete characteristics. For example, the House can be defined as a specialization of the Building. As can be seen, the concept is similar to the hierarchy of the object model, due to the fact that said model draws on the idea of semantics and is, therefore, a fundamental part of natural languages.

4. Language

The conceptual model proposed in this article serves as a basis for defining naturalistic general-purpose programming languages. This section presents the most important relevant elements of the SN language, an English-based programming language derived from the elements established in the proposed conceptual model. The remaining elements can be found in Appendix B.

Using indirect references, SN returns Java bytecode as a result and enables a higher level of description by defining a process similar to a verb phrase, which, conceptually, ensures that it is similar to a function or method. It also defines nouns that, optionally, have a plural form, as well as adjectives that combine with nouns during either definition or instantiation. Lastly, SN presents a limited capacity for describing circumstances for a noun or an adjective. Given that the main purpose here is to implement the model, the optimization of the code was not taken into account. It should be noted that, given the extent of SN grammar, only its most relevant elements are described in the present study.

In the SN language, reserved words are written in lower case, while it is recommended that the first letter of nouns and adjectives is in upper case. For attributes and verbs, said letter is kept in lower case, although there is no problem with the use of upper and lower case letters, as long as reserved words such as nouns, adjectives, verbs or identifiers are not used. This mode of use is recommended for creating a correct distinction between the main abstractions and the rest of the words. A Hello World example is shown below:

• 1 main Example:
• 2  System prints “Hello World”.

As can be observed, an abstraction main is defined on Line 1, which functions as a point of entry to the program, while, on Line 2, the sentence System prints “Hello World” contains the noun System, which possess a verb prints which, in turn, accepts a direct object, which, in this case, is the message to be printed. The Java equivalent is shown below:

• 1 class Example {
• 2  public static void main(String...arg) {
• 3   System.out.print(“Hello World”);}}

4.1. Abstractions

SN has three types of abstractions: nouns; adjectives; and a main abstraction. These abstractions are described in this section.

4.1.1. Noun

Nouns and adjectives are defined in order to create base and complementary abstractions. Nouns are base abstractions that can refine other nouns (inheritance) or be combined with adjectives in order to obtain a complementary behavior. An example of a noun definition is shown below:

• noun House.

The signature is simple: the reserved word noun is used, followed by the name of the abstraction. In natural languages, nouns are narrowed subtypes of other nouns. SN enables the refining of a noun to achieve a more specialized behavior. Based on this, the noun House is defined as a specialized form of Building, as shown below:

• noun Building.
• noun House is a Building.

where Building describes a base noun, with another noun House, presenting more concrete behavior than that of the functionality of Building in order that the code is reused and a hierarchy of types is created. As in other programming languages, the multiple inheritance of nouns is not allowed in SN.

By default, the noun Thing is the root of the types used in the SN language. All the nouns defined will implicitly extend said type or some of the subtypes. The type Things is used as a root for all the plurals defined by SN and can be used to handle every noun without the explicit definition of a plural. To define a plural, SN uses the following instruction:

• noun House is a Building with plural as Houses.

The above makes it possible to create the plural noun Houses for the noun House.

4.1.2. Adjective

With the exception of plurals, adjectives are described in a similar way, as shown below:

• adjective Luxurious.

where the adjective Luxurious is defined in order to be combined with a noun. Refining an adjective is also possible, with an example shown below:

• adjective Big.
• adjective Luxurious is Big.

The adjective Luxurious is a refined form of the adjective Big; however, unlike nouns, an adjective can be refined from two or more adjectives, as shown below:

• adjective Costly.
• adjective Luxurious is Big and Costly.

The adjective Luxurious is now defined as the union of the adjectives Costly and Big and can be combined with the noun House to define a particular type of house. The instantiation of an adjective requires the noun it complements:

• noun Mansion is a Luxurious House.

By default, the root of the adjectives from the SN language is Adjective, with all the adjectives that are defined implicitly extending said adjective or one of its subtypes.

4.2. Instance Creation

For SN, the term instance is used in the same context as OOP: a set of data in memory and accessed through an identifier or, in the case of SN, an indirect reference. To create an instance of a singular, the reserved words a/an are used, followed by the name of the noun, as shown below:

• a House.

For a plural instance, the reserved word some is used, as shown below:

• some Houses.

As proposed in [6], SN enables instance creation without requiring constructors, wherein the attributes can be associated with a value via the preposition with regardless of order or whether not all of them are assigned, while any subsequent process can be associated with another by means of circumstances. An example is given below:

• a House with 5000.0 as price.

where the attribute (Attributes are described in Appendix B.3) price is a Real Number, which comprises two basic SN types in the API: the noun Number; and the adjective Real. (Although “Real” can, grammatically, also be a noun, for the numerical context, it was chosen to work as an adjective, leading to the adjective “Integer” also being used. Both are combined with the noun “Number” for handling real and integer numbers, while a circumstance is used to ensure mutual exclusion.) The value of price is assigned when the instance is created. With these changes, the noun House is defined as follows:

• noun House:
•  attribute price as a Real Number.

Moreover, SN enables the creation of instances using an “instantiation-time” combination for merging a noun with one or more adjectives, which enables the definition of decoupled abstractions (both nouns and adjectives) that are combined as required. An example is shown below:

• a Luxurious House.

4.3. Noun Phrases in Sentences

It should be noted that the examples given in the previous section are stored in a pile instance, in order that each instance can be accessed based on its type and position, for which reason, the SN language uses noun phrases and their position by means of ordinals. An example of their implementation is presented below:

• the first House
• the last Building
• the second House

On occasions, a noun with an attribute of particular value is required, irrespective of its position. For these cases, the clause marker where is used, which works in a similar way to SQL. Given the following instances:

• a House with 20,000.00 as price.
• a House with 60,000.00 as price.
• a House with 40,000.00 as price.

An example of their implementation is presented below:

• the first House where price is equal to 40,000.00
• the last House where price is lesser than 60,000.00

where the instructions indicate that the instances referenced are not only identified by their position but also by the value of the attribute price. In this particular case, the first House where price is equal to 40,000.00 refers to the last instance, while the last House where price is lesser than 60,000.00 refers to the second because the precedence of the ordinals is lower than that of the attributes, while priority is lower than that of the type. For example, given the following abstractions:

• noun Building with plural as Buildings:
•  attribute price as Real Number.
• adjective Costly.
• adjective Big.
• noun House is a Building with plural as Houses.
• noun Mansion is a Big and Costly House.

and the subsequent instances:

• 1 a House with 20,000.00 as price.
• 2 a Costly House with 60,000.00 as price.
• 3 a Mansion with 80,000.00 as price.
• 4 a Building with 10,000.00 as price.

while, given the following instructions:

• 1 System prints the first Building.
• 2 System prints the first Building where price is equal to 60,000.00.
• 3 System prints the second Building.
• 4 System prints the last House.
• 5 System prints the Big House.
• 6 System prints the House where price is equal to 30,000.00.

Line 1 prints the value of the first instance, while Line 2 prints the value of the second instance, and Line 3 prints the value of the second instance. Line 4 prints the value of the third instance, while Line 5 prints the value of the third instance, and Line 6 prints an error, as no house has a value of 30,000.00.

Finally, it is sometimes necessary to work, not with one instance, but with a group of them, with SN enabling indirect references to collections of instances that are later grouped into plurals. An example is presented below:

• all Houses
• the last 3 Houses
• all Houses where price is greater than 25,000
• the last 3 Houses where price is equal to 500,000

Based on the previously defined Building abstractions:

• 1 System prints all Buildings.
• 2 System prints the first 3 Buildings.
• 3 System prints the last 2 Buildings.
• 4 System prints the first 2 Costly House.

Line 1 prints all the instances, while Line 2 prints the first three instances, and Line 3 prints the last two instances, with Line 4 printing Lines 2 and 3, as they contain the adjective Costly.

4.4. Local Identifiers

As the use of indirect references not only enables instructions to be written in a form closer to natural language but also causes a large number of instances to become difficult to handle, SN also enables the use of local identifiers. For example, the instance defined a Luxurious House can be associated with an identifier, as follows:

• house is a Luxurious House.

where the reserved word is corresponds to the operator = of other programming languages. The same applies for literals (numerals and strings) and other identifiers, as shown below:

• h is house.
• num is 5.
• str is “A string”.

where the identifier house from the previous example is associated with the identifier h, while, in the next line, the identifier num is associated with the literal 5 and, finally, the identifier str receives a string.

4.5. Circumstance

The SN language uses circumstances to define the context of a sentence execution. In this way, a circumstance is used to establish conditions to which nouns, adjectives and verbs react.

4.5.1. Circumstances Applied to Instances

A feature of the circumstance is that it enables the establishment as to which adjectives are required, which are not permitted and which are mutually exclusive at the moment of instantiation. For example, the abstraction Building is defined in the context of a realtor, as are the restrictions for the moment at which work with the instances begins, as shown below:

• 1 noun Building:
• 2  circumstance: this cannot be Integer or Real.
• 3  circumstance: Office and Habitable are mutually excluded.
• 4  circumstance: this requires Habitable or Office.

As can be seen, three circumstances are described which indicate that an instance of Building cannot be combined with Integer and Real adjectives and which, by necessity, must be combined with Office or Habitable; however, these, in turn, cannot be combined with each other. The foregoing enables the description of mutual exclusion mechanisms for non-invasive adjectives:

• 1 adjective Office:
• 2  circumstance: this cannot be Habitable.
• 3 adjective Habitable:
• 4  circumstance: this cannot be Office.

It should be noted that the example provides the definition of circumstances for both adjectives, although only one is needed to grant mutual exclusion.

With this in mind, the following example describes how circumstances work:

• 1 a Building.
• 2 an Office Building.
• 3 an Integer Building.
• 4 a Habitable Building.
• 5 an Office and Habitable Building.

In the above example, Lines 1, 3 and 5 will raise an error because those instances are forbidden. Line 1 breaks the circumstance defined on Line 4 of Building, while Line 3 breaks the circumstance defined on Line 2 of the same noun, and Line 5 breaks the circumstances defined on Line 3 of Building and those defined on Lines 2 and 4 in the adjectives Office and Habitable.

A circumstance enables the conditioning of the execution of a verb (verbs are described in detail in Appendix B) both before and after an instance is created. However, to date, this has been restricted solely to the use of verbs that are found in the same noun as the circumstance and the attribute, although the provision of an extended functionality for said mechanism is also an objective:

• 1 adjective Printable:
• 2  verb print itself:
• 3   System prints “A new house was created”.
• 4  circumstance: print this after this is created.

As can be seen, the verb print that provides the adjective Printable for the instance will be executed when it is combined after the instantiation. For example:

• a Printable House.

The following will be printed:

• A new house was created

4.5.2. Circumstances Applied to Attributes

In the case of the attributes, a circumstance enables the execution of a verb when attempts are made to assign the value of the attribute:

• 1 noun House:
• 2  attribute description as String.
• 3  verb itself prints desc as String:
• 4   System prints desc.
• 5  circumstance: it prints description
•    when the description is assigned.

As can be seen, the verb prints is executed when the value of the attribute value is assigned. For example:

• a House with “A beautiful house” as description.
• the description of the House is “Another description”.
• System prints the description of the House.

The following will be printed:

• A beautiful house
• Another description

This is due to the fact that when is considered the equivalent of the advice before in AspectJ.

Another case to be considered is that which occurs when it is necessary to ascertain whether an attribute has a particular value, an example of which is presented below:

• 1 noun House:
• 2  attribute description is “”.
• 3  verb itself prints desc as String:
• 4   System prints desc.
• 5  circumstance: it prints description
•    when the length of description is 0.

Taking the above example, the output with this circumstance would uniquely be Another description due to the fact that the execution of prints is conditioned for the length of description to be 0:

• a House with “A beautiful house” as description.
• the description of the House is “Another description”.
• System prints the description of the House.

The following will be printed:

• Another description

This output occurs due to the fact that, during instantiation, value was assigned to description, meaning that the circumstance verifies whether or not the length is 0, while, on the other hand, the subsequent instantiation gives the following:

• a House.
• the description of the House is “Another description”.
• System prints the description of the House.

where the following will be printed:

• Another description
• Another description

This is due to the fact that value is not assigned in description, for which reason its length is 0.

4.5.3. Circumstances Applied to Verbs

Finally, given an assignation of the variable of a noun Mansion, the following entails:

• 1 noun Mansion:
• 2  attribute price as an Integer Number.
• 3  verb assign p as Integer Number to itself:
• 4   the price of this is p.
• 5  derived attribute string as a String:
• 6   a String with “Mansion valued as ”.
• 7   add price to the String.
• 8   return it.

It is observed that there is no mechanism for validating whether a null or empty value is given to the verb assign on Line 3, which is resolved by means of a circumstance and a verb tasked with the following validation:

• 1 adjective Validated:
• 2  verb itself validates val as Integer Number:
• 3   execute the next instruction when val is null.
• 4   the price of this is 0.
• 5   execute the next instruction when val is not null.
• 6   the price of this is val.
• 7  circumstance: this validates val instead assign val to something.

As observed, the execution of assign on Mansion on Line 3 is replaced by that of validates between Lines 2 and 6, which is presented in the adjective Validated. Furthermore, the description provides the conditions in order that the circumstance occurs when assigning a Integer Number to “something”. The compiler is tasked with validating that both the instruction validates and assign cohere with the type required for the particular context of Validated. For example, if something does not correspond to Validated, the substitution will not be carried out. The same occurs if the adjective is not combined with a noun that possesses the verb assign. Thus, two examples are obtained:

• a Mansion.
• a Validated Mansion.
• the price of it is null.
• System prints the first Mansion and newline.
• System prints the last Mansion and newline.

Each will print two distinct things:

• Mansion valued as null
• Mansion valued as 0

The Scala and AspectJ equivalent is shown below:

class Mansion {

 var price : Number with Integer

 def assign(p : Number with Integer) { this.price = p }

 def string = “Mansion valued as ” + price}

trait Validated {

 def validates(val : Number with Integer) {

  if(val == null)

   this.price = 0

  else

   this.price = val}}

 1 aspect Validated_ValidatorAspect {

 2  Object around(Validated v, naturalistic.lang.Integer $val) :

 3   execution(∗ Validated+.assign(naturalistic.lang.Integer+)) &&

 4   target(v) &&

 5   args($val) {

 6    Object rn = null;

 7    try {

 8     rn = v.validates($val);

 9    } catch (Exception e) {

  10   rn = proceed(restrictedMansion, $val);}

  11    return rn;}}

In this case, the AspectJ advice indicates that, when the execution point of the method assign defined in Validated or its subtypes is reached (Lines 2 and 3), the method validates, defined within Validates (Line 8), will be executed instead. Lines 4 and 5 define the objects and arguments required to work with validates, while Line 10 places the original execution, which is carried out if the validates method gives an exception. It should be noted that this example is an optimized version of the result that occurs during SN compilation, as it is resolved using Java Reflection.

4.6. Naturalistic Control Structures

While traditional programming languages are accustomed to using instructions associated with blocks for delimiting the scope of an iterator or conditional, natural languages describe repetitive instructions, which indicate up to which part of the text the actions are scoped. This section presents naturalistic control structures, while their grammar is presented in Appendix B.

4.6.1. Naturalistic Iterator

The SN language enables work with reflexive instructions in order to carry out iterations, with the iterator functioning as an anaphoric or cataphoric reference.

Naturalistic iterators enable the generation of instructions that solely specify how many instructions will be repeated and under which conditions said iteration will take place. The instruction does not have access to the context of the other instructions which it affects, nor is it clear whether an instruction really does appear before or after. This situation is caused by the nature of a computer, which does not know the context of an instruction. An example is presented below:

i is 0.

repeat the next 2 instructions until i > 10.

System prints i.

add 1 to i.

As can be seen, blocks or marks are not defined, while the compiler is tasked with working with the instructions indicated by means of the next 2. If an iterator is required to repeat a block of instructions a specific number of times, the times reserved word is used:

numbers are some Numbers.

repeat the next instruction 50 times.

an Integer Number; and add 2 to numbers.

In the example, the iterator will be repeated 50 times, with a new number added to the collection of numbers. Finally, if it is necessary to work with each element of a plural, such as the plural numbers from the previous example, the following construction is used:

i is 1.

repeat the next 2 instructions for each numbers as number.

multiply i by 2.

add it to number.

The example takes the collection of numbers that was created in the previous example and performs a transaction on each of its values, represented by the variable number.

4.6.2. Naturalistic Conditional

A naturalistic conditional is defined as resembling the manner in which naturalistic iterators express themselves, as they possess the same characteristics and limitations, with the difference that, instead of indicating that a set of instructions is repeated N times, it indicates that the set of instructions will be executed only if a particular condition is fulfilled. An example is presented below:

• flag is false.
• execute the next 3 instructions when flag is equal to false.
• System prints “Optional output”.
• System prints “Another output”.
• flag is true.
• System prints “From the outside”.

where the three instructions subsequent to the definition of the condition are executed if the flag has value false, otherwise, only From the outside will be printed.

5. Compiler

This section details the most important characteristics of the SN language compiler. It should be noted that, being the first prototype of SN, special emphasis was placed on the functionality and correctness of the result, leaving aside the efficiency and speed of the bytecode generated. The decision was also taken to use two existing programming languages due to the fact that they possess the features required to implement the elements considered in the design of the SN language.

The grammar was implemented using ANTLR v4 (ANother Tool For Language Recognition) [33]. At the time of writing, there were 68 rules and 137 tokens, due to the complexity of the instructions, which contain sentences with noun phrases comprising nouns and adjectives, further to sentences with a deictic subject where the complements of the verb are also noun phrases. The number of tokens is high because prepositions and auxiliaries are used for the correct generation of the verbs. Output at the first step of compiling produces Scala and AspectJ code, with both codes later compiled by their own compilers to generate bytecode.

Scala is a multi-paradigm programming language that combines object-oriented programming with functional programming [34]. Version 2.12.3 (not the SBT (the Simple Build Tool is a build tool that works similarly to Maven or Ant [35]) release) was chosen as the main language for the present study, using intermediary code generation to obtain bytecode.

Chosen to carry out the work with circumstances, AspectJ (1.8.10) is an aspect-oriented language based on Java, which uses the signature of the methods to identify execution points into which code can be inserted [3].

To optimize the SN grammar tests, it was decided to use the Scala and AspectJ languages as intermediate languages, meaning that, for each SN noun, a Scala-class source code is generated, while, for each adjective, a Scala trait (a trait is a mixin implementation for Scala) source code is also generated. Nouns and adjectives have attributes and verbs, which are translated into Scala fields and functions, respectively, with the exception of derived attributes, which are translated into Scala functions. All circumstances defined in a noun or adjective are grouped into an AspectJ complementary aspect. Finally, bytecode generation is conducted by AspectJ and Scala compilers.

The decision was taken to use Reflection to simplify the process of code transformation, as the use of indirect references requires the intensive use of explicit casting (the term casting is used in OOP to indicate the conversion of the type of object into any other type within its hierarchy. [36]) at Scala level, which complicated the debugging of the first programs written in SN. This was because several examples consist of type conversions that are not part of the noun hierarchy and a correct type analysis is required to achieve proper functionality.

Although avoiding explicit conversion leads to an integrity problem, this decision was made in order to restrict the use of complex grammatical constructs. As a result, Reflection contributed negatively to bytecode efficiency, although it did simplify code generation, while its use in AspectJ resulted in fragile signatures in which the implementation of advice is decoupled from the pointcuts, thus reducing the effect of fragility.

5.1. Scala Generation

Once the Scala and AspectJ source code is generated, their compilers are used to generate the executable bytecode. First, the Scala compiler is invoked, generating at least one class file per noun (now translated into a Scala class) and adjective (now translated into a Scala trait). It should be noted that, if a composition is undertaken at instance-time, an additional class will be generated for each different composition. This occurs because, internally, the Scala compiler translates instance-time compositions into inner classes (within the corresponding function), while the successive instances of that composition are actually types of that inner class. Given the following example:

• noun House.
• adjective Big.
• adjective Costly.

whose Scala result is as follows:

• class House
• trait Big
• trait Costly

if there is an SN implementation such as the one shown below:

• main Example:
•  h1 is a Big House.
•  h2 is a Costly House.
•  h3 is a Big and Costly House.
•  h4 is a Costly and Big House.

the resulting Scala code is as follows:

• object Example extends scala.App {
•  var h1 = new House with Big
•  var h2 = new House with Costly
•  var h3 = new House with Big with Costly
•  var h4 = new House with Costly with Big}

Therefore, the Scala compiler will generate the following class files:

• Big.class
• Costly.class
• House.class
• Example.class
• Example$.class
• Example$$anon$delayedInit$body.class
• Example$$anon$1.class
• Example$$anon$2.class
• Example$$anon$3.class
• Example$$anon$4.class

where the first three class files are the two adjectives and the defined noun. The following three class files refer to elements that Scala generates for executing the program, which, as they are specific to Scala, are beyond the scope of this article. Finally, the remaining four class files correspond to each of the inner classes that the Scala compiler generates for the time instance composition made when an object is instantiated.

Another notable detail is that working with such high level grammatical elements ensures that the signatures for the methods in the bytecode are ambiguous. For example, the signature of the verb plus num as Number to itself in bytecode was simply plus, which caused compiler problems when working with said verb, because it could not be verified whether or not the sentence was translated as num plus 5 or plus num 5. Thus, for the translation into Scala, the decision was taken to generate methods with a name that would include not only the verb but also the position of the noun invoking it, as well as the number of arguments and the preposition (if any). Thus, if the noun is as follows:

• noun Number:
•  verb itself plus arg as Number.

the signature is generated as follows:

• class Number
•  public Number plus(arg : Number)

With the changes, the signature is now generated as follows:

class Number

 public Number itself_plus_arg(arg : Number)

Thus, the ambiguity caused by signatures is controlled.

In the SN language, as indirect references are an alternative for local variables, every verb translated into a Scala method has a ItMethodCompanion object that handles said references. When an instance is created, it is stored on a list contained by ItMethodCompanion and, if an indirect reference is used, ItMethodCompanion searches for it based on position (using ordinals), type (nouns and adjectives) and specific values for the attributes.

To work with iterators and conditionals, SN undertakes a process of semantic analysis in order to ascertain whether or not there are sufficient instructions (one or more) after the definition of the iterator or conditional. In the event of these not being sufficient, a semantic error is presented, while, in the event of there being sufficient instructions, they are arranged in order that while or for blocks are generated for the iterators, or if blocks are created for the conditionals. Given the fact that iterators and conditionals do not describe blocks, the SN language solely provides scope for the local variables. This means that, if a variable is defined in an instruction related to a conditional or an iterator, the definition will be moved to just before the blocks, while the point at which it is employed will be used to provide it with an assignation.

5.2. AspectJ Generation

Once the Scala code is generated, the SN compiler verifies whether there is a circumstance and, if not, the compiler ends its execution, otherwise it invokes the AspectJ compiler that generates a class file for each noun or adjective that has at least one circumstance. Given that Load-Time Weaving (LTW) is used, code weaving is not performed, as this process occurs when the classes are loaded during the execution of the program.

LTW enables the generation of bytecode, from AspectJ, without directly altering it, as occurs in the generation of AspectJ compile-time weaving. The decision was made to keep the bytecode unweaved, thus making it possible to analyze it without depending on its aspectual counterpart. As both AspectJ compile-time weaving and LTW are processes pertaining to AspectJ, they are outside the scope of this article.

As a result of the execution, a class file is generated with the name of the noun or adjective it complements, plus the suffix _ValidatorAspect. For example, if the following noun is given:

• noun House:
•  circumstance: Big and Costly are mutually excluded.

the AspectJ compiler will generate the following class file:

• House_ValidatorAspect.class

6. Test Scenarios

Three test scenarios are presented below, with the first using indirect references to work with the basic operations for integers, while the second presents the implementation of a database connection, and the third describes an approximate equivalent of the example of files presented in [5].

6.1. Case 1: Operations with Numbers

This scenario presents the noun Number that describes the basic arithmetic operations of addition, subtraction, multiplication and division. Its equivalent in the SN language is presented below. While it should be noted that this noun is part of the “low level” API for the SN language, a simplified version is used to demonstrate the properties of the language.

•  1 abstract noun Number is a Thing with plural as Numbers:
•  2  verb add number as Number to itself.
•  3  verb itself plus number as Number.
•  4  verb subtract number as Number from itself.
•  5  verb itself minus number as Number.
•  6  verb multiply number as Number by itself.
•  7  verb itself times number as Number.
•  8  verb divide number as Number by itself.
•  9  verb itself by number as Number.
•   10  verb leftover number as Number by itself.
•   11  verb itself mod number as Number.
•   12 adjective Integer.

The noun is described on Line 1 with a plural definition, while, on Lines 2 to 11, verbs representing basic mathematical operations are presented, with only Line 10 emphasized because the term “leftover” could be confusing as it is a word chosen for representing a remainder operation. Lines 2, 4, 6, 8 and 10 represent operations that alter the Number instance. Lines 3, 5, 7, 9 and 11 are operations that return another instance of Number without altering it. The complementary adjective is presented on Line 12, which has specific implementations for handling integer numbers, and is conceived to combine with Number, as this noun is abstract and incomplete. Its Scala equivalent is the following:

 1 abstract class Number extends Thing {

 2  def add(number : Number) : Number

 3  def plus(number : Number) : Number

 4  def subtract(number : Number) : Number

 5  def minus(number : Number) : Number

 6  def multiply(number : Number) : Number

 7  def times(number : Number) : Number

 8  def divide(number : Number) : Number

 9  def by(number : Number) : Number

  10  def leftover(number : Number) : Number

  11  def mod(number : Number) : Number

  12 trait Integer

As can be seen, it uses an abstract class and a trait in order to undertake the composition. In Scala, the part for the plurals is easily managed using a list, as shown below.

var numbers = List(new Number with Integer)

The following code presents the manner in which the verbs are invoked:

 1 main Operations:

 2  an Integer Number with 5 as value.

 3  add 2 to the Number.

 4  the Number plus 3.

 5  the second Number minus the first Number.

 6  an Integer Number with the value of the third Number as value.

 7  subtract 1 from the fourth Number.

 8  divide the fourth Number by 2.

 9  170 mod 9; and an Integer Number with the 6th as value.

  10  leftover it by 3.

Line 1 comprises the point of entry to the program, while Line 2 creates an instance for Number and assigns the value of 5. It should be noted that the instances are intended to be created and their attributes assigned according to the programmer’s needs, be this in terms of the definition of the noun, in order to give it predetermined values, or during instantiation as part of the preposition with. On Line 3, 2 is added to the instance, where, in this case, the expression the Number refers to the first (and, up to this point, only) instance. Another instance derived from the verb plus results from adding 3 to the first instance, in which case, the instance will have a value of 10. (The conceptual difference between the verbs add and plus is created on Line 4. This is the first addition to the instance, while the second returns a new instance of said addition, without altering the previous instance.) On Line 5, a third instance derived from the verb minus is created and results from subtracting the value of the first instance (7) from the second (10), which means that the third instance will have a value of 3. On Line 6, a fourth instance is created, whose value is that of the third instance (3). On Line 7, 1 is subtracted from the fourth instance (3), which finishes with a value of 2. On Line 8, the fourth instance (2) is divided by 2, giving a value of 1. Line 9 creates an instance whose value will be 8, the remainder of the division of 170 by 9. Finally, Line 10 creates an instance whose value is equal to the remainder from the previous instance (8) on being divided by 3, the result of which is 2.

As can be seen, in this case, it was possible to manage without the use of identifiers and, in their place, indirect references to instances were used according to the moment at which they were instantiated. Furthermore, this study presents a mechanism for instantiation and assignation that simplifies the definition of constructors, which enables the description of nouns with a level of detail that will depend on the needs of the programmer. The equivalent of said code in Scala is the following:

 1 class Operations extends App {

 2  val num1 = new Number with Integer

 3  num1.value = 5

 4  num1.add(2)

 5  val num2 = num1.plus(3)

 6  val num3 = num2 minus.(num1)

 7  val num4 = new Number with Integer

 8  num4.value = num3.value

 9  num4.subtract(1)

  10  val num5 = num4.divide(2)

  11  val num6 = 170.mod(9)

  12  val num6 = new Number with Integer

  13  num7.value = num6

  14  num7.leftover(3)}

As can be seen, identifiers were used for correctly working with the instances. In this case, constructors were not used with arguments, while the assignation of the attribute value was undertaken in a separate instruction.

6.2. Case 2: Database Connection

In this scenario, an example of connection to a database by means of naturalistic queries is presented. SQL is a query language with a high level of expressiveness, a feature which facilitates implementation in the SN language without major problems. Two very simple abstractions are presented below, Car and Person:

noun Car:

 attribute model as a String.

 attribute maxSpeed as a Integer Number.

noun Person:

 attribute name as a String.

 attribute age as a Integer Number.

To enable a separation between the database connection and the nouns, the adjective Storable is presented, thus refining the adjective DBEntity.

1 adjective Storable is DBEntity:

2  circumstance: execute assign this when this is created.

3  verb assign itself:

4   the driver is “org.postgresql.Driver”.

5   the jar is “C:\\pgsql.jar”.

6   the user is “admin”.

7   the password is “admin1”.

8   the URL is “jdbc:postgresql:

    //localhost:5432/agenda”.

Based on these abstractions, the following example presents a mechanism that enables three to be converted into database entities with the ability to query, insert, delete, and modify information:

1 main Select:

2  a DBPersistent String with “Person1” as value.

3  an Storable Person with the String as name.

4  some Strings.

5  add “name” to these.

6  add “age” to the Strings.

7  select the Strings from the Person.

8  System prints these and newline.

Line 1 describes an abstraction main, which is the starting point of any program in SN. Line 2 describes the instance of a noun String that is complemented with an adjective DBPersistent, which turns the string into an abstraction storable in an attribute of a database tuple. Line 3 indicates the creation of an instance of the noun Person that is complemented with Storable, in order that this instance functions as an element equivalent to a tuple of a database. Line 4 indicates the creation of a plural type Strings, which will store the attributes of the table to be accessed. Lines 5 and 6 add the strings name and age, which are the attributes of the table Person that you want to extract from the database. On Line 7, the database query is made by means of the verb select, which returns a plural of the type Person, if a plural is not defined, and the type Things, the root of plurals, is then returned. Finally, Line 8 prints the values. Other database-related operations are shown in Appendix C.

6.3. Case 3: Encoding Process

This scenario is based on the example proposed in [5], as it is a representation of code written in Java. Given that it only describes an approximate representation, there is no guarantee that it can work without a profound analysis of the API being carried out in order to translate it into the SN language and, thus, present a functional example. Firstly, description is given of three nouns which possess verbs tasked with reading, writing or cleaning data. The main example is presented below.

1 noun Encoder:

2  verb encodeDuration bytes as Byte Numbers in itself.

1 noun InputStream:

2  verb read bytes as Byte Numbers from itself.

3  verb empty itself.

1 noun OutputStream:

2  verb write bytes as Byte Numbers into itself.

3  verb empty itself.

 1 noun Example:

 2  verb itself encodeStream input as InputStream and output as OutputStream:

 3   an Encoder.

 4   some Byte Numbers.

 5   repeat the next 3 instructions until empty input.

 6   some Byte Numbers; read the Byte Numbers from input;

     and add it to the Byte Numbers.

 7   encodeDuration these in the Encoder.

 8   write it into output.

 9   execute the next instruction when read the Byte Numbers from

     input are lesser than the first Byte Numbers.

  10   this patch the last Byte Numbers and 0.

  11  verb itself patch bytes as Bytes and number as Byte Number.

The following description focuses solely on the noun Example. As can be seen, an instance of Encoder is created on Line 3, while an instance of Numbers, which is also delimited by means of the adjective Byte, is created on Line 4. Line 5 describes an iterator which repeats the following three instructions until input is empty. Line 6 shows the creation of another instance of Byte Numbers, which receives the value of the result of the verb read for input, which receives the first instance of Byte Numbers as a parameter. Line 7 executes encodeDuration, which receives the instance of Byte Numbers, which was created in the previous line and is invoked by means of the indirect reference these. The result of Line 7 is written in output on Line 8. Line 9 describes a conditional, which indicates that the subsequent instruction will be executed if the bytes which were read from input are lower than the value of the first instance of Byte Numbers. Line 10 calls to the verb patch, which receives the last instance of Byte Numbers that had been read, while Line 11 provides the definition without implementing the verb.

7. SN Evaluation

As seen in the scenarios presented in the previous section, SN’s grammar enables work with indirect references, as well as reducing the use of identifiers, as mentioned by Lopes et al. [5], while maintaining a grammar similar to the English language.

It should be noted that evaluating expressiveness from the perspective of natural language is practically impossible. This is because, as mentioned in [28], there is no standardized mechanism for evaluating translation between man pages (the software documentation for systems based on UNIX), i.e., there is no mechanism reported that objectively evaluates a program and what it is expected to do and then describes these intentions in natural language. In addition, the mechanisms reported in other studies reviewed focus on the code that resulted from the translation (where applicable) or, in its absence, experimental tests conducted on subjects with different levels of programming knowledge (ranging from children to software architects and programmers). For this reason, instructions and code fragments were selected to cover the largest number of valid SN constructions, in order that students with different levels of experience in both programming and English are subsequently able to evaluate their expressiveness from the perspective of natural language.

7.1. Programming Example

As part of the debugging process, an undergraduate student with knowledge of objects and, therefore, presenting object-oriented reasoning, performed the first tests on the SN language. As a result, the student designed exercises, in which the problems posed were solved but which were not naturally expressive. Presented below is one of these exercises, which consists of a mechanism for describing mathematical expressions naturalistic, with, as can be seen, an object-oriented cognitive process used for the programming, therefore differing from what is expected in a naturalistic language:

noun SpeedFormula:

 attribute speed is 0.

 verb itself calculateSpeed distance as Number and time as Number:

   speed is distance divided by time.

   System prints speed.

As can be seen, while the example works correctly, the name of the abstraction is a composition using an adjective with a noun. While this is not significantly problematic, it is based on the human cognitive process and, thus, is a non-naturalistic description. The same happens with the verb, which is the union of a verb and an adjective. An example of its use is given below:

main CalculateV:

 System prints “Write the distance: ” and newline.

 System reads.

 dst is integer of it.

 System prints “Write the time: ” and newline.

 System reads.

 time is integer of it.

 System prints dst and “/”.

 System prints time and newline.

 fv is a SpeedFormula.

 fv calculateSpeed dst and time.

A naturalistic approach is presented below:

noun Formula:

 circumstance: this must be Percentage or Speed.

 circumstance: Percentage and Speed are mutually excluded.

adjective Speed:

 attribute distance as a Real Number.

 attribute time as an Real Number.

 derived attribute result as a Real Number:

  distance / time; and return it.

As can be seen above, the noun was decoupled from the adjective, thus maintaining the context of the sentences while providing an extension mechanism where another adjective that only shares the attribute result is added, with this adjective returning the result of the operation. The following example is presented:

adjective Percentage:

 attribute quantity as a Real Number.

 attribute percent as an Integer Number.

 derived attribute result as a Real Number:

  aux is the real of percent; aux / 100; quantity ∗ it; and return it.

There are now two adjectives that enable work with two types of formulas. The use of both formulas is presented below:

main Main:

 a Speed Formula with 10 as distance and 5 as time.

 System prints the result of it and newline.

 speed is a Speed Formula with 10 as distance and 5 as time.

 System prints the result of speed and newline.

 System prints the result of a Percentage Formula with 10 as percent

  and 500 as quantity and newline.

 a Percentage Formula with 10 as percent and 500 as quantity and newline.

 System prints the result of it.

Although the naturalistic version contains more code, it is, in turn, more readable according to the context of the program while also enabling the extension of the functionality of Formula. Based on both the foregoing and that reported in [37,38], users were not permitted to perform their own exercises. These studies mention that people will try to construct sentences in natural language without considering the language restrictions (in this case, those of SN). These two studies report problems in both the translation process and the interpretation of the text, because the participants used ambiguous sentences or ones with elements not permitted by the tools reported by the authors.

7.2. Questionnaire

An analytical evaluation was chosen instead of a practical one, in order that prior experience with the paradigm did not bias the answers, as, during the initial tests of SN, it was observed that those who work with SN without experience in a naturalistic context seek to shape ideas according to the dominant paradigms. For example, SN enables work with syntax that is closer to OOP, but this is achieved at the cost of sacrificing the naturalistic expressiveness expected from SN. Based on the above, it is observed either that a process of “unlearning” the dominated paradigm is required or that subjects have no prior programming knowledge in order to reduce bias in the evaluation of SN expressiveness. On the other hand, were participants to be solely taught to program in SN, this would create another bias where already knowing the paradigm and syntax would mean that subjects would consider the code expressive, not because of its naturalness, but because of their own previous experience.

The tests were performed using a Likert scale-based questionnaire [39] because no standardized mechanism is reported for comparing the correctness of code to its description in natural language [28]. For example, Chomsky [13] presented the sentence “colourless green ideas sleep furiously” which, while grammatically correct, lacks meaning. In fact, this sentence can be implemented in SN with only minor modifications, giving “the Colourless and Green Ideas sleep furiously”.

Undergraduate students from the computer systems engineering degree program of the Tecnológico Nacional de México (National Technological Institute of Mexico), campus Orizaba participated in the tests, in which 49 students reviewed examples of programs written in SN. Students ranged in age from 18 to 32, with, when asked to estimate their level of programming knowledge, 46.9% considering themselves as having a medium level, 2% considering themselves as having a high level, and 51.1% considering themselves as having a low or zero level. In terms of their mastery of English, 8.1% of the students considered themselves as having a high level, 53.1% considered themselves as having a medium level, and 38.7% considered themselves as having a low or zero level.

A scale was established with values between 1 and 4, where 1 is not expressive and 4 is totally expressive. The tests ranged from analyzing simple instructions to understand their meaning and context to analyzing complete programs that perform tasks such as arithmetic operations via English sentences, defining nouns, adjectives and their combinations, or database management. Questions 4 and 5 consisted of two true or false questions.

The Likert scale was adapted to four alternatives, as options such as “very expressive” were considered too diffuse to be distinguished from the “totally expressive” or “self-documented” option, which already covers the positive range, while, at the opposite extreme, the difference between “little expressive” and “inexpressive” is more evident. In addition, an explicitly neutral option using “moderately expressive” was retained. The list of questions, with their respective percentages, can be found in Appendix D.

Table 1. Question Results.

Question	Inexpressive/ Not Useful	Little Expressive Little Useful	Moderately Expressive Moderately Useful	Highly Expressive Very Useful
1	10.2%	36.7%	40.8%	12.2%
2	2%	38.8%	51%	8.2%
3	8.2%	34.7%	36.7%	20.4%
6	10.2%	34.7%	49%	6.1%
7	2%	38.8%	46.9%	12.2%
8	4.1%	34.7%	38.8%	22.4%
9	2%	26.5%	57.1%	14.3%
10	4.1%	36.7%	46.9%	12.2%
11	4.1%	32.7%	51%	12.2%
12	10.2%	28.6%	49%	12.2%
13	6.1%	32.7%	38.8%	22.4%
14	14.3%	32.7%	40.8%	12.2%
15	14.3%	20.4%	57.1%	8.2%
16	6.1%	30.6%	40.8%	22.4%
17	8.2%	28.6%	53.1%	10.2%
18	0	8.2%	59.2%	32.7%
19	4.1%	42.9%	40.8%	12.2%
20	10.2%	22.4%	59.2%	8.2%
21	6.1%	22.4%	55.1%	16.3%
22	0	20.4%	59.2%	20.4%

presents a summary of the results for the questions regarding expressiveness levels, while

Table 2. True/False Questions.

Question	Yes	No
4	55.1%	44.9
5	51%	49

presents the percentages of answers given to the two true or false questions.

As noted in Table 1, the expressiveness level of the language tends to be moderate when students without language knowledge are asked to evaluate instructions, presenting a tendency to little expressive when examples are shown with several indirect references, such as in Question 19. This is an expected result, derived from the complexity of understanding instructions in which identifiers are dispensed with, while questions such as Question 3 revealed that a simple instruction with indirect references is understood at least moderately by more than half of the students, a situation repeated in Questions 6 and 7. It should be noted that Question 8, which, together with Question 16, obtained the most positive results of all questions, shows SN code and its equivalent in Java, while Question 16 refers to the use of instead in a circumstance. It is possible that Question 8 had such a high positive percentage because the students were able to compare the code with its counterpart in Java.

Table 2 presents two questions, where Question 4 asked students to correctly choose from one of the two options that print the sentence based on how they are presented on screen, while Question 5 asked students to identify another value printed from the example shown in Question 4. A little more than half of the students answered correctly, which also shows that indirect references, although not entirely obvious, are not an unknown concept either.

The remarks made by the students show that, as Spanish is their native language, it was difficult for them to solve complex elements with indirect references, in addition to the fact that many were looking for an implementation similar to languages such as Java, PHP, C# or Haskell, which are known to them.

8. Conclusions and Future Work

The conceptual model presented in this article is derived from the analysis undertaken on the elements that provide the most relevant information in a sentence written in English. In addition, a tendency to use one or more of the elements identified, such as indirect references, pronouns or ellipsis, was observed in several related studies. The model elements were selected to enable the design of general-purpose naturalistic programming languages that are expressive from a natural language perspective and do not lose their formality, without requiring data dictionaries or artificial intelligence techniques.

There is one great disadvantage to the excessive use of indirect references, namely the complexity for the programmer of analyzing the code. For this reason, they were also included in the model, although not as crucial elements, because alternative ways of working with unique values, such as unrepeatable attributes for instances, can be defined in a similar way to the primary keys of SQL.

Based on the questionnaire answered by the students and the research carried out, it was concluded that the conceptual model does not require more elements and serves as a basis for defining the features that a general-purpose naturalistic programming language should possess. Moreover, the questionnaire obtained a high level of expressiveness for SN in students who had no knowledge of it, while the main criticisms recorded were focused on the verbosity of the language and reflect a marked resistance to a new paradigm, a common occurrence in the history of programming languages.

Based on the scenarios used to evaluate the correctness of SN code, which were added to the questionnaire completed by the students, it was observed that SN contributes to reducing the gap between the problem and solution domains, but only when the source code is written using constructions similar to the English language. This results in a self-documented code, but one that is more extensive and faces the significant design challenge of maintaining naturalness. As a result, SN requires a learning process that focuses on not only knowing the grammar but also adapting the cognitive process, because, although SN enables the programming of abstractions similar to those found in Java or Scala, it loses the naturalness of the instructions, which is its main objective.

As a concept test, while SN reflects a high level of expressiveness compared to the English language, it lacks sufficient optimization for use in real environments. The combination of adjectives and nouns during instantiation time enables abstractions to be decoupled, which increases modularity. The use of indirect references increases the naturalness of the code, but, in turn, complicates the handling of a large number of instances, although SN allows the use of identifiers to solve this problem. Finally, the use of circumstances enables the definition of a context for nouns, adjectives, attributes and verbs, which increases the modularity of the code by encapsulating elements that, in other paradigms, are scattered among the abstractions, with the exception of AOP. However, offering a syntax closer to English, as the circumstances are based on the syntax in a similar way to AspectJ pointcuts, means that the robustness in the definition of verbs that this entails contributes to maintaining control of the circumstances.

In future research, SN grammar will be refined for the conceptual model to be more completely validated. As part of this refinement, support will be given in order that programmers are able to define embedded grammars in describing elements of a particular domain, as, in scientific documents, formal language is separate to natural language. Naturalistic iterators and conditionals will be analyzed to verify whether they have the adequate level of naturalness. The coherence of the indirect references will be evaluated to avoid incoherent syntax instructions such as add 2nd to the Numbers.

Furthermore, as Scala and AspectJ were used as intermediary languages to facilitate the analysis of the compilation process and ensure the correctness of the code (which was achieved), the compilation process will be modified to generate bytecode without intermediary languages. In this way, SN will be an independent language, which will improve its optimization and, in turn, will enable the testing of complex applications. Finally, as the construction, analysis and verification of SN was conducted by generating Scala source code, the formal evaluation of the language was postponed because Scala is an already validated language, while the correctness of the intermediate source code was validated via experimentation. With this in mind, a formal evaluation of SN will be performed.