text:
Wikijunior:Ancient Civilizations/Kushites

What country did they live in?
The Kushites lived in Kush, also known as Nubia, from around 3100 BC to around 400 AD. Nubia was a region in East Africa, in what is today northern Sudan. Their culture was influenced somewhat by their Egyptian neighbors to the north. Their capital city changed several times, from Kerma in the north, to Napata farther south, to Meroë even farther south, but all three were on the Nile river.

The Kushites lived in East Africa, in the country of Nubia. They lived around the capital, Napata. Today, Napata is in central Sudan and it is south of what is known as Nubia. There are several rivers running through Nubia. They are the Nile, the Atabara, and the Blue and White Nile run through a small patch of Nubia. There is one river running through lower Nubia. The Kushite empire lasted until 350 AD. In this year the Kushite kingdom fell.

What did their buildings look like?
The Kushites built many pyramids similar to those of Egypt, though smaller and steeper. In Meroë, (the capital city of Kush) they lived in rectangular brick houses made of mud. These houses usually included several rooms and had flat roofs.

Some of the nomadic Kushites built huts covered with reeds or animal skins.

What did they eat?
Cattle were very important to the Kushites, because of their religion and their diet included beef, milk, and dairy products. They also ate some grains like millet and barley, some vegetables, and dates. They bred on their farms but they wouldn't eat pig because they thought they had leprosy. The poor hardly ever got to eat meat.

What did they wear?
Men wore loin clothes and tunics made of linen, while women wore simple long skirts. Women also wore heavy ornaments including headbands, a large bracelets, and armlets.

In later times, when the capital city had moved to Meroë, the people wore long, fancy robes and a lot of jewelry. Many poor people wore cloth made out of lamb's wool.

What did their writing look like?
The Kushites used the Meroitic language (named after the city of Meroë, which was the capital around 600 BC). Meroitic has both hieroglyphic letters and cursive letters, both of which are similar to those of the Egyptians. The Meroitic script was written from right to left, like Egyptian and other Arabic languages. We know what sounds the letters make, but do not yet know what most of the words mean, except for names of people.

What did they believe?
The Kushite religion was very similar to the Egyptian religion, borrowing most of their gods. Amon, who was shown as a ram, was the primary god, but there were many others. Many regions had their own gods and goddesses they worshipped. Gods and goddesses native to the Kushites include Amesemi and Apedemak, a lion god.

Frogs were important to the Kushites, and were associated with rain.

Are some of them famous even today?
The name, "Candace", comes from a queen of Kush (Kandake of Kush).

What is left of them today?
The influence of Kush can be seen in Africa today, especially in Sudan. The huts of workers in Sudan are very similar to ancient Kushite huts which have been excavated.

While most of the myths and legends of the Kushite people have been lost, there are a few stories about Kush that still exist today. For example, Aida, an opera from the nineteenth century by Giuseppe Verdi, tells the story of a Kushite princess.


text:
Wikijunior talk:Ancient Civilizations/Kushites

Internal

 * Kush

External

 * Civilizations in Africa: Kush
 * http://www.geocities.com/Tokyo/Bay/7051/mero.pdf
 * digNubia

Books

 * African Kingdoms of the Past: Egypt, Kush, Aksum: Northeast Africa. Kenny Mann.  1997.  Dillon Press.
 * Cultures of the Past: The Ancient African Kingdom of Kush. Pamela F. Service.  1998.  Benchmark Books.

Ancient Writers

 * Herodotus' description of Aethiopia in 430BC - what Herodotus calls Aethiopia is actually Nubia or Kush
 * Diodorus Siculus in 1st century BC
 * Strabo's Geography in 7 BC - http://penelope.uchicago.edu/Thayer/E/Roman/Texts/Strabo/home.html - Book XVII Chapter 2 contains some details about food, buildings, etc.
 * Pliny's Natural History around 61 AD

Image
Would someone who knows what they're doing fix up the image? I copied the markup from the Wikipedia Kush article, but obviously that's not sufficient.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Cookbook:Khao Pad Gai (Thai Chicken Fried Rice)

Khao pad gai is Thai-style fried rice with chicken, as street vendors in the central region of Thailand make it. Note that this is a very imprecise recipe, and so "cups" means "handfuls". Any measuring tool that holds about the capacity of a large handful will do.

Ingredients

 * Peanut oil
 * 1 large chicken breast, sliced in thin strips
 * 2 eggs, unbeaten
 * 4 cups (900 g) cooked Thai jasmine rice, refrigerated overnight
 * ½ yellow onion, chopped into strips
 * ¾ roma tomato, cut into strips
 * 2 green onions, thinly sliced
 * ¾ cup (180 g) cilantro, finely chopped
 * Thai fish sauce (nam pla)
 * Soy sauce
 * 1 Tbsp sugar (preferably palm sugar)
 * 1 tsp salt
 * 2 cloves garlic, minced and fried
 * Vinegar

Optional

 * 1 tsp MSG
 * 2 Tbsp Thai chili sauce

Garnish

 * 3 slices cucumber, peeled (note: can run fork down all sides lightly if desired)
 * 3 slices roma tomato
 * 3 sprigs green onion
 * Lettuce leaf

Procedure

 * 1) Make sure that all of the ingredients are prepared and set aside in small bowls by the stove.
 * 2) Add about 4 Tbsp peanut oil to the wok, and turn the flame to high heat.
 * 3) When the oil is almost smoking, add the chicken strips and push around vigorously with a wok spoon or spatula.
 * 4) When the chicken seems as if it is starting to brown, push it up the side of the wok and crack the eggs into the wok.
 * 5) Stir the eggs around a bit. When almost fully scrambled, mix in the chicken and stir around for 30 seconds more.
 * 6) Push the eggs/chicken to the side, add some more oil, and throw in the tomato and onion. Stir-fry for about 5 minutes. They will not look done, but in the end, they will be fine.
 * 7) Add the cold cooked rice and mix it all in.
 * 8) Turn the heat to low, then add a few splashes of fish sauce and soy sauce to taste.
 * 9) Add sugar, salt, MSG, a splash of vinegar, and chili sauce if wanted. Lastly, add the fried garlic on top. Stir it all in and turn off the heat.
 * 10) On a large platter, arrange the garnishes on a lettuce leaf, and plate the fried rice next to it.
 * 11) Eat the garnishes with the fried rice.


text:
User:RollerCoasterlikeBookofWiki

Use Blogger by typing 'rctlocomotionblog2004.blogspot.com' in the Address bar.

title: User:RollerCoasterlikeBookofWiki


text:
User talk:RollerCoasterlikeBookofWiki

Discussion Page Here. I think you should... Click!

Click!
Click "+"!

title: User talk:RollerCoasterlikeBookofWiki


text:
Managing Groups and Teams/A balance between management and leadership

In the business world of today, there seems to be a halo afixed to the term Leader, while the term Manager is seen to have something of a stigma. "Leader" brings to mind heroic figures rallying people together to give their all for a cause, while "Manager" brings to mind less-charismatic individuals trying to make people into more effecient cogs in the corporate machine.

When one considers this definition of Management (from Wikipedia) one can see that Leadership is actually a sub-catergory of Management: "Management (from Old French ménagement "the art of conducting, directing", from Latin manu agere "to lead by the hand") characterises the process of leading and directing all or part of an organization, often a business, through the deployment and manipulation of resources (human, financial, material, intellectual or intangible)."

One can manage their time, their budget, their fuel, and yes, their people, but one can only lead people (or to be more inclusive, we should say one can only lead intelligent living things, since shepards and dog-trainers would object to a homo sapiens-centric definition).

Then perhaps the perception of a cog-manipulating manager is rooted in this difference between animate and inanimate objects. It is when we feel used, manipulated, or led against our will by a person in authority over us, we feel as if we are being treated like an inanimate object. We say the person in authority is a lousy manager. But when the person in authority increases our own autonomy, makes us feel at liberty to accept or reject his/her vision, and fills us with a real personal desire to bring this vision to life, we say he/she is a great leader.

When applying these concepts for "manager" and "leader" in the setting of a team, we find interesting results: If there is a team leader that is perceived to be unconcerned with the team members needs, or has a personal agenda more important than the team's goals, then the leader is perceived to be more of a "manager" and becomes estranged from the team members. Conversely, the team leaders most admired and loyally followed are those who show concern for the team members as individuals with real needs, and are those who put "The Cause" of the team above their own persona agenda.

Realistically, most organizations do need leaders who sometimes look at their teams with cold, analytical eyes, evaluating inefficiencies and making unpopular choices. But it would be a mistake to think that one has to be an "estranged, unliked manager" in order to execute these responsibilities. If a team leader's tasks such as efficiency analysis were done hand in hand with sincerely seeking to know team members individual needs, then the team leader would be perceived to have a genuine desire to make the team more successful. Additionally, ineffective leaders may hide an unwillingness to make tough decisions by faking the "touchy-feely" attitudes associated with great leaders with high emotional-intelligence.

It is my opinion that effective leadership is a uniquely human institution, and there isn't a team that couldn't profit through better "leaders" rather than better "managers" –using the titles as metaphors, of course. One can still balance all the practical demands of a "manager" with the beneficial traits of an inspiring "leader."


text:
User:RollerCoasterlikeBookofWiki/Internet Games

