Home ›

Translate Haskell into English Manually

Jun 21, 2006  By Shannon Behrens
 in
Write a program in Haskell that translates C type declarations into English.
Interlude

In the next part of this two part series, I'll build upon the concept of a parse pipeline with the State monad. Then, with all the pieces in place, I'll show the complete Haskell program. I'll also take a step back for some closing commentary.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Part 2

Shannon -jj Behrens's picture
Submitted by Shannon -jj Behrens (not verified) on Mon, 08/07/2006 - 19:33.

Let me try that again: part 2 is at:

http://www.linuxjournal.com/article/9242

Part 2

Shannon -jj Behrens's picture
Submitted by Shannon -jj Behrens (not verified) on Thu, 08/03/2006 - 12:16.

Here's part two: http://www.linuxjournal.com/article/9242.

output function

Oliver Mooney's picture
Submitted by Oliver Mooney (not verified) on Mon, 07/24/2006 - 09:54.

The output function isn't defined in the Haskell source code given. If it's operating on your ParseContext type, presumably you'd have to write it yourself? I know it'd be a pretty simple function, but I'm just checking that you do have to write it yourself, and that's it's not generated automatically via some form of Haskell magic?

output function

Shannon -jj Behrens's picture
Submitted by Shannon -jj Behrens (not verified) on Mon, 07/24/2006 - 15:14.

It comes for free because of the words "deriving Show". There's a whole paragraph on this in the next part of the article.

Thanks for reading!

output != output

Shannon -jj Behrens's picture
Submitted by Shannon -jj Behrens (not verified) on Tue, 07/25/2006 - 10:19.

Ugh, looking back, I got confused. When you said "output" function, you were literally talking about the function named "output", whereas I instantly jumped to the conclusion that you were talking about the function used to do output. Sorry for the confusion.

output function

Oliver Mooney's picture
Submitted by Oliver Mooney (not verified) on Tue, 07/25/2006 - 06:40.

So any type deriving from the Show class becomes compatible with the 'output' function which expects instances of the Show class? Or is it that the Show class allows each field of a type to be referred to by field name?

Using the following as a minimal example:

data ParseContext = ParseContext {
input :: String, -- The input that has not been parsed yet.
output :: String -- The output generated so far.
} deriving Show

executing the following at the Hugs prompt:
output (ParseContext {input = "", output = "some text"})
gives "some text" as a response.

But changing the name of the output field to outputB gives an error when using the function 'output', resolved by using a corresponding function name of 'outputB'. So is it that field names become functions, presumably with the type ParseContext -> String ?

Incidentally, I tried dropping off the 'deriving Show' declaration and accessing fields by name still works, perhaps because String instances already derive Show?

I know I'm probably belabouring the obvious here, I'm just trying to pin the origin of specific functionality down, which has been my biggest bugbear with learning Haskell to date. Looking forward to part 2!

output function

Shannon -jj Behrens's picture
Submitted by Shannon -jj Behrens (not verified) on Tue, 07/25/2006 - 10:15.

Using the following as a minimal example:

data ParseContext = ParseContext {
input :: String, -- The input that has not been parsed yet.
output :: String -- The output generated so far.
} deriving Show

Haskell automatically creates functions "input" and "output" of type "ParseContext -> String" as you suggested. This comes for free and has nothing to do with "deriving Show". As another commenter commented, what would be "ctx.output" in Java is "output ctx" in Haskell.

What "deriving Show" gives you is the ability to call "show ctx" which has type "something that is showable -> String". Imagine an interface in Java that has one method, "toString()". "deriving show" means that not only should ParseContext implement that interface, but the compiler should automatically figure out a reasonable implementation for what in Java would be the "toString()" method. What Java calls an interface, Haskell calls a type class (which is a horribly confusing re-use of the word class). ParseContext is a member of the Show type class. This is documented here.

My hope is that if you take your time studying my article, you won't have as hard a time reading other Haskell tutorials as I did ;)

By the way, I just asked the editor to hurry up and publish the second half ;)

output function

Oliver Mooney's picture
Submitted by Oliver Mooney (not verified) on Wed, 07/26/2006 - 08:59.

Thanks Shannon, that's much clearer now.

I'm a Haskell beginner, but

Luke Plant's picture
Submitted by Luke Plant (not verified) on Mon, 07/24/2006 - 12:03.

I'm a Haskell beginner, but I', pretty sure the 'output' function is defined implicitly in ParseContext. In a typical OO language, you would have:

instance_of_ParseContext.output

but in Haskell you have:

output instance_of_ParseContext

output function

Oliver Mooney's picture
Submitted by Oliver Mooney (not verified) on Tue, 07/25/2006 - 06:43.

That's my understanding too I think! It's funny, I'd implicitly associated field access in that way with OO programming, but I guess there's no reason it shouldn't apply to functional programming too. I'd gotten out of the habit of equating objects with types but it looks like I took it too far.

off to an excellent start

Martin DeMello's picture
Submitted by Martin DeMello (not verified) on Thu, 06/22/2006 - 14:00.

looking forward to the second half!

Money Maker

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 06/23/2006 - 22:18.

I think this is going to be a big miney maker I am sure he will have all sorts of compaines knockin gon his door asking to patent the program!

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions