Project Navigator. Here you will find all the files that make up your Haskell project. You can arrange them in folders and they are distributed over three groups: (1) Haskell modules, (2) non-Haskell code, and (3) resource files. All your Haskell code goes into the first group, using one file per Haskell module. The second group is for non-Haskell files that are processed by a tool, such as text in markdown format. Finally, the third group is for resources, such as images or data files, that your Haskell code processes. At the very top of the project navigator is a single item representing your project’s metadata — you can select it to view and edit that metadata.
Playground. Each Haskell module automatically gets its own associated playground, where all defintions of that module are accessible, whether they are exported or not. It is the perfect place to test and experiment with the definitions of the associated module.
Playground Editor. This is where you can write and edit the statements comprising a playground. Each line that has text in the leftmost column begins a new playground statement. All further lines of a playground statment need to be indented, following Haskell’s layout rules.
Playground statements can be simple expressions, but also function definitions, type or class declarations, module imports, or language pragmas. Whatever form they take, they are constantly re-evaluated as you change either the Haskell module or the playground statements.
Module Editor. This is where you edit individual Haskell modules — that is, Haskell source files with the suffix ’.hs’. Haskell modules may contain function definitions, type and class declarations, as well as import declarations to access other modules; all as set out in the Haskell language standard. Haskell for Mac also supports all of the language extensions provided by the Glasgow Haskell Compiler. Language extensions can be enabled on a module by module basis using LANGUAGE pragmas at the top of a module.
A common mistake. In the playground editor (as opposed to the module editor), variable bindings as well as function definitions must be introduced by the let keyword.
NB: Each module must start with a module header of the form
module MODULE_NAME where
The module name must match the file name and, if it is nested inside one or more folders, it must also include the folder names separated by a dot. For example, a module called ’Display’ insider a folder ’Database’ that is inside a folder ’Generic’ must use ’Generic.Database.Display’ as its module name. There is one exception! The main module of a program is implicitly called ’Main’ if the module header is omitted. This is the case in the ’FirstSteps’ example above.
Diagnostics. There are three kinds of diagnostics: (1) warnings, (2) deferred type errors, and (3) fatal errors. You should address the first two kinds, but they will not prevent you from experimenting with your code in a playground — which is often very useful in determining the source of the problem.
Playground Results & Types. The playground results area shows a preview of expression evaluation, which may be textual or graphical. It’s vertical size depends on how many lines the corresponding playground statement occupies. You can easily increase the size of the preview by adding some empty lines after the playground statement. To display a complete result in a popover window, click on the preview. To the right of the result preview is the type of the statement (or of the bindings introduced by the statement). If the type is truncated, hover the mouse over the truncated type to see the entire type.
Console. The playground result view displays the value returned from expression evaluation. However, I/O actions (such as print or putStr) may also write text to the standard output stream. This text is displayed in the console area. Optionally, the console will also display text written to the standard error stream. Whether or not that is the case can be controlled in the application preferences.
Deferred Type Errors. To reap the safety benefits of strong static typing, you need to fix all type errors before deploying a program. Nonetheless, during rapid prototyping and refactoring, it is often useful to ignore some type errors for a bit, while still being able to run the code. Deferred type errors combine the assurances of rigorous type checking with the flexibility of untyped code during development. If the execution of an incorrectly typed piece of code is attempted at runtime, an exception with a type error message is raised.
Nontermination. Haskell for Mac deals gracefully with most nonterminating Haskell expressions. However, if memory allocation runs out of bounds, Haskell for Mac will become non-responsive in the current version.
Experiment. The button labelled ”Experiment” at the left hand side of the toolbar re-executes the playground code. If the playground pane is hidden, it will also be revealed. The button is disabled if there are any fatal errors in the Haskell module.
Playground code is executed right away, while you are writing and changing it. Inspect the results immediately, whether they are text, images, or animations.
Animated, graphical scenes are interactive. Test them in the playground, change the code, and immediately observe the effect of your changes.
©2016 Applicative. All Rights Reserved. ABN 98 214 510 772.
Apple, the Apple logo, Mac and macOS are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.