Control Your Game
First go to [http://www.sonypictures.com/movies/click/site/index.php. this site], then click on "Click Arcade".

Use your mouse to click on the people from their useless banter (">>") will appear if clicked. If you miss one, a buzzer will sound and a guy will say "shut up". React too slow (get buzzed 10 times) and 10 people want to say, you lose!

Only difference: Using a universal controller and speeding up these annoying little distractions (if you have one).


text:
Talk:AP Biology/The Science of Biology

Proper Procedure Needs Review
I'm not sure what the deal is with that paragraph, but Proper Procedure doesn't seem to make any sense...

title: Talk:AP Biology/The Science of Biology


text: Category:Subject:Console game programming


text:
Wikijunior talk:Languages/Spanish

It might be a good idea to include the differences between the Spanish spoken in Spain and in Latin America. In the first poem/story people in Spain would use the 2nd person plural instead of the 3rd. Yes, but they would still use the tilde on the question word cómo. “¿Hola, mis amigos, ¿cómo estáis?

"Te quiero" and "Te amo" means almost the same, "I love you". "I want you" its not a traduction for "Te quiero". While "Te quiero" means the same as Te amo, "te amo" is a more deep feeling, much more. By the way I'm spanish native speaker.

title: Wikijunior talk:Languages/Spanish


text:
Wikijunior talk:How Things Work/Rocket

The description written on 8-7-06 is a summery of quite complex forces that exist in a rocket’s motion. It would be better to write a summery considering that it is directed to 8-11 year olds. “A rocket works by pushing hot exhaust out of one end creating a thrust which pushes it up.” - “The hot exhaust is created by burning a fuel in a controlled manner,” – “By creating a jet of heated exhaust a force is exerted on the colder air behind the rocket.”

I think this level of technical data would be more appropriate.

Top Speed of Blackbird
I was under the impression the SR-71 Blackbird flew at Mach 3, not 5 times the speed of sound as stated.

 * Welcome to Wikibooks! We encourage you to Be bold --xixtas

Why the big changes?
There were several things about this article that I felt really needed to be improved before we could move it to the publishable section in the table of contents: There is still much to be done with this article before it can be ready for publication. But I would like to see 10 of these modules readied for publication including this one. -- xixtas talk 20:52, 23 May 2007 (UTC)
 * The size of the photos caused the page to render poorly in smaller browser windows (In fact, it didn't even render well in a full screen 1024x768 on my notebook.) I think photos larger than 400 pixels wide should be used sparingly if at all.
 * The "middle" tag was causing the photos on the right to shift underneath both that picture and the text they were supposed to be associated with.
 * There was a factual errors regarding the composition of fuel for the Saturn V F-1 engine it is now correctly stated as a combination of a kerosene engine (stage 1) and hydrogen-oxygen (stage 2 and 3).
 * The comparative power of the Saturn V F1 engine to the Shuttle Booster was incorrectly state. The shuttle booster is the most powerful rocket engine ever made.
 * Some of the photos did not seem to be chosen to illustrate the text. Instead, they seemed to be included just because they were pictures that had to do with rockets.
 * I made sure there was a caption on every picture.
 * I removed all 1337 spelling from the text.
 * There should always be a space after a period (unless it's followed by a close parentheses.) Likewise with commas.
 * There was some unnecessary and in my view undesirable US/European centric language.

title: Wikijunior talk:How Things Work/Rocket


text:
User:Babij~enwikibooks

My Wikipedia user page:

title: User:Babij~enwikibooks


text:
Wikijunior:How Things Work/Elevator

Apart from in the United States, an elevator is known as a lift. The term "elevator" is actually the brand name of a lift by a company within the United States. The company was so successful and installed them in so many places, that people started to refer to lifts as elevators. This in turn caused the company to lose its "Elevator" trademark and it became the common name in the United States for a lift.

A lift is designed to transport vertically in a controlled manner. The most common use of a lift is to move people between floors in buildings all over the world. They are also used in mines and manufacturing processes to move material and personnel.

A lift is made up of four major components: The lift cab or platform, the shaft or hoist-way, the drive system and the counterweight.

The cab is moved vertically inside the shaft using either a hydraulic piston or a pulley system, normally the weight of the cab is balanced by counterweights so that the drive system uses minimal energy.

Who invented it?
Elisha Graves Otis (August 3, 1811-April 8, 1861) invented a safe way of braking a hoisting machine, making it safe for people to use. This enabled the development of the passenger lift, the pulley elevator.

How does it get power?
Usually lifts are powered by electricity drawn from the power grid. However, they can be powered in other ways including by draft animals. Also, since you might want to use a lift in a power cut, there can often be a big battery used to power a lift if the power grid is broken.

How does it work?
An elevator is really just a cab (or box) attached to a pulley or hydraulic system, which you will read about later, with some counterweights thrown in to make it easier to lift. When you push a button, it tells the pulley how much to turn, and the elevator moves to where you want it to.

How dangerous is it?
Elevators can be dangerous. For instance, if the pulley or hydraulic system moves the wrong distance, people can get stuck inside the elevator, and they have to call the firemen. Actually being stuck inside an elevator which has stopped past a floor isn't dangerous. Trying to get out yourself prior to having the licensed elevating mechanic open the door for you is. The doors can't close on you these days either, there is either a mechanical arm which travels with the door that when hit will cause the door operator to re-open. Or there is what is called a door detector placed on the car door, which uses light rays, and should the light rays be broken the door re-opens as well.

Some people are scared that if the power goes out an elevator will fall. This is not true, as an elevator has a brake that will stop the elevator from falling far.

What does it do?
The lift transports people to different floors of a building by moving upwards and downwards.

How does it vary?
Elevators usually carry people, but in large buildings there are separate goods elevators to transport things between floors. In Israel, Argentina and other countries with large Jewish populations there are Sabbath elevators which operate on the Jewish Sabbath. They automatically stop at every floor without any buttons being pressed which allows Jews to use the elevator on the day when they're not allowed to do physical work like pressing buttons.

In large skyscrapers there are sometimes double-decker elevators. The lower part will call at odd-numbered floors (1,3,5 etc.) and the upper part will call at even-numbered floors (ground, 2, 4, etc.)

How has it changed the world?
The elevator has changed the world dramatically. Without elevators you would not have mid/high rise buildings, since it would take too long to access the top floors on foot. The New York City skyline would probably be a series of five story buildings.

Lifts also mean that people with physical disabilities are able to access the upper floors of building in a wheelchair. Wheels don't work on stairs!

What idea(s) and/or inventions had to be developed before it could be created?
Before the elevator could be invented, the simple lifting machine had to be. The elevator is simply a safe lifting machine.

Fastest elevators in the world
1. Taipei 101 (60.6 km/h)

2. Yokohama Landmark Tower (45.0 km/h)

title: Wikijunior:How Things Work/Elevator


text:
Microsoft Certified Professional Developer/Exam 70-290: Managing and Maintaining a Microsoft Windows Server 2003 Environment/Configure File System Permissions

NTFS Permissions
NTFS Permissios are used to control who has access to files and folders, and what they can do with them.
 * They can only be used on NTFS volumes (not FAT or FAT32)
 * They apply whether the files and folders are accessed locally or over a network
 * Note: Share permissions only apply to network access and cannot be used to control local access

Permissions Inheritance
By default, permissions for subfolders and files are inherited from the parent folder. You can prevent files and folders from inheriting permissions:
 * Right-click a file or folder
 * Choose Properties
 * Go to the Security tab and click the Advanced button
 * This will open the Advanced Security Settings dialog box
 * Untick the "Inherit from parent..." checkbox at the bottom
 * At this point you can either copy the permissions from the parent folder (in order to modify them), or clear all permissions from the selected file or folder (in order to set new permissions from scratch)

Effective Permissions
Generally, when a user is a member of more than one group which has permissions set on a file or folder, their effective permissions on that object are the sum of the permissions assigned to them. However, there are a few additional rules to take into account:
 * Deny permissions override Allow permissions
 * File permissions override Folder permissions
 * Explicit permissions override Inherited permissions

The order of precedence for permissions is:
 * 1) Explicit Deny overrides
 * 2) Explicit Allow overrides
 * 3) Inherited Deny overrides
 * 4) Inherited Allow


text:
User:Sanjeevpraja~enwikibooks

my name is sanjeev 22 yrs doing my B.Sc and i love painting i do study in also art school. probably i am much attact with art and culture as i was born in city of cultural diversity thats kathmandu. more about me my e-mail add is sanjeevpraja@yahoo.com

title: User:Sanjeevpraja~enwikibooks


text:
Template:Haskell/Example

 Example:

title: Template:Haskell/Example


text:
Talk:Biomechanics

not 100%
in reading, i stumbled upon this book, and it appears to have good content however, it is not a publishable "school" as of yet, i have reduced the completion grade

 * Well, anyone is welcome to edit of course. If you find some useful information to add, I would be pleased. Also, I used the "paint" accessorie to make the images clear. But if anyone can draw them with a higher quality, it would be great, as long as they remain clear. Dr_Darsh

title: Talk:Biomechanics


text:
Haskell/Type basics

In programming, Types are used to group similar values into categories. In Haskell, the type system is a powerful way of reducing the number of mistakes in your code.

Introduction
Programming deals with different sorts of entities. For example, consider adding two numbers together:

$$2 + 3$$

What are 2 and 3? Well, they are numbers. What about the plus sign in the middle? That's certainly not a number, but it stands for an operation which we can do with two numbers – namely, addition.

Similarly, consider a program that asks you for your name and then greets you with a "Hello" message. Neither your name nor the word Hello are numbers. What are they then? We might refer to all words and sentences and so forth as text. It's normal in programming to use a slightly more esoteric word: String, which is short for "string of characters".

Databases illustrate clearly the concept of types. For example, say we had a table in a database to store details about a person's contacts; a kind of personal telephone book. The contents might look like this:

The fields in each entry contain values. Sherlock is a value as is 99 Long Road Street Villestown as well as 655523. Let's classify the values in this example in terms of types. "First Name" and "Last Name" contain text, so we say that the values are of type String.

At first glance, we might classify address as a String. However, the semantics behind an innocent address are quite complex. Many human conventions dictate how we interpret addresses. For example, if the beginning of the address text contains a number it is likely the number of the house. If not, then it's probably the name of the house – except if it starts with "PO Box", in which case it's just a postal box address and doesn't indicate where the person lives at all. Each part of the address has its own meaning.

