/99/$ IEEE

Size: px

Start display at page:

Download "/99/$ IEEE"

Buck Quentin Byrd
5 years ago
Views:

1 A Multiparadigm Language Approach to Teaching Principles of Programming Languages D. Suzanne Westbrook Computer Science and Electrical Engineering Northern Arizona University Flagstaff, AZ Abstract - This paper describes our experiences in using the multiparadigm language GED to teach our principles of programming languages course. The benefits of using a multiparadigm language include less time spent on learning new environments for different languages, easier transition to different paradigms, and opportunities for multiparadigm programming. In this paper, we give a brief description of GED (which supports the imperative, functional, logic, and object-oriented paradigms), describe how it is used in our course, and discuss the advantages and disadvantages of this approach versus the traditional use of several languages. Introduction Most programming languages courses have students use several distinct languages to gain experience with different language paradigms and implementation issues. Although this approach gives students exposure to multiple real languages (they think it looks good on the resume!), the exposure is necessarily shallow due to the time involved in learning new environments. We believe that by using one multiparadigm language, instead of several single-paradigm languages, students can concentrate specifically on the aspects of a particular paradigm rather than having to learn a new environment and syntax for each language in addition to a paradigm. For the last five years we have used the multiparadigm language GED as the only language in our undergraduate principles of programming languages course. GED supports the imperative, functional, object-oriented, and logic paradigms and allows programs to be written using either single paradigms or combinations of paradigms. In this paper, we give a brief description of GED and show how it can be used to develop problem solutions in the imperative (or procedural), functional, logic, and object-oriented paradigms. We also describe how it is used in our course and discuss the advantages and disadvantages of this approach versus the traditional use of several languages. Course Background paradigms (currently imperative, functional, logic, and object-oriented). Programming assignments are oriented toward experimentation with different paradigms. Solutions are graded on correctness of results while staying within the appropriate paradigm. Approximately every two to three weeks, lectures are alternated between concepts and paradigms so students always have a programming assignment to work on. Additional assignments are made, as needed, for example a written homework covering BNF notation and grammars. Starting in 1997, students had a formal background in an object-oriented language (C++) and program design. In prior years, they had an imperative/procedural background using C. For most students in the class, this is their first formal exposure to a second language and to different paradigms. They have opportunities in other required and elective courses to learn additional languages (currently Visual C++, Java, Ada, Lisp, and Prolog). On the first day of class, the students answer a short survey about their familiarity with different programming paradigms. The results are shown below. Most students were familiar with the notion of the object-oriented paradigm. This is not surprising since that concept is at the heart of working with C++. It was surprising, however, that a majority of the students said they were not familiar with the notion of the imperative (procedural) paradigm even when that was their first paradigm exposure. As expected, most students are not familiar with the functional or logic paradigms. Table 1: Number of students familiar with different programming paradigms (total students in parentheses) Paradigm Familiarity (23) (21) (18) (16) Imperative Functional Logic Our principles of languages course is a junior-level required course offered each spring. The course covers both traditional programming language concepts (most usually associated with imperative languages) and programming Object- Oriented b3-14

2 Description of GED We use the multiparadigm language GED that was developed by John Placer and is an extension of his previous languages G and G-2 [2,3]. GED is an expression-based, interpreted language that has constructs to support programming in the imperative, functional, logic and objectoriented paradigms. The basic data type in GED is a list where list members may be heterogeneous. Eight types are supported: List, Func (for function definition), Symbol, Real, Type, String, and File. The type system is hierarchically organized with List as the base type for all others. GED statements may be entered at the interpreter prompt or may be saved in a file and included in a GED session. GED has built-in operators for arithmetic, comparison, logic, list-processing, and string-processing operations. Several types of control structures are supported, including blocks for sequencing and scoping, selection statements, and iteration (while, foreach, recursion). Formatted input and output are supported for both standard input/output and files. Process abstraction is provided in GED by support for defining named entities (usually called functions ) for use as procedures, true functions, named logical rules, and methods. Named entities are first-class values and can, therefore, be used as arguments to other entities, returned by other entities, assigned to variables, and used as list elements. GED supports relations and has mechanisms to perform simple and complex queries on the values of relation sets. Data abstraction is provided through support for user-defined types that allow for encapsulation and inheritance. GED Examples In order to give the flavor of GED, this section gives sample code for returning a list with an item deleted from an original list in each of the imperative, functional, logic, and object-oriented paradigms. In the functional and logic examples, the original list is not actually modified, however it is in the imperative and object-oriented examples. Comments begin with a double dash. Local variables are declared in a list beginning with the keyword local and are initialized when followed by a colon and some value ( [ ] is an empty list). Imperative/ Procedural Style in GED In this imperative example, a function is defined to perform the delete. This function uses a block structure with sequencing of statements, a foreach iterative control structure, and variable assignment all characteristics of the imperative paradigm. The main program code that invokes delete also uses sequencing and variable assignment to obtain the result. -- delete occurrences of value x from list func delete(x, list) { local [a:[ ]]; foreach i in list do if (i!= x) then a := a i end end; a; -- main program using delete { alist := [1, 2, 3]; alist := delete(2, alist); Functional Style in GED In this functional example, the function definition uses no local variables (and therefore no variable assignment). Instead of an explicit looping construct (such as the foreach in the imperative example), recursive calls are made to traverse the list. The built-in functions head and tail correspond to car and cdr in other functional languages and the append operator ( ) is used to combine lists. The function is invoked using explicit values for both the item to be deleted and the actual list of values. func delete (x, list) if list then if (x = head(list) then delete(x, tail(list)) else [head(list)] delete(x, tail(list)) end end. -- invocation of delete delete(2, [1, 2, 3]). Logic Style in GED In this logic paradigm example, first the list is defined to have some set of values. Then a named logical rule is defined such that each element in the list is examined (temp is instantiated with each value in turn), compared to the value of x and if it is not a match (the clause is true) then it is added to a new list. -- state assertion list := [1, 2, 3]. 11b3-15

3 -- named logical rule func delete(x) { local [temp]; list [temp], temp!= x -> temp using GED in a single paradigm style (imperative, functional, logic). In the fourth assignment, the objectoriented paradigm was to be used in at least some context, but they were free to also use other paradigms as desired thereby potentially creating a multiparadigm solution. -- execute rule to delete 2 from list delete(2). Object-Oriented Style in GED In the object-oriented example, a new class MyList is defined along with its methods (init, add, delete). MyList is based on the List type, contains one private instance variable (list), has no static variables (#), and no public variables (#). To use MyList, first an instance of it (alist) is created using the built-in operator make, then three elements are added to it, and then one of the elements is deleted. Of interest here is the implementation of the delete method which uses the logic, functional, and imperative paradigms to modify the original list. The logic paradigm is represented in list [<x] and list [>x] both of which are a type of query or filter which return all elements of list matching the constraint. The functional paradigm is represented by the append operator. The imperative paradigm is represented by the use of variable assignment. -- define user-defined type (class) MyList addtype (MyList, List, local[list], #, #). -- definition of methods for MyList ---- constructor for MyList func {MyList} init (me, x:[ ]) list := x add a value to a MyList instance func {MyList} add(me, x) list := list [x] delete all elements that match x from -- a MyList instance (using logic paradigm) func {MyList} delete (me, x) list := list [<x] list [>x]. -- main program using MyList and delete alist := make (MyList). add (alist, 1). add (alist, 2). add (alist, 3). delete(alist, 2). Assignments and Experiences During the course, four paradigm-related assignments were given. Each of the first three assignments was to be solved Imperative/Procedural Assignment The first assignment was to use GED to solve a single problem in an imperative (procedural) style. GED features supporting this paradigm are variable assignment, block structure, selection and looping constructs, and definition and use of functions and procedures. The problem required the ability to create, access, and modify a simple database. This problem was chosen for the imperative style (although it would also have been appropriate for an object-oriented solution) because there was a straightforward solution using problem decomposition and a hierarchy of procedures to perform the various tasks. Many students seemed to be at a loss on how to even think about writing a program without the ability to define objects and their behaviors. Given that their first language was C++, this was not completely unexpected but the extent of it was still surprising. Even after much discussion on problem decomposition based on procedural abstractions, many solutions were unnecessarily lengthy due to duplicated code resulting in monolithic solutions. These differences in solutions, however, provided interesting examples and discussions on what is a good imperative solution and what could be improved in those that were judged to be not as good solutions. Functional Assignment The second assignment was to solve a series of small problems using GED in a functional style. GED features supporting this paradigm include support for lists as a basic data structure, defining and using functions, selection statements, recursion, higher-order functions, polymorphism, and functions as first-class values. The problems used in this assignment included, among others, quicksort, a series of set manipulations (subset, intersection, difference, union), manipulations with lists of values (summing all values without regard to depth of list nesting), and converting a function with multiple arguments to a curried version. Each of these problems gave an opportunity to utilize recursion and to think about problem solving in a functional way. Although the students were well acquainted with recursion from previous classes, the emphasis on it with these problems seemed to strengthen their previous knowledge. Many of them expressed pleasure with their solutions and the functional paradigm succinctly stated by one student as this stuff is really cool!. Logic Assignment 11b3-16

4 The third assignment was to solve a series of related problems using GED in a logic paradigm style. GED features supporting this paradigm include the definition of relations (by associating a list of related values to a variable name), support for defining logical rules (named or unnamed) that allow for the return of a set of values based on satisfying a set of expressions, variable instantiation, an implied search mechanism, and backtracking. The problems used in this assignment concerned determining familial relationships given some initial relationships. Given the assertions of male and female and the relation parentof (where the first person is the parent of the second), the students were to determine which females are mothers, which males are fathers, and then determine all sister, brother, cousin, aunt, uncle, and grandparent relations. In essence, build a family tree (in the spirit of diversity, an acknowledgement was given that this exercise in no way was meant to exclude other forms of family composition and relationships). Working with this paradigm seems to prove the most difficult for many students. The logic paradigm is generally the most unlike any other paradigm they have seen and the notions of variable instantiation, backtracking, and an implicit search mechanism do not seem readily obvious. Object-Oriented/Multiparadigm Assignment The last assignment is a single problem that requires the use of at least some concepts of object-oriented programming and allows for the inclusion of other paradigms, thereby creating a multiparadigm solution. GED supports the objectoriented paradigm by the definition of classes and class methods through user-defined types and named functions associated with those types. This assignment is a simulation of a motor vehicle department that has various queues and transactions. It is stated to be an event-driven simulation, but the solutions often turn out to be time-driven. There are several ways to model the problem, but the students are not directed in any particular way other than to use at least one class. They are told that their solutions can be multiparadigm in the sense that the methods can be implemented using the logic or functional paradigms, for example. Over the years, a common solution theme involves using one class and several methods within an imperatively structured program. However, as the students have more recently come from an object-oriented background, the solutions have more of an overall object-oriented structure. One main problem students have is understanding the notion of an event-driven system and how to implement it. Since they are not given the structure of the program, it seems to be a problem to some on how to represent the various queues in the system and how to handle their interactions. Another problem encountered is that the assignment comes at the end of the semester (the last three weeks) and students tend to not start it early enough, resulting in numerous uncompleted assignments. Comparison of MPL to Traditional Approaches It is difficult in a one-semester course to integrate both the theory of programming languages and the notions of differing paradigms, particularly if the paradigms are demonstrated by requiring programming in multiple, distinct languages with different environments (such as lisp, Prolog, and Smalltalk to name a few). Although it is certainly desirable to have students exposed to as many real languages as possible in their undergraduate experiences, if they lack this exposure in the cases where it is shallow or limited then this lack is not necessarily detrimental. We feel that by using a single, multiparadigm language, such as GED, students gain exposure to multiple paradigms in a cohesive environment and can, therefore, focus more on the characteristics of a paradigm rather than learning a new environment. Another advantage of this approach is that they gain experience in learning a new language that does not have as much documentation as available for more established languages and therefore requires more experimentation to master. Former students have commented that their experience learning GED was helpful when they went to industry and were given a proprietary language to learn. Conclusion Overall, we have found using a multiparadigm language such as GED to be a good experience and plan to continue its use. Improvements to the GED environment are being explored to provide better error messages and to allow paradigm flags to be set to disallow certain language constructs outside of the chosen paradigm. Another multiparadigm language, Leda, has also been used at other schools and might be appropriate for a variety of courses [1]. Interestingly, the use of GED has increased the visibility of our principles of languages course since students have heard about both the fun and travails of working with it from previous students. It seems to provide a sense of accomplishment just in working with a language that none of their friends at other schools are using and in being able to say that they have used a multiparadigm language. In the past, there used to be some complaints about not using real languages that could be listed on a resume, but the new trend is to list GED and have the opportunity to explain their experience with it. Acknowledgements 11b3-17

5 Special thanks to John Placer for initiating the use of GED in this class and for the sample problems included in the draft GED manual. Many thanks also to the students in the course over the last five years for their numerous suggestions and comments. References 1) Budd, T., Pandey, R., Never Mind the Paradigm, What About Multiparadigm Languages?, SIGCSE Bulletin, 1995, Vol. 27, No. 2, pp ) Placer, J. The Multiparadigm Language G, Computer Languages, 1991, Vol. 16, No. 3 /4, pp ) Placer, J., The Promise of Multiparadigm Languages as Pedagogical Tools, Proceedings of the 21 st Annual ACM Computer Science Conference, February 15-18, 1993, pp , Indianapolis, IN. 11b3-18

Multi-Paradigm Approach for Teaching Programming

Multi-Paradigm Approach for Teaching Laxmi P Gewali* and John T Minor School of Computer Science University of Nevada, Las Vegas 4505 Maryland Parkway, Las Vegas Nevada 89154 Abstract: Selecting an appropriate