Assignment -
You are to design a NEW programming language called "ifONLY". This new language will be directed to the general purpose problem solving domain space. It need not be Object-Oriented or support concurrency as part of the user syntax.
The language does not have to be computable (able to write a compiler for), or at least you are not required to figure out how you may implement your features other than at the user level. Also the language does not have to be complete in terms of total coverage. I would like you to address the major issues in the chapters (3,6,7,8) in terms of how they may affect your language.
It is up to you to decide the options you would like to have in your language. What form of the control flows; what data structure constructs. I would like examples of your proposed syntax. Again, you should focus on the higher level user issues and not on the underlying compiler requirements. That is to say; you do not have to be overly concerned about possible conflicts in your design.
Think of your language as a DRAFT of a language "ifONLY" that would do it like YOU would like it done (from the programmer's point of view). You do not need to limit yourself to things found in other languages. Is there something you have always wanted but you have not seen? Now is your chance to include it! Or maybe it is just a better (in your opinion) syntax for the way something is expressed.
Through the course you will see that many of the design decisions may have just been at the whim of the creator and that there are many ways to express the logic the programmer wants. Remember Knuth's observation paraphrased by the author in Chapter 1 "programming should be regarded as the art of telling another human being what one wants the computer to do"
Along with the language, I would like you to comment on some of your thought process on why you have chosen to go one way or another in your design.
Use the sections of the chapters (3,6,7,8) to help guide the issues you may need to (or not) address in your language.
Also, include a summary of the language at the end of the report.
Other comments:
1. You should not take your design down to an implementation level. Think in terms of addressing things at the user of the language level when taking about features. YOU ARE NOT creating the new language semantic or syntax diagrams ... This is to be done at a high level. Think conceptual level. If there is a particular thing you want go deeper into that is fine but again; this is not a formal language design!!!!!
2. As it relates to 1. you should have, aside from the features themselves, some discussion on your choices. This is where you can demonstrate your reasoning in terms of the particular concept. For example, for scoping, 1. Would address the "WHAT" but you should have something about the "WHY". Somethings will not take much at all but some you may want to go into deeper.
You should not feel that you have to address everything or include everything. It is your language and I want to leave you the freedom to make your own choices (i.e. there are no wrong choices). What I want is some discussion on why you did what you did.
3. Also, include a summary of the language at the end of the report.
For References in question/assignment use the book: Programming Language Pragmatics, fourth edition by Michael Scott.
Word limit : 2500 (500 report + 2000 other).