In principle, we can indeed say that addresses are Strings, but that doesn't capture many important features of addresses. When we describe something as a String, all that we are saying is that it is a sequence of characters (letters, numbers, etc). Recognizing something as a specialized type is far more meaningful. If we know something is an Address, we instantly know much more about the piece of data – for instance, that we can interpret it using the "human conventions" that give meaning to addresses.

We might also apply this rationale to the telephone numbers. We could specify a TelephoneNumber type. Then, if we were to come across some arbitrary sequence of digits which happened to be of type TelephoneNumber we would have access to a lot more information than if it were just a Number – for instance, we could start looking for things such as area and country codes on the initial digits.

Another reason not to consider the telephone numbers as Numbers is that doing arithmetic with them makes no sense. What is the meaning and expected effect of, say, multiplying a TelephoneNumber by 100? It would not allow calling anyone by phone. Also, each digit comprising a telephone number is important; we cannot accept losing some of them by rounding or even by omitting leading zeros.

Why types are useful
How does it help us program well to describe and categorize things? Once we define a type, we can specify what we can or cannot do with it. That makes it far easier to manage larger programs and avoid errors.

Using the interactive command
Let's explore how types work using GHCi. The type of any expression can be checked with  (or shortened to  ) command. Try this on the boolean values from the previous module:

The symbol, which will appear in a couple other places, can be read as simply "is of type", and indicates a type signature.

reveals that truth values in Haskell are of type, as illustrated above for the two possible values,   and  , as well as for a sample expression that will evaluate to one of them. Note that boolean values are not just for value comparisons. captures the semantics of a yes/no answer, so it can represent any information of such kind – say, whether a name was found in a spreadsheet, or whether a user has toggled an on/off option.

Characters and strings
Now let's try  on something new. Literal characters are entered by enclosing them with single quotation marks. For instance, this is the single letter H:

So, literal character values have type  (short for "character"). Now, single quotation marks only work for individual characters, so if we need to enter longer text – that is, a string of characters – we use double quotation marks instead:

Why did we get  again? The difference is the square brackets. means a number of characters chained together, forming a list of characters. Haskell considers all Strings to be lists of characters. Lists in general are important entities in Haskell, and we will cover them in more detail in a little while.

Incidentally, Haskell allows for type synonyms, which work pretty much like synonyms in human languages (words that mean the same thing – say, 'big' and 'large'). In Haskell, type synonyms are alternative names for types. For instance,  is defined as a synonym of , and so we can freely substitute one with the other. Therefore, to say:

is also perfectly valid, and in many cases a lot more readable. From here on we'll mostly refer to text values as, rather than.

Functional types
So far, we have seen how values (strings, booleans, characters, etc.) have types and how these types help us to categorize and describe them. Now, the big twist that makes Haskell's type system truly powerful: Functions have types as well. Let's look at some examples to see how that works.

Example:
We can negate boolean values with  (e.g.   evaluates to   and vice-versa). To figure out the type of a function, we consider two things: the type of values it takes as its input and the type of value it returns. In this example, things are easy. takes a  (the   to be negated), and returns a   (the negated  ). The notation for writing that down is:

You can read this as " is a function from things of type   to things of type  ".

Using :t on a function will work just as expected:

The description of a function's type is in terms of the types of argument(s) it takes and the type of value it evaluates to.

Example: and
Text presents a problem to computers. At its lowest level, a computer only knows binary 1s and 0s. To represent text, every character is first converted to a number, then that number is converted to binary and stored. That's how a piece of text (which is just a sequence of characters) is encoded into binary. Normally, we're only interested in how to encode characters into their numerical representations, because the computer takes care of the conversion to binary numbers without our intervention.

The easiest way to convert characters to numbers is simply to write all the possible characters down, then number them. For example, we might decide that 'a' corresponds to 1, then 'b' to 2, and so on. This is what something called the ASCII standard is: take 128 commonly-used characters and number them (ASCII doesn't actually start with 'a', but the general idea is the same). Of course, it would be quite a chore to sit down and look up a character in a big lookup table every time we wanted to encode it, so we've got two functions that do it for us,  (pronounced 'char') and  :

We already know what  means. The new type on the signatures above,, refers to integer numbers, and is one of quite a few different types of numbers. The type signature of  tells us that it takes an argument of type , an integer number, and evaluates to a result of type Char. The converse is the case with : It takes things of type Char and returns things of type Int. With the info from the type signatures, it becomes immediately clear which of the functions encodes a character into a numeric code and which does the decoding back to a character.

To make things more concrete, here are a few examples. Notice that the two functions aren't available by default; so before trying them in GHCi you need to use the  (or  ) command to load the Data.Char module where they are defined.

Functions with more than one argument
What would be the type of a function that takes more than one argument?

( is the exclusive-or function, which evaluates to   if either one or the other argument is , but not both; and   otherwise.)

The general technique for forming the type of a function that accepts more than one argument is simply to write down all the types of the arguments in a row, in order (so in this case  first then  ), then link them all with. Finally, add the type of the result to the end of the row and stick a final  in just before it. In this example, we have:

  Write down the types of the arguments. In this case, the use of  and   gives away that   and   have to be of type  : Bool                  Bool ^^ p is a Bool        ^^ q is a Bool as well  Fill in the gaps with : Bool -> Bool  Add in the result type and a final. In our case, we're just doing some basic boolean operations so the result remains a Bool. Bool -> Bool -> Bool ^^ We're returning a Bool ^^ This is the extra -> that got added in

The final signature, then, is:

Real world example:
As you'll learn in the Haskell in Practice section of the course, one popular group of Haskell libraries are the GUI (Graphical User Interface) ones. These provide functions for dealing with the visual things computer users are familiar with: menus, buttons, application windows, moving the mouse around, etc. One function from one of these libraries is called, and you can use it to open a new window in your application. For example, say you're writing a word processor, and the user has clicked on the 'Options' button. You need to open a new window which contains all the options that they can change. Let's look at the type signature for this function:

You don't know these types, but they're quite simple. All three of the types there,,   and   are defined by the GUI library that provides. As we saw earlier, the two arrows mean that the first two types are the types of the parameters, and the last is the type of the result. holds the title of the window (which typically appears in a title bar at the very top of the window), and  specifies how big the window should be. The function then returns a value of type <tt>Window</tt> which represents the actual window.

So, even if you have never seen a function before or don't know how it actually works, a type signature can give you a general idea of what the function does. Make a habit of testing every new function you meet with <tt>:t</tt>. If you start doing that now, you'll not only learn about the standard library Haskell functions but also develop a useful kind of intuition about functions in Haskell.

Type signatures in code
We have explored the basic theory behind types and how they apply to Haskell. Now, we will see how type signatures are used for annotating functions in source files. Consider the  function from an earlier example:

That is all we have to do. For maximum clarity, type signatures go above the corresponding function definition.

The signatures we add in this way serve a dual role: they clarify the type of the functions both to human readers and to the compiler/interpreter.

Type inference
If type signatures tell the interpreter (or compiler) about the function type, how did we write our earliest Haskell code without type signatures? Well, when you don't tell Haskell the types of your functions and variables it figures them out through a process called type inference. In essence, the compiler starts with the types of things it knows and then works out the types of the rest of the values. Consider a general example:

is a function that takes an argument  and returns the result of evaluating. Without a type signature, the type of  and the type of the result are not specified. In the expression, however, the compiler knows that   is a. Since  and   are being compared with equality with   and both arguments of   must have the same type, it follows that   must be a. Finally, since  is the result of   it must be a. And thus we have a signature for the function:

Indeed, if you leave out the type signature, the Haskell compiler will discover it through this process. You can verify that by using <tt>:t</tt> on  with or without a signature.

So why write type signatures if they will be inferred anyway? In some cases, the compiler lacks information to infer the type, and so the signature becomes obligatory. In some other cases, we can use a type signature to influence to a certain extent the final type of a function or value. These cases needn't concern us for now, but we have a few other reasons to include type signatures:

 * Documentation: type signatures make your code easier to read. With most functions, the name of the function along with the type of the function is sufficient to guess what the function does. Of course, commenting your code helps, but having the types clearly stated helps too.
 * Debugging: when you annotate a function with a type signature and then make a typo in the body of the function which changes the type of a variable, the compiler will tell you, at compile-time, that your function is wrong. Leaving off the type signature might allow your erroneous function to compile, and the compiler would assign it the wrong type. You wouldn't know until you ran your program that you made this mistake.

Types and readability
A somewhat more realistic example will help us understand better how signatures can help documentation. The piece of code quoted below is a tiny module (modules are the typical way of preparing a library), and this way of organizing code is like that in the libraries bundled with GHC.

This tiny library provides three string manipulation functions. converts a string to upper case,  to lower case, and   capitalizes the first letter of every word. Each of these functions takes a  as argument and evaluates to another. Even if we do not understand how these functions work, looking at the type signatures allows us to immediately know the types of the arguments and return values. Paired with sensible function names, we have enough information to figure out how we can use the functions.

Note that when functions have the same type we have the option of writing just one signature for all of them, by separating their names with commas, as above with  and.

Types prevent errors
The role of types in preventing errors is central to typed languages. When passing expressions around you have to make sure the types match up like they did here. If they don't, you'll get type errors when you try to compile; your program won't pass the typecheck. This helps reduce bugs in your programs. To take a very trivial example:

That line will cause a program to fail when compiling. You can't add two strings together. In all likelihood, the programmer intended to use the similar-looking concatenation operator, which can be used to join two strings together into a single one:

An easy typo to make, but Haskell catches the error when you tried to compile. You don't have to wait until you run the program for the bug to become apparent.

Updating a program commonly involves changes to types. If a change is unintended, or has unforeseen consequences, then it will show up when compiling. Haskell programmers often remark that once they have fixed all the type errors, and their programs compile, that they tend to "just work". The behavior may not always match the intention, but the program won't crash. Haskell has far fewer run-time errors (where your program goes wrong when you run it rather than when you compile) than other languages.

title: Haskell/Type basics


text:
Talk:Haskell/Variables and functions

#haskell brainstorming notes 2006-07-08
DH: Firstly I think we should rip out that stuff about tail recursion. It's much to in-depth for that level.

DH: A better introduction wouldn't spend so much time talking about how to emulate other languages.

DH: I know newcomers struggle with the lack of loops -- I did -- but I don't think that's sufficient reason to dedicate the entire 'Basic concepts' chapter to overcoming it.

EYK: i think it would be fair to write this book as if the reader has never programmed before

 * Yes, thank you so much for making this not dependent on learning other programming! It is not great to force everyone to learn a different technique just to unlearn it when then doing functional. Backfromquadrangle (discuss • contribs) 09:39, 15 November 2013 (UTC)

DH: And I think we should have a whole chapter on types.

DH: I think the main faults of that page are: A better introduction wouldn't spend so much time talking about how to emulate other languages.
 * 1) Bad focus on what Haskell's about
 * 2) Assumes too much of the reader (recursion, types).

DH: Perhaps we could change this into a brief chapter explaining the _very_ basics -- arithmetic and so forth, before outlining the rest of the book, or at least the rest of the first section of the book

EYK: a brief romp through the interpreter? try this! now see what happens what you try that?

Functions with functions
SH: I hope it wasn't out of place but in reading through this introductory chapter I decided to add an example of calling a functionwithin another function (assuming this was the intended meaning of the section. I'm by no means a haskell programmer so if something was amiss please change it and let me know.

 * Most excellent! You read our minds exactly -- Kowey 09:44, 11 July 2006 (UTC)

 * I've added an exercise for various-parameter functions and also an exercise for reusing a previously written function, both related. Is that ok ? -- Pupeno 16:23, 4 November 2006 (UTC)

 * Thanks for that. Looks good to me.  There might be some stuff from Haskell/YAHT we should steal as well -- Kowey 17:54, 4 November 2006 (UTC)

Bug in "area" exercise
The code doesn't work as stated... since "area 5" multiplies a real and integer. One could use "area 5.0" or amend the discussion to include this problem. (Since it was discussed above)

 * Hi, could you please clarify that with an example? I have tested the code... but I could always be mistaken -- Kowey 16:40, 27 May 2007 (UTC)
 * I am wondering if perhaps he just assumed it? I thought the same thing, wondering why, for example, pi * 5^2 worked.  I did :t r and :t 5^2 to learn that one was an Integer and one a Num, which made me feel a little better.  But it might be worth pointing out.  Perhaps if I was bolder, like you're supposed to be with wiki, I would just do it, but I'm a total haskell newbie. -- Msouth 03:53, 15 July 2007 (UTC)
 * I added a note. I am a newbie, so someone please clarify/correct. -- Msouth 04:30, 15 July 2007 (UTC)

 * Ack! Now I see the problem (thanks). It looks like I've accidentally stumbled across the dreaded Monomorhpism restriction (sort of your explanation).  It means my initial explanation of (pi * r) isn't quite right.  But then again, I don't think I want to get into that restriction right now because it's scary sounding. Will have to think about this -- Kowey 04:50, 15 July 2007 (UTC)
 * (by the way, I've just posted an article about this on my blog) -- Kowey 06:26, 15 July 2007 (UTC)

 * Hi Msouth, I have added an improved explanation in the Types section just above this "area" exercise. It has not been vetted by the Haskell community yet, but maybe you should have a look and see what you think -- Kowey 12:00, 19 July 2007 (UTC)

What does this sentence mean?
"Informally, the r in let r = 0 is true when you are in the top level of the interpreter". It's "true"? Like a true boolean? I don't understand this sentence, what it's telling me, what the top level of the interpreter is, etc.-- Msouth 04:37, 15 July 2007 (UTC)

 * I have removed the offending text. I don't know what it means either.  Definitely not true like true boolean, though.  Thanks! -- Kowey 06:33, 15 July 2007 (UTC)

Solutions to problems
Where are the answers for these supposed to be? For example, I'm pretty sure "cylinder b h = (pi * (b ^ 2)) * h" is a valid answer, but how do I check?

 * Yeah, that's an anonying part of this book; we haven't worked out all the solutions yet. I think it would be fair to put them all in a subpage; e.g. Haskell/Solutions/Variables and functions -- Kowey 07:29, 7 February 2007 (UTC)

Beginner Insight
This may be beginner's insight, or it may just be that I'm an idiot but:

Prelude> let pi = 3.14159265358979323846264338327950 Prelude> let area r = pi * r ^ 2 Prelude> area 5

...wait a sec- I thought we weren't allowed to multiply an integer by a double? The area function does though?

- Elin

 * Thanks for that. There's a somewhat tricky technical explanation behind this that I had tried to make clearer (see the discussion above).  Well, I've had another go at it (in the paragraph above).  Hopefully it is a little better.  The basic idea is that numbers like   can actually be either integers, doubles or something else.  Usually, the type is inferred from the context, but in some situations, for example, when you just say something like , there is no context.  Haskell has to assign a type to it, so it defaults to  .  However, in  , we know that   expects a double as input, so Haskell can infer that the   should be treated as a double.  Hope that helps.  -- Kowey 17:30, 28 July 2007 (UTC)

Truncation
"Don't worry about all those missing digits; they're just skipped when displaying the value. All the digits will be used in any future calculations."

Prelude> let pi = 3.14159265358979323846264338327950 Prelude> pi - 3.141592653589793238462643 0.0

كсηפ Cyp 20:00, 1 September 2007 (UTC)

Hum ... I get Prelude> pi - 3.141592653589793 0.0 Prelude> pi - 3.14159265358979 3.1086244689504383e-15 Prelude> (pi - 3.141592653589793)*1000000000000000 0.0 The middle output showed me that a lot of digits were still there, so perhaps the first output was just being, y'know, truncated. So I tried to get these digits with the last output, but that failed. Then I noticed one other thing: most of the digits in the middle output are simply wrong!

Actually, since Haskell is a lazy language, I (a mathematician, not a computer programmer) don't understand why we need to bother with all this Float nonsense (where we pretend that a real number has only finitely many digits, and we just try to make sure that we have more digits than anybody will really need). Shouldn't a lazy language simply calculate the digits we need when we want them?

—Toby Bartels (talk) 18:08, 16 November 2008 (UTC)

 * There are of course ways to do arbitrary precision calculations, but the  and   types are the standard IEEE floating point numbers. Execution speed and all that.
 * -- apfeλmus 10:14, 17 November 2008 (UTC)

"let" syntax in Hugs?
"If this command does not work, you are probably using hugs instead of GHCi, which expects a slightly different syntax."

I don't suppose anyone would like to tell readers just what the Hugs syntax is, would they? A quick search did not turn up anything. --75.15.138.149 15:39, 16 September 2007 (UTC)

Hugs can only evaluate expression, which means that you cannot bind variable across multiple prompt lines. Other than that, normal let expression work, of course. > let x = (1+2) in x*x 9 But you can't use this x in the next line. I filed a feature request for Hugs. -- apfeλmus 06:55, 17 September 2007 (UTC)

variables that don't change
I know that programmers are used to variables for names that are assigned to numbers, strings, and other data structures. But if I understand correctly so far, Haskell variables are not allowed to vary, which makes for a rather odd use of the term. I think it was probably better off to stick with the term symbol.

 * Well, the standard term is variable, we can't just change it to symbol I'm afraid.
 * Also note that the mutable variables (imperative) programmers are used are much younger than the variables that have been used in mathematics for centuries and which work just like the Haskell ones. They still "vary" in the sense that they are a placeholder for a variety of values, it's just that they don't change once they are in scope.
 * -- apfeλmus 08:57, 7 December 2008 (UTC)

 * Can't agree. Even imperative programmers see 'symbol' every day in the compiler errors. I'd be very surprised to see the word 'variable' in any Haskell book/article/post. Don't see any point to give the beginners this misconception.
 * It is not a misconception. The Haskell Report uses "variable" in this sense. A variable is a named location in memory. Variables need not be changeable; "constant variable" is not an oxymoron. (That being so, I have reverted your edit regarding .) --Duplode (discuss • contribs) 17:20, 20 November 2018 (UTC)
 * I think there is a piece of Murphy's Law about programming that says something like "Constants aren't; variables won't". Haskell solved this problem by making the "variables" becoming constants :-) I wonder if there is a way to insert Murphy's Law into this book :-))))))))) Albmont (talk) 17:52, 31 December 2009 (UTC)

 * Go ahead! :D This particular variations "Variables won't; constants aren't." seems to be called "Osborn's law".
 * -- apfeλmus 10:16, 1 January 2010 (UTC)

I think that "areaRect l w = l * w" and "areaSquare s = areaRect s s" is a good place to explain that we aren't setting s or l or w as some permanent variable to be used again, it's just placeholders for that precise function definition, hence why s can be substituted for l and w. Does that make sense? Backfromquadrangle (discuss • contribs) 09:39, 15 November 2013 (UTC)

 * That does make sense, though the chapter already covers that point from a different angle with the section on scope. (By the waythanks for merging the parallel paragraphs there!)--Duplode (discuss • contribs) 21:30, 16 November 2013 (UTC)

Couldn't match expected type
I am using GHCi 6.10.4 from the Hackage Haskell Platform distribution.

When I try:

let r = 25 :: Num a => a 2 * pi * r

From the box on monomorphism restriction, I get:

against inferred type `Integer' In the second argument of `(*)', namely `r' In the expression: 2 * pi * r    In the definition of `it': it = 2 * pi * r

And doing:

let r = 25 :: Num a => a :type r

Gives:

r :: Integer

I'm still trying to figure out why - if it's something I've done wrong then I apologise for this, otherwise you may want to look into it for your book.

Y Less (talk) 12:11, 9 December 2009 (UTC)

 * You have to write the type signature above (before) the binding if you want to a polymorphic value:
 * -- apfeλmus 11:56, 13 December 2009 (UTC)
 * -- apfeλmus 11:56, 13 December 2009 (UTC)

Rewrite 2010 May
Rewriting to adhere to new structure. Old text here:. -- apfeλmus 19:46, 15 May 2010 (UTC)

Allowed variable names
"Variables must begin with a lowercase letter, but for the rest, any string consisting of letter, numbers, underscore (_) or tick (') is allowed." Actually, the allowed names of variables are both more and less restrictive than described. Perhaps this link should be provided? http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-180002.4 --M0davis (discuss • contribs) 03:05, 28 October 2012 (UTC)

Pyramids of Giza problem
Why is it even here? It makes use of both conditions and recursivity, none of which have been introduced yet. It also makes a poor effort explaining what the input and output are supposed to be (pyramid volume? base size? brick size?).

 * The proposed recursive solution was a bad fit, indeed; I replaced it with something more appropriate for the context. The lack of guidance about initial assumptions is something to consider, too --Duplode (discuss • contribs) 21:17, 16 November 2013 (UTC)

meaning of "local and top-level definitions"
in this section, it's fairly unclear to me what a top-level definition is. (my prior programming experience tells me a local definition would be those under the 'where' statement.) my only guess is that a tld refers to the first line of a definition of a funtion which is anything other than the value of a local variable, i.e. some expression. unfortunately, that isn't very clear without trying to eliminate possibilities of meaning, and i'm still not certain i got it right. it would be great if those definitions were explicit. thanks! Sudozero (discuss • contribs) 04:47, 27 June 2014 (UTC)

argument vs. parameter clarity
starting in this section, arguments and parameters are not destinguished, however they are not the same. often people use them interchaneably without much trouble. i'm not sure if the two words are commonly blended in the haskell community, but i've found use of the word 'parameter' in other haskell contexts by using a search engine.

in the following sections i've read, the word 'argument' tends to be used for both meanings. this could lead to some confusion or false statements. it may be a good idea to distinguish them briefly in this section, then go through the book to replace occurences of 'argument' with 'parameter' wherever it's technically correct.

-- Sudozero (discuss • contribs) 14:52, 5 July 2014 (UTC)

Problem in "subtract" example on Multiple parameters section
Dear all,

I would like to warn that the subtract example in the "Multiple parameters" section is problematic since the reader might try defining the function and running it in GHCi to obtain a warning:

*Main> subtract 10 5 <interactive>:22:1: Ambiguous occurrence ‘subtract’ It could refer to either ‘Main.subtract’, defined at Varfun.hs:9:1 or ‘Prelude.subtract’, imported from ‘Prelude’ at Varfun.hs:1:1 (and originally defined in ‘GHC.Num’)

Maybe the book should change the subtract function name to mysubtract?

Fooliu (discuss • contribs) 14:39, 25 December 2014 (UTC)

title: Talk:Haskell/Variables and functions


text:
Haskell/Recursion

Recursive functions play a central role in Haskell, and are used throughout computer science and mathematics generally. Recursion is basically a form of repetition, and we can understand it by making distinct what it means for a function to be recursive, as compared to how it behaves.

A recursive function simply means this: a function that has the ability to invoke itself.

And it behaves such that it invokes itself only when a condition is met, as with an if/else/then expression, or a pattern match which contains at least one base case that terminates the recursion, as well as a recursive case which causes the function to call itself, creating a loop.

Without a terminating condition, a recursive function may remain in a loop forever, causing an infinite regress.

The factorial function
Mathematics (specifically combinatorics) has a function called factorial. It takes a single non-negative integer as an argument, finds all the positive integers less than or equal to “n”, and multiplies them all together. For example, the factorial of 6 (denoted as $$6!$$) is $$1 \times 2 \times 3 \times 4 \times 5 \times 6 = 720$$. We can use a recursive style to define this in Haskell:

Let's look at the factorials of two adjacent numbers:

Notice how we've lined things up. You can see here that the $$6!$$ includes the $$5!$$. In fact, $$6!$$ is just $$6 \times 5!$$. Let's continue:

The factorial of any number is just that number multiplied by the factorial of the number one less than it. There's one exception: if we ask for the factorial of 0, we don't want to multiply 0 by the factorial of -1 (factorial is only for positive numbers). In fact, we just say the factorial of 0 is 1 (we define it to be so. Just take our word for it that this is right. ). So, 0 is the base case for the recursion: when we get to 0 we can immediately say that the answer is 1, no recursion needed. We can summarize the definition of the factorial function as follows:

 * The factorial of 0 is 1.
 * The factorial of any other number is that number multiplied by the factorial of the number one less than it.

We can translate this directly into Haskell:

This defines a new function called. The first line says that the factorial of 0 is 1, and the second line says that the factorial of any other number  is equal to   times the factorial of. Note the parentheses around the ; without them this would have been parsed as  ; remember that function application (applying a function to a value) takes precedence over anything else when grouping isn't specified otherwise (we say that function application binds more tightly than anything else).

The example above demonstrates the simple relationship between factorial of a number, n, and the factorial of a slightly smaller number, n - 1.

Think of a function call as delegation. The instructions for a recursive function delegate a sub-task. It just so happens that the delegate function uses the same instructions as the delegator; it's only the input data that changes. The only really confusing thing about recursive functions is the fact that each function call uses the same parameter names, so it can be tricky to keep track of the many delegations.

Let's look at what happens when you execute :

 * 3 isn't 0, so we calculate the factorial of 2
 * 2 isn't 0, so we calculate the factorial of 1
 * 1 isn't 0, so we calculate the factorial of 0
 * 0 is 0, so we return 1.
 * To complete the calculation for factorial 1, we multiply the current number, 1, by the factorial of 0, which is 1, obtaining 1 (1 × 1).
 * To complete the calculation for factorial 2, we multiply the current number, 2, by the factorial of 1, which is 1, obtaining 2 (2 × 1 × 1).
 * To complete the calculation for factorial 3, we multiply the current number, 3, by the factorial of 2, which is 2, obtaining 6 (3 × 2 × 1 × 1).

(Note that we end up with the one appearing twice, since the base case is 0 rather than 1; but that's okay since multiplying by 1 has no effect. We could have designed  to stop at 1 if we had wanted to, but the convention (which is often useful) is to define the factorial of 0.)

When reading or composing recursive functions, you'll rarely need to “unwind” the recursion bit by bit — we leave that to the compiler.

One more note about our recursive definition of : the order of the two declarations (one for   and one for  ) is important. Haskell decides which function definition to use by starting at the top and picking the first one that matches. If we had the general case before the 'base case', then the general   would match anything passed into it – including 0. The compiler would then conclude that  equals , and so on to negative infinity (clearly not what we want). So, always list multiple function definitions starting with the most specific and proceeding to the most general.

Loops, recursion, and accumulating parameters
Imperative languages use loops in the same sorts of contexts where Haskell programs use recursion. For example, an idiomatic way of writing a factorial function in C, a typical imperative language, would be using a for loop, like this:

Here, the for loop causes  to be multiplied by   repeatedly. After each repetition,  is subtracted from   (that is what   does). The repetitions stop when  is no longer greater than.

A straightforward translation of such a function to Haskell is not possible, since changing the value of the variables  and   (a destructive update) would not be allowed. However, you can always translate a loop into an equivalent recursive form by making each loop variable into an argument of a recursive function. For example, here is a recursive “translation” of the above loop into Haskell:

is an auxiliary function which actually performs the factorial calculation. It takes an extra argument,, which is used as an accumulating parameter to build up the final result.

Other recursive functions
As it turns out, there is nothing particularly special about the  function; a great many numeric functions can be defined recursively in a natural way. For example, let's think about multiplication. When you were first learning multiplication (remember that moment? :)), it may have been through a process of 'repeated addition'. That is, 5 × 4 is the same as summing four copies of the number 5. Of course, summing four copies of 5 is the same as summing three copies, and then adding one more – that is, 5 × 4 = 5 × 3 + 5. This leads us to a natural recursive definition of multiplication:

Stepping back a bit, we can see how numeric recursion fits into the general recursive pattern. The base case for numeric recursion usually consists of one or more specific numbers (often 0 or 1) for which the answer can be immediately given. The recursive case computes the result by calling the function recursively with a smaller argument and using the result in some manner to produce the final answer. The 'smaller argument' used is often one less than the current argument, leading to recursion which 'walks down the number line' (like the examples of  and   above). However, the prototypical pattern is not the only possibility; the smaller argument could be produced in some other way as well.

List-based recursion
Haskell has many recursive functions, especially concerning lists. Consider the  function that finds the length of a list:

So, the type signature of  tells us that it takes any type of list and produces an. The next line says that the length of an empty list is 0 (this is the base case). The final line is the recursive case: if a list isn't empty, then it can be broken down into a first element (here called ) and the rest of the list (which will just be the empty list if there are no more elements) which will, by convention, be called   (i.e. plural of  ). The length of the list is 1 (accounting for the ) plus the length of   (as in the   example in Next steps,   is set when the argument list matches the  pattern).

Consider the concatenation function  which joins two lists together:

This is a little more complicated than. The type says that  takes two lists of the same type and produces another list of the same type. The base case says that concatenating the empty list with a list  is the same as   itself. Finally, the recursive case breaks the first list into its head and tail  and says that to concatenate the two lists, concatenate the tail of the first list with the second list, and then tack the head   on the front.

There's a pattern here: with list-based functions, the base case usually involves an empty list, and the recursive case involves passing the tail of the list to our function again, so that the list becomes progressively smaller.

Recursion is used to define nearly all functions to do with lists and numbers. The next time you need a list-based algorithm, start with a case for the empty list and a case for the non-empty list and see if your algorithm is recursive.

Don't get TOO excited about recursion...
Despite its ubiquity in Haskell, one rarely has to write functions that are explicitly recursive. Instead, standard library functions perform recursion for us in various ways. For example, a simpler way to implement the  function is:

Almost seems like cheating, doesn't it? :) This is the version of  that most experienced Haskell programmers would write, rather than the explicitly recursive version we started out with. Of course, the   function uses some list recursion behind the scenes, but writing   in this way means you, the programmer, don't have to worry about it.

title: Haskell/Recursion


text:
User:Robin Stocker

See my Wikipedia user page.

title: User:Robin Stocker


text:
Character Creation

Introduction
In literature, character refers to a human, animal or mythical being that forms part of the narrative. In some cases non living entities (for example, an artificial intelligence) can be a character. Definition of character is an essential component of all good fiction. This book takes you through the key elements of creating characters in your writing.

Broadly there are two types of character: the protagonist and the antagonist. The protagonist is the story's main character, central to the plot. The antagonist is the character in opposition to the protagonist. Two other definitions are frequently encountered: round characters and flat characters. Round characters are those that are fleshed out in detail, with, for example, a back story that explains their motivations. A flat character is less well rounded, possibly even one-dimensional. They are not usually central to the narrative. Indeed, making them central to the plot would probably be a mistake as their flatness makes them generally uninteresting to the reader.

The next pages take you through the steps to create a round character. To create a flat character, the same steps are followed but to a lower level of detail with, possibly, some sections missed out completely.

Pages

 * /Character background/
 * /Character personality/
 * /Character appearance/
 * /Little details/

title: Character Creation


text:
Chess Opening Theory/1. e4/1...d5/2. exd5/2...Qxd5/3. Nc3/3...Qd6

= Scandinavian Defense: Mieses-Kotrč, Gubinsky-Melts Defense = Rather than moving the queen to d8 or a5 after Nc3, the Gubinsky-Melts Defense opts to keep the queen in the center of the board, controlling many important squares, but allowing the queen to be a more ideal target compared to the queen going all the way back to d8 or a5, where it is tucked into a safer square.

Theory table
.

1. e4 d5 2. exd5 Qxd5 3.Nc3 Qd6


text:
Talk:Sufism

What is this even about?
I really don't know what this is about, and it looks a lot like it's been mis guiding truth seekers. The sufism is Reality of religion... Wikisquared 20:43, 8 July 2006 (UTC)

title: Talk:Sufism


text:
Character Creation/Character background

This section covers the creation of the character's background. The background is essential, even if it is not actually detailed in the story. As well as making the character more interesting and adding depth to the story, the author uses the background to ensure the character's behaviour remains consistent. For example, in one scene a character may take the stairs instead of the lift and consequently become involved in a situation. Earlier in the story the character may have used the lift and the reader will spot the inconsistency. But if the author has written up the background and stated that the character is claustrophobic, then they are less likely to forget that the character wouldn't use a lift.

The basics
Start out with writing down some of the basic facts:

 * Is your character male, female, neuter (say, a computer intelligence) or something of your own invention?
 * Where was your character born?
 * How old are they?
 * What is their current job?
 * What are their interests outside their job?
 * Who do they love? And who did they used to love?
 * Who are their enemies and friends?

Heritage
Now think about the character's heritage. Is your character Irish, German, African-American or from a made-up place? Make sure you try to bring out your character's heritage in their actions. Use the way they pronounce things, and how they feel about things to flag up their background. It is good practice to make your character with many different heritages, that way it will seem more realistic as real people have many different heritages in their history.

Your character's heritage (and current nationality) can affect other aspects of the character. For instance, if Brian is from Ireland, he will probably speak with an Irish accent, and be light skinned, and likely has a lot of freckles. Sancho, conversely, who is from Mexico, would speak with a Mexican accent, is probably dark skinned, and is treated differently by people than Brian.

But equally you should strive to avoid the stereotypes - Germans aren't all taciturn and humourless, Italians aren't all frivolous and amorous. Sometimes doing the opposite of the stereotypical view will surprise and interest your reader. How about a teetotal Australian?

Don't be afraid to try something original when creating a character. How about a character from the Côte d'Ivoire, even if it necessitates some research on that country?

When the heritage is made-up, for example your character is an alien, then you will have to work much harder to explain to the reader how their heritage affects their behaviour.

Empathise, don't sympathise
You need to understand why your character behaves the way they do. Don't give them motivations that you can't understand — because then you won't be able to write effectively about them. On the other hand, don't sympathise. If you find yourself feeling sorry for the character you'll be tempted to lessen the problems the character faces which will weaken the story.

"Roundedness"
Very few real people are monomaniacs. Your character should have things that drive them and things that repel them - but there should be more than one. Nobody is just a homicidal killer, nobody is just a mother caring for her children. For your character to feel real they must have enough traits to make the reader feel the person is more than just a caricature.

Name
The name of the character is important as names can have particular associations in certain cultures. For example, names like Adolf, Jesus and Mohamed immediately conjure an image of the real person with that name. It is usually best to choose the name last after the character is fully defined. This prevents you, the author, from creating a stereotype. Of course, these preconceptions can be useful ways of misleading the reader - naming a character who will sacrifice his life for others "Adolf" may trick the reader and create a strong surprise.

title: Character Creation/Character background


text:
Managing Groups and Teams/Effective Team Leadership

There are many elements that create and are essential to be an effective leader that has the power to motivate a team and drive success. There is often a balancing act that the leader must manage between being a leader and a member while ensuring the goal is clear and obtainable. There are six leadership competencies that are the building blocks to becoming an effective leader; focus on the goal, ensure a collaborative climate, build confidence, demonstrate sufficient technical know-how, set priorities, and manage performance as described When Teams Work Best by LaFasto and Larson. Therefore, the question arises, “Does an effective team leader both merge into the group as a member of the team and also maintain a leadership role? And if so, how?”

A leader is the key player in the game that is comprised of challenge and risk. Therefore, an effective team leader must be both a component to the team and also a leader to manage the team’s progress. The leader cannot possibly be competent in every area without being engaged in the team. The leader must know each member and the team as a whole in order to bring them all together and create a process that is open, productive, and promotes confidence. An effective leader uses each member’s contributions and energy to focus on a common goal. Essentially, a leader’s job is to add importance to the team’s effort, which cannot be done without being a member.

It is very common for a team leader to be in the dark about their team and the everyday operations. This is a consequence of a leader’s disengagement and lack of membership with the team. Moreover, the team’s contention usually gives birth at this point and lends itself to decreased productivity and satisfaction. An effective leader needs to be able to pinpoint problems and praise excellence within the group, which cannot be done from the sideline. The leader is a part of the overall process; therefore, a relationship naturally exists. However, it is up to the leader whether to nurture that relationship or minimize its importance. The team leader must understand the team’s vision and clearly define the goal to guarantee success and member loyalty. One cannot lead a team without knowing the purpose and goal of the team. Furthermore, a team leader must create a collaborative climate to ensure that the best thinking and ideas of the team are represented. Again, a wholesome climate cannot be established without knowing the members and becoming engaged in the team.

The foundation of a highly motivated and successful team is the member’s understanding and relevance of their goal. An effective leader’s trust in the team goal is vital to the member’s commitment. The members become isolated and discouraged when the leader’s investment is minimal. Team members want the opportunity to prove their value and worth to the goal and the leader. The leader must be involved and a member of the team to effectively influence the member’s productivity and function in the grand scheme of things.

There has been a gradual progression and contemporary focus on the leader’s mutual relationship with the members as opposed to the authority position in the modern day. This leader-member relationship breeds trust, confidence, stimulation, responsiveness, and problem solving which are the keys for success and satisfaction. As demonstrated, an effective leader should be a part and merge with the team and simultaneously lead and encourage it’s constituents toward the goal. The leader can bring inspiring growth or demise to a team and company; therefore, it is essential for a leader to be effective and powerful.


text:
Managing Groups and Teams/Dictatorship vs Leadership

The glory of a leader can be plagued and overshadowed by many concerns that can affect the team’s success. A leader must wear many hats and be able to lead and encourage a team to perform. It is necessary for a leader to become an engaged member of the team, but be able to lead at the same time. It is inevitable that different personalities, industries, and goals will force any leader to adapt and mold to fit the current environment. What is the best way to successfully encourage and lead a team? This is the million dollar question. Although each situation will present various opportunities and needs that a leader must meet, there will be some leadership styles that will impede the group each time.

What is the appropriate balance between being a dictator and being weak or a push over? A leader must be able to relate to the team and earn their respect and loyalty to the goal. This cannot be accomplished by being a dictator and micro managing the team and the members. A leader must manage and master the core competencies as illustrated in When Teams Work Best by LaFasto and Larson to be effective and respected. When a leader is a dictator it violates the concept of the leader being a part of the team. However, when a leader is not active or an integral link in the process then an unqualified leader evolves from the team pool, which creates dysfunction and chaos. At one extreme of the leadership spectrum is dictatorship. When a leader is a dictator they feel better because they have control and power. Leaders that have a high desire for control will have a significant impact on the team. Team members can identify when a dictator emerges and at that point it is very difficult for the leader to break out of this defined mold. As a result, the members shut down because they feel their contribution and ideas are not valued. This hampers the team’s identity, confidence, openness, and supportiveness. The ideas and actions now become that of the leader rather than a unique collection of the team. Conversely, the other end of the leadership spectrum involves being a push over or what can be interpreted as being disinterested or possessing little passion. When a designated leader expresses little desire or interest in the team goal then it is quite natural for an informal leader to emerge from the team. Consequently, the road toward the vision and goal becomes blocked with obstacles and the goal is more distant and foggy. Moreover, the members feel abandoned when the leader does not demonstrate a concern or responsibility in the decision. This forces the members to guess the leader’s perspective and ultimately they begin to question their ability to lead, which devalues their trust and confidence in their leader. The ideas and actions of the group become less creative and effective because the members don’t feel important.

Therefore, a leader must discover the appropriate balance and walk the fine line. An effective leader needs to provide direction and share their ideas while building the member’s confidence. It is much easier for a leader to argue and fight for their point of view when they haven’t transformed into a dictator. A leader should manage their control and exhibit their care and passion by sharing the control with the team. When the control and power is balanced and shared between the leader and the team issues such as what gets discussed and possible solutions and actions now become a collective effort. Resultantly, this type of relationship and arrangement leads to a high level of trust and satisfaction. And it is common knowledge that these are fundamental elements for a productive and happy team and group.


text:
Character Creation/Character personality

Is your character mean, nice, stupid? That can be determined all by their personality...

Personality mix
Most characters have three personalities. The first two mixed together to make their main personality, and the third one arising when danger is near, e. g. Character number one's main personality is a mix of harshness and intelligence, while in a dangerous situation he would be brave.

Sometimes there are a characters with four personality types, the first three being their main personality, and the fourth appearing what they face danger (the personalities could be split so that the third and fourth are displayed when danger arises).


text:
User talk:144.226.173.68

Jambands
I have deleted the page Jambands because it does not appear to be a textbook. If you do wish to write a textbook on the subject, then please recreate the page after reading WB:NEW. Thanks. --hagindaz 23:22, 8 July 2006 (UTC)

title: User talk:144.226.173.68


text:
Character Creation/Character appearance

The appearance of a character is important, but remember as a writer you are describing the appearance and much will be left to the readers' imagination. Of course, if you are writing for film or television or for a visual work like a comic book, then appearance becomes more important.

Physical attributes
You should decide the physical attributes of your character. At the least you should consider:

 * Height - are they tall, short, average?
 * Weight - are they overweight, underweight, average?
 * Skin tone and freckles, eye color
 * Distinguishing features - birthmarks, scars, tattoos
 * Hair color- brunette, blonde?
 * Hair length-short, long shoulder length?
 * Other- ethnicity (race), sexuality

Some of these attributes will be worked into the story early on to allow the reader to form an image of the character in their "minds eye". Others will be returned to as important plot devices. You should try to avoid the stereotypes - not all pirates have only one eye and have a false leg!

For aliens, physical attributes must be more detailed as the reader needs more help to picture the creature.

Accessories
Think about the things your character carries and uses and whether any should be distinctive. Think of Doctor Who's sonic screwdriver, James Bond's Walther PPK, the Crocodile in Peter Pan's clock! These are all iconic accessories. People in real life tend to favor certain items and these items are part of how we recognize them and think of them. The glasses they wear, the type of watch they use, the jewellery they wear. Add accessories to shape your character. Are they fascinated with antiques? Give them a pocket watch instead of a wristwatch... Do they hanker after the past? Give them an old car like Morse had.

Clothing
Clothing is usually more a plot point than part of characterization. Your character will have types of clothing they wear more frequently - smart or casual for example. However, they are likely to change their clothing during the story based on the requirements of the plot. A good example of when clothing is a strong part of character is Arthur Dent in The Hitchhiker's Guide to the Galaxy where he wears a dressing gown and pajamas throughout the story. The difficulty with clothing is that it can very easily create a caricature.

title: Character Creation/Character appearance


text:
Write Yourself a Scheme in 48 Hours

Contents

 * 1) Overview
 * 2) First Steps: Compiling and running
 * 3) /Parsing/
 * 4) /Evaluation, Part 1/
 * 5) /Error Checking and Exceptions/
 * 6) /Evaluation, Part 2/
 * 7) Building a REPL: Basic I/O
 * 8) Adding Variables and Assignment: Mutable State in Haskell
 * 9)  Defining Scheme Functions: Closures and Environments
 * 10)  Creating IO Primitives: File I/O
 * 11)  Towards a Standard Library: Fold and Unfold
 * 12)  Conclusion & Further Resources
 * 13)  Answers to Exercises

48時間でSchemeを書こう Write Yourself a Scheme in 48 Hours

title: Write Yourself a Scheme in 48 Hours


text:
Write Yourself a Scheme in 48 Hours/First Steps

First, you'll need to install GHC. On GNU/Linux, it's often pre-installed or available via the package manager ( or   or   for example, depending on your distribution). It's also downloadable from http://www.haskell.org/ghc/. A binary package is probably easiest, unless you really know what you're doing. It should download and install like any other software package. This tutorial was developed on GNU/Linux, but everything should also work on Windows, as long as you know how to use the command line, or on the Macintosh from within the Terminal.

For UNIX (or Windows Emacs) users, there is a pretty good Emacs mode, including syntax highlighting and automatic indentation. Windows users can use Notepad or any other text editor: Haskell syntax is fairly Notepad-friendly, though you have to be careful with the indentation. Eclipse users might want to try the eclipsefp plug-in.

Now, it's time for your first Haskell program. This program will read a name off the command line and then print a greeting. Create a file ending in ".hs" and type the following text. Be sure to get the indentation right, or else it may not compile. Let's go through this code. The first two lines specify that we'll be creating a module named Main that imports the System module. Every Haskell program begins with an action called  in a module named. That module may import others, but it must be present for the compiler to generate an executable file. Haskell is case-sensitive: module names are always capitalized, definitions always uncapitalized.

The line  is a type declaration: it says that   is of type , which is an IO action carrying along values of unit type. A unit type allows only one value, also denoted, thus holding no information. Type declarations in Haskell are optional: the compiler figures them out automatically, and only complains if they differ from what you've specified. In this tutorial, I specify the types of all declarations explicitly, for clarity. If you're following along at home, you may want to omit them, because it's less to change as we build our program.

The IO type is an instance of the Monad class (a class of types). Monad is a concept. To say a value is of a type of the monad class is to say:

In this example,
 * 1) there is (a certain type of) extra information attached to this value;
 * 2) most functions do not need to worry about these pieces of information.

 * 1) the "extra information" is IO actions to be performed using the carried along values;
 * 2) while the basic value (which attached with information) is void, represented as.

Both  and   belong to the same   monad type, but they have different base types. They act on (and pass along) values of different types,  and.

"value attached with (hidden) information" is called "Monadic value".

"Monadic value" is often called "actions", because the easiest way to think about the using of IO monad is to think about a sequence of actions affecting the outside world. The sequence of actions maybe pass along basic values, and each action is able to act on the values.

Haskell is a functional language: instead of giving the computer a sequence of instructions to carry out, you give it a collection of definitions that tell it how to perform every function it might need. These definitions use various compositions of actions and functions. The compiler figures out an execution path that puts everything together.

To write one of these definitions, you set it up as an equation. The left hand side defines a name, and optionally one or more patterns (explained later) that will bind variables. The right hand side defines some composition of other definitions that tells the computer what to do when it encounters the name. These equations behave just like ordinary equations in algebra: you can always substitute the right hand side for the left within the text of the program, and it'll evaluate to the same value. Called "referential transparency", this property makes it significantly easier to reason about Haskell programs than other languages.

How will we define our  action? We know that it must be an  action, which we want to read the command line args and print some output, producing , or nothing of value, eventually.

There are two ways to create an IO action (either directly or by calling a function that performs them):

 * 1) Lift an ordinary value into the IO monad, using the   function.
 * 2) Combine two existing IO actions.

Since we want to do two things, we'll take the second approach. The built-in action getArgs reads the command-line arguments and passes them along as a list of strings. The built-in function putStrLn takes a string and creates an action that writes this string to the console.

To combine these actions, we use a do-block. A do-block consists of a series of lines, all lined up with the first non-whitespace character after the do. Each line can have one of two forms:

The first form binds the result of action1 to name, to be available in next actions. For example, if the type of action1 is  (an IO action returning a list of strings, as with  ), then name will be bound in all the subsequent actions to the list of strings thus passed along, through the use of "bind" operator. The second form just executes action2, sequencing it with the next line (should there be one) through the  operator. The bind operator has different semantics for each monad: in the case of the IO monad, it executes the actions sequentially, performing whatever external side-effects that result from actions. Because the semantics of this composition depend upon the particular monad used, you cannot mix actions of different monad types in the same do-block - only  monad can be used (it's all in the same "pipe").

Of course, these actions may themselves call functions or complicated expressions, passing along their results (either by calling the  function, or some other function that eventually does so). In this example, we first take the first element of the argument list (at index 0, ), concatenate it onto the end of the string "Hello, ", and finally pass that to   which creates new IO action, participating in the do-block sequencing.

A new action thus created, which is a combined sequence of actions as described above, is stored in the identifier  of type. The Haskell system notices this definition, and executes the action in it.

Strings are lists of characters in Haskell, so you can use any of the list functions and operators on them. A full table of the standard operators and their precedences follows:

To compile and run the program, try something like this:

debian:/home/jdtang/haskell_tutorial/code# ghc -o hello_you --make listing2.hs debian:/home/jdtang/haskell_tutorial/code# ./hello_you Jonathan Hello, Jonathan

The  option specifies the name of the executable you want to create, and then you just specify the name of the Haskell source file.


text:
Write Yourself a Scheme in 48 Hours/Parsing

Making project scaffolding and getting parsec
We'll be using the Parsec library. To install it, you'll need, which is invoked with the   command.

On Debian/Ubuntu:. Alternatively, you can use ghcup, which works for many platforms.

After installing, let's make a project:

Now edit  such that   is listed in   listing, in addition to.

Now, the project can be run using :

Building executable 'myProject' for myProject-0.1.0.0.. [1 of 1] Compiling Main            ( app/Main.hs ) Linking myProject-0.1.0.0/x/myProject/build/myProject/myProject ... Hello, Haskell!

The last line is the output by the program.

Writing a Simple Parser
Now, let's try writing a very simple parser.

Start by adding these lines to the import section of  (which was generated by  ): This makes the Parsec library functions available to us, except the  function, whose name conflicts with a function that we'll be defining later.

Now, we'll define a parser that recognizes one of the symbols allowed in Scheme identifiers: This is another example of a monad: in this case, the "extra information" that is being hidden is all the info about position in the input stream, backtracking record, first and follow sets, etc. Parsec takes care of all of that for us. We need only use the Parsec library function, and it'll recognize a single one of any of the characters in the string passed to it. Parsec provides a number of pre-built parsers: for example, and  are library functions. And as you're about to see, you can compose primitive parsers into more sophisticated productions.

Let's define a function to call our parser and handle any possible errors: As you can see from the type signature,  is a function  from a   to a. We name the parameter, and pass it, along with the   parser we defined above to the Parsec function. The second parameter to  is a name for the input. It is used for error messages.

can return either the parsed value or an error, so we need to handle the error case. Following typical Haskell convention, Parsec returns an data type, using the   constructor to indicate an error and the   one for a normal value.

We use a  construction to match the result of   against these alternatives. If we get a  value (error), then we bind the error itself to   and return "No match" with the string representation of the error. If we get a  value, we bind it to , ignore it, and return the string "Found value".

The  construction is an example of pattern matching, which we will see in much greater detail later on.

Finally, we need to change our main function to call  and print out the result: To compile and run this, you can specify the command line parameters after the "executable target" which the project scaffolding generated with the call to  in the first section. For example:

$ cabal run myProject $ Found value $ cabal run myProject a No match: "lisp" (line 1, column 1): unexpected "a"

Whitespace
Next, we'll add a series of improvements to our parser that'll let it recognize progressively more complicated expressions. The current parser chokes if there's whitespace preceding our symbol:

$ cabal run myProject "  %" No match: "lisp" (line 1, column 1): unexpected " "

Let's fix that, so that we ignore whitespace.

First, lets define a parser that recognizes any number of whitespace characters. Incidentally, this is why we included the  clause when we imported Parsec: there's already a  function in that library, but it doesn't quite do what we want it to. (For that matter, there's also a parser called that does exactly what we want, but we'll ignore that for pedagogical purposes.) Just as functions can be passed to functions, so can actions. Here we pass the Parser action to the Parser action, to get a Parser that will recognize one or more spaces.

Now, let's edit our parse function so that it uses this new parser: We touched briefly on the  ("bind") operator in lesson 2, where we mentioned that it was used behind the scenes to combine the lines of a do-block. Here, we use it explicitly to combine our whitespace and symbol parsers. However, bind has completely different semantics in the Parser and IO monads. In the Parser monad, bind means "Attempt to match the first parser, then attempt to match the second with the remaining input, and fail if either fails." In general, bind will have wildly different effects in different monads; it's intended as a general way to structure computations, and so needs to be general enough to accommodate all the different types of computations. Read the documentation for the monad to figure out precisely what it does.

Compile and run this code. Note that since we defined  in terms of , it will no longer recognize a plain old single character. Instead you have to precede a symbol with some whitespace. We'll see how this is useful shortly:

$ cabal run myProject "  %" Found value $ cabal run myProject % No match: "lisp" (line 1, column 1): unexpected "%" expecting space $ cabal run myProject "  abc" No match: "lisp" (line 1, column 4): unexpected "a" expecting space

Return Values
Right now, the parser doesn't do much of anything—it just tells us whether a given string can be recognized or not. Generally, we want something more out of our parsers: we want them to convert the input into a data structure that we can traverse easily. In this section, we learn how to define a data type, and how to modify our parser so that it returns this data type.

First, we need to define a data type that can hold any Lisp value: This is an example of an algebraic data type: it defines a set of possible values that a variable of type LispVal can hold. Each alternative (called a constructor and separated by ) contains a tag for the constructor along with the type of data that the constructor can hold. In this example, a  can be:

 * 1) An , which stores a String naming the atom
 * 2) A , which stores a list of other LispVals (Haskell lists are denoted by brackets); also called a proper list
 * 3) A , representing the Scheme form  ; also called an improper list. This stores a list of all elements but the last, and then stores the last element as another field
 * 4) A , containing a Haskell Integer
 * 5) A , containing a Haskell String
 * 6) A , containing a Haskell boolean value

Constructors and types have different namespaces, so you can have both a constructor named  and a type named. Both types and constructor tags always begin with capital letters.

Next, let's add a few more parsing functions to create values of these types. A string is a double quote mark, followed by any number of non-quote characters, followed by a closing quote mark: We're back to using the -notation instead of the   operator. This is because we'll be retrieving the value of our parse (returned by ) and manipulating it, interleaving some other parse operations in the meantime. In general, use  if the actions don't return a value,   if you'll be immediately passing that value into the next action, and  -notation otherwise.

Once we've finished the parse and have the Haskell String returned from, we apply the   constructor (from our LispVal data type) to turn it into a. Every constructor in an algebraic data type also acts like a function that turns its arguments into a value of its type. It also serves as a pattern that can be used in the left-hand side of a pattern-matching expression; we saw an example of this in Lesson 3.1 when we matched our parser result against the two constructors in the  data type.

We then apply the built-in function  to lift our   into the   monad. Remember, each line of a -block must have the same type, but the result of our String constructor is just a plain old LispVal. lets us wrap that up in a Parser action that consumes no input but returns it as the inner value. Thus, the whole  action will have type.

The  operator is infix function application: it's the same as if we'd written , but   is right associative and low precedence, letting us eliminate some parentheses. Since  is an operator, you can do anything with it that you'd normally do to a function: pass it around, partially apply it, etc. In this respect, it functions like the Lisp function.

Now let's move on to Scheme variables. An atom is a letter or symbol, followed by any number of letters, digits, or symbols: Here, we introduce another Parsec combinator, the choice operator. This tries the first parser, then if it fails, tries the second. If either succeeds, then it returns the value returned by that parser. The first parser must fail before it consumes any input: we'll see later how to implement backtracking.

Once we've read the first character and the rest of the atom, we need to put them together. The " " statement defines a new variable. We use the list cons operator  for this. Instead of, we could have used the concatenation operator   like this  ; recall that   is just a single character, so we convert it into a singleton list by putting brackets around it.

Then we use a case expression to determine which  to create and return, matching against the literal strings for true and false. The underscore  alternative is a readability trick: case blocks continue until a   case (or fail any case which also causes the failure of the whole   expression), think of   as a wildcard. So if the code falls through to the  case, it always matches, and returns the value of.

Finally, we create one more parser, for numbers. This shows one more way of dealing with monadic values: It's easiest to read this backwards, since both function application and function composition  associate to the right. The parsec combinator many1 matches one or more of its argument, so here we're matching one or more digits. We'd like to construct a number  from the resulting string, but we have a few type mismatches. First, we use the built-in function read to convert that string into a number. Then we pass the result to  to get a. The function composition operator  creates a function that applies its right argument and then passes the result to the left argument, so we use that to combine the two function applications.

Unfortunately, the result of  is actually a , so our combined   still can't operate on it. We need a way to tell it to just operate on the value inside the monad, giving us back a. The standard function  does exactly that, so we apply   to our   function, and then apply the result of that to our parser.

We also have to import the Monad module up at the top of our program to get access to : This style of programming—relying heavily on function composition, function application, and passing functions to functions—is very common in Haskell code. It often lets you express very complicated algorithms in a single line, breaking down intermediate steps into other functions that can be combined in various ways. Unfortunately, it means that you often have to read Haskell code from right-to-left and keep careful track of the types. We'll be seeing many more examples throughout the rest of the tutorial, so hopefully you'll get pretty comfortable with it.

Let's create a parser that accepts either a string, a number, or an atom: And edit readExpr so it calls our new parser: Compile and run this code, and you'll notice that it accepts any number, string, or symbol, but not other strings:

$ cabal run myProject "\"this is a string\"" Found value $ cabal run myProject 25 Found value $ cabal run myProject symbol Found value $ cabal run myProject (symbol) bash: syntax error near unexpected token `symbol' $ cabal run myProject "(symbol)" No match: "lisp" (line 1, column 1): unexpected "(" expecting letter, "\"" or digit

Recursive Parsers: Adding lists, dotted lists, and quoted datums
Next, we add a few more parser actions to our interpreter. Start with the parenthesized lists that make Lisp famous: This works analogously to, first parsing a series of expressions separated by whitespace  and then apply the List constructor to it within the Parser monad. Note too that we can pass  to sepBy, even though it's an action we wrote ourselves.

The dotted-list parser is somewhat more complex, but still uses only concepts that we're already familiar with: Note how we can sequence together a series of Parser actions with  and then use the whole sequence on the right hand side of a do-statement. The expression  returns a , then combining that with   gives a  , exactly the type we need for the do-block.

Next, let's add support for the single-quote syntactic sugar of Scheme: Most of this is fairly familiar stuff: it reads a single quote character, reads an expression and binds it to, and then returns  , to use Scheme notation. The  constructor works like an ordinary function: you pass it the String you're encapsulating, and it gives you back a LispVal. You can do anything with this LispVal that you normally could, like put it in a list.

Finally, edit our definition of parseExpr to include our new parsers: This illustrates one last feature of Parsec: backtracking. and  recognize identical strings up to the dot; this breaks the requirement that a choice alternative may not consume any input before failing. The try combinator attempts to run the specified parser, but if it fails, it backs up to the previous state. This lets you use it in a choice alternative without interfering with the other alternative.

Compile and run this code:

$ cabal run myProject "(a test)" Found value $ cabal run myProject "(a (nested) test)" Found value $ cabal run myProject "(a (dotted . list) test)" Found value $ cabal run myProject "(a '(quoted (dotted . list)) test)" Found value $ cabal run myProject "(a '(imbalanced parens)" No match: "lisp" (line 1, column 24): unexpected end of input expecting space or ")"

Note that by referring to  within our parsers, we can nest them arbitrarily deep. Thus, we get a full Lisp reader with only a few definitions. That's the power of recursion.