text:
Utilities and combinators for parsing command line options
Version on this page: | 0.14.3.0@rev:2 |
LTS Haskell 22.30: | 0.18.1.0 |
Stackage Nightly 2024-07-23: | 0.18.1.0 |
Latest on Hackage: | 0.18.1.0 |
optparse-applicative is a haskell library for parsing options on the command line, providing a powerful applicative interface for composing these options.
optparse-applicative takes care of reading and validating the arguments passed to the command line, handling and reporting errors, generating a usage line, a comprehensive help screen, and enabling context-sensitive bash, zsh, and fish completions.
Table of Contents
- Introduction
- Quick Start
- Basics
- Builders
- Custom parsing and error handling
- Bash completion
- Arrow interface
- Applicative Do
- How it works
The core type in optparse-applicative is a Parser
data Parser a
instance Functor Parser
instance Applicative Parser
instance Alternative Parser
A value of type Parser a
represents a specification for a set of
options, which will yield a value of type a
when the command line
arguments are successfully parsed.
If you are familiar with parser combinator libraries like parsec, attoparsec, or the json parser aeson you will feel right at home with optparse-applicative.
If not, don't worry! All you really need to learn are a few basic
parsers, and how to compose them as instances of Applicative
Quick Start
Here's a simple example of a parser.
import Options.Applicative
import Data.Semigroup ((<>))
data Sample = Sample
{ hello :: String
, quiet :: Bool
, enthusiasm :: Int }
sample :: Parser Sample
sample = Sample
<$> strOption
( long "hello"
<> metavar "TARGET"
<> help "Target for the greeting" )
<*> switch
( long "quiet"
<> short 'q'
<> help "Whether to be quiet" )
<*> option auto
( long "enthusiasm"
<> help "How enthusiastically to greet"
<> showDefault
<> value 1
<> metavar "INT" )
The parser is built using an applicative style starting from a
set of basic combinators. In this example, hello is defined as an
option with a String
argument, while quiet is a boolean flag
(called a switch) and enthusiasm gets parsed as an Int
with help
of the Read
type class.
The parser can be used like this:
main :: IO ()
main = greet =<< execParser opts
opts = info (sample <**> helper)
( fullDesc
<> progDesc "Print a greeting for TARGET"
<> header "hello - a test for optparse-applicative" )
greet :: Sample -> IO ()
greet (Sample h False n) = putStrLn $ "Hello, " ++ h ++ replicate n '!'
greet _ = return ()
The greet
function is the entry point of the program, while opts
is a complete description of the program, used when generating a
help text. The helper
combinator takes any parser, and adds a
option to it.
The hello
option in this example is mandatory since it doesn't
have a default value, so running the program without any argument
will display an appropriate error message and a short option summary:
Missing: --hello TARGET
Usage: hello --hello TARGET [-q|--quiet] [--enthusiasm INT]
Print a greeting for TARGET
Running the program with the --help
option will display the full help text
containing a detailed list of options with descriptions
hello - a test for optparse-applicative
Usage: hello --hello TARGET [-q|--quiet] [--enthusiasm INT]
Print a greeting for TARGET
Available options:
--hello TARGET Target for the greeting
-q,--quiet Whether to be quiet
--enthusiasm INT How enthusiastically to greet (default: 1)
-h,--help Show this help text
optparse-applicative provides a number of primitive parsers, corresponding to different posix style options, through its Builder interface. These are detailed in their own section below, for now, here's a look at a few more examples to get a feel for how parsers can be defined.
Here is a parser for a mandatory option with an argument:
target :: Parser String
target = strOption
( long "hello"
<> metavar "TARGET"
<> help "Target for the greeting" )
One can see that we are defining an option parser for a String
argument, with long option name "hello", metavariable "TARGET",
and the given help text. This means that the target
parser defined
above will require an option like
--hello world
on the command line. The metavariable and the help text will appear in the generated help text, but don't otherwise affect the behaviour of the parser.
The attributes passed to the option are called modifiers, and are
composed using the semigroup operation (<>)
Options with an argument such as target
are referred to as regular
options, and are very common. Another type of option is a flag,
the simplest of which is a boolean switch, for example:
quiet :: Parser Bool
quiet = switch ( long "quiet" <> short 'q' <> help "Whether to be quiet" )
Here we used a short
modifier to specify a one-letter name for
the option. This means that this switch can be set either with
or -q
Flags, unlike regular options, have no arguments. They simply return
a predetermined value. For the simple switch above, this is True
if the user types the flag, and False
There are other kinds of basic parsers, and several ways to configure them. These are covered in the Builders section.
Now we may combine the target
and quiet
into a single parser that
accepts both options and returns a combined value. Given a type
data Options = Options
{ optTarget :: String
, optQuiet :: Bool }
and now it's just a matter of using Applicative
's apply operator (<*>)
to combine the two previously defined parsers
opts :: Parser Options
opts = Options <$> target <*> quiet
No matter which parsers appear first in the sequence, options will still be parsed in whatever order they appear in the command line. A parser with such a property is sometimes called a permutation parser.
In our example, a command line like:
--target world -q
will give the same result as
-q --target world
It is this property which leads us to an Applicative interface instead of a Monadic one, as all options must be considered in parallel, and can not depend on the output of other options.
Note, however, that the order of sequencing is still somewhat significant, in that it affects the generated help text. Customisation can be achieved easily through a lambda abstraction, with Arrow notation, or by taking advantage of GHC 8's ApplicativeDo extension.
It is also common to find programs that can be configured in different ways through the command line. A typical example is a program that can be given a text file as input, or alternatively read it directly from the standard input.
We can model this easily and effectively in Haskell using sum types:
data Input
= FileInput FilePath
| StdInput
run :: Input -> IO ()
run = ...
We can now define two basic parsers for the components of the sum type:
fileInput :: Parser Input
fileInput = FileInput <$> strOption
( long "file"
<> short 'f'
<> metavar "FILENAME"
<> help "Input file" )
stdInput :: Parser Input
stdInput = flag' StdInput
( long "stdin"
<> help "Read from stdin" )
As the Parser
type constructor is an instance of Alternative
, we can
compose these parsers with a choice operator (<|>)
input :: Parser Input
input = fileInput <|> stdInput
Now --file "foo.txt"
will be parsed as FileInput "foo.txt"
, --stdin
will be parsed as StdInput
, but a command line containing both options,
--file "foo.txt" --stdin
will be rejected.
Having Applicative
and Alternative
instances, optparse-applicative
parsers are also able to be composed with standard combinators. For
example: optional :: Alternative f => f a -> f (Maybe a)
mean the user is not required to provide input for the affected
Running parsers
Before we can run a Parser
, we need to wrap it into a ParserInfo
structure, that specifies a number of properties that only apply
to top level parsers, such as a header describing what the program
does, to be displayed in the help screen.
The function info
will help with this step. In the Quick Start
we saw
opts :: ParserInfo Sample
opts = info (sample <**> helper)
( fullDesc
<> progDesc "Print a greeting for TARGET"
<> header "hello - a test for optparse-applicative" )
The helper
parser that we added after opts
just creates a dummy
option that displays the help text. Besides that, we just
set some of the fields of the ParserInfo
structure with meaningful
values. Now that we have a ParserInfo
, we can finally run the
parser. The simplest way to do so is to simply call the execParser
function in your main
main :: IO ()
main = do
options <- execParser opts
The execParser
function takes care of everything, including getting
the arguments from the command line, displaying errors and help
screens to the user, and exiting with an appropriate exit code.
There are other ways to run a ParserInfo
, in situations where you
need finer control over the behaviour of your parser, or if you
want to use it in pure code. They will be covered in Custom parsing
and error handling.
Builders allow you to define parsers using a convenient combinator-based
syntax. We have already seen examples of builders in action, like
and switch
, which we used to define the opts
for our "hello" example.
Builders always take a modifier argument, which is essentially a composition of functions acting on the option, setting values for properties or adding features.
Builders work by building the option from scratch, and eventually
lifting it to a single-option parser, ready to be combined with
other parsers using normal Applicative
and Alternative
See the haddock documentation for Options.Applicative.Builder
for a full list of builders and modifiers.
There are four different kinds of options in optparse-applicative
regular options, flags, arguments, and commands. In the following,
we will go over each one of these and describe the builders that
can be used to create them.
Regular options
A regular option is an option which takes a single argument, parses it, and returns a value.
A regular option can have a default value, which is used as the result if the option is not found in the command line. An option without a default value is considered mandatory, and produces an error when not found.
Regular options can have long names, or short (one-character) names, which determine when the option matches and how the argument is extracted.
An option with a long name (say "output") is specified on the command line as
--output filename.txt
while a short name option (say "o") can be specified with
-o filename.txt
Options can have more than one name, usually one long and one short, although you are free to create options with an arbitrary combination of long and short names.
Regular options returning strings are the most common, and they can
be created using the strOption
builder. For example,
( long "output"
<> short 'o'
<> metavar "FILE"
<> value "out.txt"
<> help "Write output to FILE" )
creates a regular option with a string argument (which can be
referred to as FILE
in the help text and documentation), default
value "out.txt", a long name "output" and a short name "o".
A regular option
can return an object of any type, and takes a
reader parameter which specifies how the argument should be parsed.
A common reader is auto
, which requires a Read
instance for the
return type and uses it to parse its argument. For example:
lineCount :: Parser Int
lineCount = option auto
( long "lines"
<> short 'n'
<> metavar "K"
<> help "Output the last K lines" )
specifies a regular option with an Int
argument. We added an
explicit type annotation here, since without it the parser would
have been polymorphic in the output type. There's usually no need
to add type annotations, however, because the type will be normally
inferred from the context in which the parser is used.
Further information on readers is available below.
A flag is just like a regular option, but it doesn't take any arguments, it is either present in the command line or not.
A flag has a default value and an active value. If the flag is found on the command line, the active value is returned, otherwise the default value is used. For example:
data Verbosity = Normal | Verbose
flag Normal Verbose
( long "verbose"
<> short 'v'
<> help "Enable verbose mode" )
is a flag parser returning a Verbosity
Simple boolean flags can be specified using the switch
builder, like so:
( long "keep-tmp-files"
<> help "Retain all intermediate temporary files" )
There is also a flag'
builder, which has no default value. This
was demonstrated earlier for our --stdin
flag example, and is
usually used as one side of an alternative.
Another interesting use for the flag'
builder is to count the
number of instances on the command line, for example, verbosity
settings could be specified on a scale; the following parser will
count the number of instances of -v
on the command line.
length <$> many (flag' () (short 'v'))
Flags can be used together after a single hyphen, so -vvv
-v -v -v
will both yield 3 for the above parser.
An argument parser specifies a positional command line argument.
The argument
builder takes a reader parameter, and creates a
parser which will return the parsed value every time it is passed
a command line argument for which the reader succeeds. For example
argument str (metavar "FILE")
creates an argument accepting any string. To accept an arbitrary
number of arguments, combine the argument
builder with either the
or some
some (argument str (metavar "FILES..."))
Note that arguments starting with -
are considered options by
default, and will not be considered by an argument
However, parsers always accept a special argument: --
. When a
is found on the command line, all the following words are
considered by argument
parsers, regardless of whether they start
with -
or not.
Arguments use the same readers as regular options.
A command can be used to specify a sub-parser to be used when a certain string is encountered in the command line.
Commands are useful to implement command line programs with multiple
functions, each with its own set of options, and possibly some
global options that apply to all of them. Typical examples are
version control systems like git
, or build tools like cabal
A command can be created using the subparser
builder (or hsubparser
which is identical but for an additional --help
option on each
command), and commands can be added with the command
For example
( command "add" (info addOptions ( progDesc "Add a file to the repository" ))
<> command "commit" (info commitOptions ( progDesc "Record changes to the repository" ))
Each command takes a full ParserInfo
structure, which will be
used to extract a description for this command when generating a
help text.
Note that all the parsers appearing in a command need to have the same type. For this reason, it is often best to use a sum type which has the same structure as the command itself. For example, for the parser above, you would define a type like:
data Options = Options
{ optCommand :: Command
, ... }
data Command
= Add AddOptions
| Commit CommitOptions
Alternatively, you can directly return an IO
action from a parser,
and execute it using join
from Control.Monad
start :: String -> IO ()
stop :: IO ()
opts :: Parser (IO ())
opts = subparser
( command "start" (info (start <$> argument str idm) idm)
<> command "stop" (info (pure stop) idm) )
main :: IO ()
main = join $ execParser (info opts idm)
Modifiers are instances of the Semigroup
and Monoid
so they can be combined using the composition function mappend
(or simply (<>)
). Since different builders accept different sets
of modifiers, modifiers have a type parameter that specifies which
builders support it.
For example,
command :: String -> ParserInfo a -> Mod CommandFields a
can only be used with commands, as the CommandFields
type argument of Mod
will prevent it from being passed to builders
for other types of options.
Many modifiers are polymorphic in this type argument, which means that they can be used with any builder.
Custom parsing and error handling
Parser runners
Parsers are run with the execParser
family of functions — from
easiest to use to most flexible these are:
execParser :: ParserInfo a -> IO a
customExecParser :: ParserPrefs -> ParserInfo a -> IO a
execParserPure :: ParserPrefs -> ParserInfo a -> [String] -> ParserResult a
When using the IO
functions, retrieving command line arguments
and handling exit codes and failure will be done automatically.
When using execParserPure
, the functions
handleParseResult :: ParserResult a -> IO a
overFailure :: (ParserHelp -> ParserHelp) -> ParserResult a -> ParserResult a
can be used to correctly set exit codes and display the help message; and modify the help message in the event of a failure (adding additional information for example).
Option readers
Options and Arguments require a way to interpret the string passed
on the command line to the type desired. The str
and auto
readers are the most common way, but one can also create a custom
reader that doesn't use the Read
type class or return a String
and use it to parse the option. A custom reader is a value in the
We provide the eitherReader :: (String -> Either String a) -> ReadM a
convenience function to help create these values, where a Left
hold the error message for a parse failure.
data FluxCapacitor = ...
parseFluxCapacitor :: ReadM FluxCapacitor
parseFluxCapacitor = eitherReader $ \s -> ...
option parseFluxCapacitor ( long "flux-capacitor" )
One can also use ReadM
directly, using readerAsk
to obtain the
command line string, and readerAbort
or readerError
within the
monad to exit with an error message.
One nice property of eitherReader
is how well it composes with
attoparsec parsers with
import qualified Data.Attoparsec.Text as A
attoReadM :: A.Parser a -> ReadM a
attoReadM p = eitherReader (A.parseOnly p . T.pack)
s can be used to customise the look of the usage text and
control when it is displayed; turn off backtracking of subparsers;
and turn on disambiguation.
To use these modifications, provide them to the prefs
and pass the resulting preferences to one of the parser runners
that take an ParserPrefs
parameter, like customExecParser
It is possible to configure optparse-applicative to perform automatic
disambiguation of prefixes of long options. For example, given a
program foo
with options --filename
and --filler
, typing
$ foo --fil test.txt
fails, whereas typing
$ foo --file test.txt
succeeds, and correctly identifies "file"
as an unambiguous prefix
of the filename
Option disambiguation is off by default. To enable it, use the
modifier as described above.
Here is a minimal example:
import Options.Applicative
sample :: Parser ()
sample = () <$
switch (long "filename") <*
switch (long "filler")
main :: IO ()
main = customExecParser p opts
opts = info (helper <*> sample) idm
p = prefs disambiguate
Customising the help screen
optparse-applicative has a number of combinators to help customise the usage text, and determine when it should be displayed.
The progDesc
, header
, and footer
functions can be used to
specify a brief description or tagline for the program, and detailed
information surrounding the generated option and command descriptions.
Internally we actually use the ansi-wl-pprint
library, and one can use the headerDoc
combinator and friends if
additional customisation is required.
To display the usage text, the user may type --help
if the helper
combinator has been applied to the Parser
Authors can also use the preferences showHelpOnError
to show the help text on any parser failure or
when a command is not complete and at the beginning of the parse
of the main program or one of its subcommands respectively.
Even if the help text is not shown for an error, a specific error message will be, indicating what's missing, or what was unable to be parsed.
myParser :: Parser ()
myParser = ...
main :: IO ()
main = customExecParser p opts
opts = info (myParser <**> helper) idm
p = prefs showHelpOnEmpty
Command groups
One experimental feature which may be useful for programs with many subcommands is command group separation.
data Sample
= Hello [String]
| Goodbye
deriving (Eq, Show)
hello :: Parser Sample
hello = Hello <$> many (argument str (metavar "TARGET..."))
sample :: Parser Sample
sample = subparser
( command "hello" (info hello (progDesc "Print greeting"))
<> command "goodbye" (info (pure Goodbye) (progDesc "Say goodbye"))
<|> subparser
( command "bonjour" (info hello (progDesc "Print greeting"))
<> command "au-revoir" (info (pure Goodbye) (progDesc "Say goodbye"))
<> commandGroup "French commands:"
<> hidden
This will logically separate the usage text for the two subparsers
(these would normally appear together if the commandGroup
was not used). The hidden
modifier suppresses the metavariable
for the second subparser being show in the brief usage line, which
is desirable in some cases.
In this example we have essentially created synonyms for our parser, but one could use this to separate common commands from rare ones, or safe from dangerous.
The usage text for the preceding example is:
Usage: commands COMMAND
Available options:
-h,--help Show this help text
Available commands:
hello Print greeting
goodbye Say goodbye
French commands:
bonjour Print greeting
au-revoir Say goodbye
Bash, Zsh, and Fish Completions
has built-in support for the completion of
command line options and arguments in bash, zsh, and fish shells.
Any parser, when run using the execParser
family of functions,
is automatically extended with a few (hidden) options for the
completion system:
: this takes the full path of the program as argument, and prints a bash script, which, when sourced into a bash session, will install the necessary machinery to make bash completion work. For a quick test, you can run something like (for a program calledfoo
on thePATH
):$ source <(foo --bash-completion-script `which foo`)
Normally, the output of
should be shipped with the program and copied to the appropriate directory (usually/etc/bash_completion.d/
) during installation; -
: which is analogous for zsh; -
: which is analogous for fish shell; -
: internal options used by the completion script to obtain a list of possible completions for a given command line; -
: a flag to tell the completion system to emit descriptions along with possible completions. This is used to provide help along with the completion forzsh
Actions and completers
By default, options and commands are always completed. So, for example, if the
program foo
has an option with a long name output
, typing
$ foo --ou<TAB>
will complete --output
Arguments (either of regular options, or top-level) are not completed by default. To enable completion for arguments, use one of the following modifiers on a regular option or argument:
: specifies a list of possible completions to choose from;action
: specifies a completion "action". An action dynamically determines a list of possible completions. Common actions are "file" and "directory"; the full list of actions can be found in the bash documentation;completer
: a completer is a functionString -> IO [String]
, returning all possible completions for a given string. You can use this modifier to specify a custom completion for an argument.
Completion modifiers can be used multiple times: the resulting completions will call all of them and join the results.
When running a parser with execParser
, the parser is extended with
, which defines the above options.
When completion is triggered, the completion script calls the executable with
the special --bash-completion-index
and --bash-completion-word
The original parser is therefore run in completion mode, i.e. runParser
called on a different monad, which keeps track of the current state of the
parser, and exits when all arguments have been processed.
The completion monad returns, on failure, either the last state of the parser (if no option could be matched), or the completer associated to an option (if it failed while fetching the argument for that option).
From that we generate a list of possible completions, and print them to
standard output. They are then read by the completion script and put into the
variable (or an appropriate alternative for the other shells).
Arrow interface
It is also possible to use the Arrow syntax to combine basic parsers.
This can be particularly useful when the structure holding parse results is deeply nested, or when the order of fields differs from the order in which the parsers should be applied.
Using functions from the Options.Applicative.Arrows
module, one can write,
for example:
data Options = Options
{ optArgs :: [String]
, optVerbose :: Bool }
opts :: Parser Options
opts = runA $ proc () -> do
verbosity <- asA (option auto (short 'v' <> value 0)) -< ()
let verbose = verbosity > 0
args <- asA (many (argument str idm)) -< ()
returnA -< Options args verbose
where parsers are converted to arrows using asA
, and the resulting
composed arrow is converted back to a Parser
with runA
See tests/Examples/Cabal.hs
for a slightly more elaborate example
using the arrow syntax for defining parsers.
Note that the Arrow
interface is provided only for convenience. The
API based on Applicative
is just as expressive, although it might be
cumbersome to use in certain cases.
Applicative do
Some may find using optparse-applicative easier using do notation.
However, as Parser
is not an instance of Monad
, this can only
be done in recent versions of GHC using the ApplicativeDo extension.
For example, a parser specified in this manner might be
{-# LANGUAGE RecordWildCards #-}
{-# LANGUAGE ApplicativeDo #-}
data Options = Options
{ optArgs :: [String]
, optVerbose :: Bool }
opts :: Parser Options
opts = do
optVerbose <- switch (short 'v')
optArgs <- many (argument str idm)
pure Options {..}
Here we've also used the RecordWildCards extension to make the
parser specification cleaner. Compilation errors referring to Monad
instances not being found are likely because the Parser
can not be implemented entirely with Applicative
(Note however,
there were a few desugaring bugs regarding ApplicativeDo in GHC
8.0.1, function application with ($)
in particular may not work,
and the pure
value should instead be wrapped parenthetically).
Monadic parsing?
If a Monadic style were to be used, there would be no possible way to traverse the parser and generate a usage string, or for us to allow for options to be parsed in any order. Therefore it is intentionally unsupported to write a
in this manner with optparse-applicative, and theParser
type does not have an instance forMonad
. -
Overlapping flags and options / options with optional arguments?
This is not supported as it can lead to an ambiguous parse.
For example, if we supported and had an optional value option "–foo" and a flag "–bar", is "–foo –bar" the option with value "–bar", or the default value with the flag switched on? What if instead of a switch we had many positional string arguments, is the first string the option's value or the first positional?
It is suggested to instead use the
instance ofParser
and create a flag', an option, and a pure value for the default (with different names for the flag and option). -
Backtracking on
errors?Parser structures are predetermined at parse time. This means that if a
fails, the whole parse must also fail, we can't consider any alternatives, as there can be no guarantee that the remaining structure will fit. One occasionally confusing side effect of this is that two positional arguments for different constructors of a sum type can't be composed at the parser level; rather, this must be done at theReadM
level. For example:import Options.Applicative data S3orFile = S3 BucketKey | File FilePath s3Read, fileRead :: ReadM S3orFile s3Read = S3 <$> ... fileRead = File <$> ... correct :: Parser S3orFile correct = argument (s3Read <|> fileRead) idm incorrect :: Parser S3orFile incorrect = argument s3Read idm <|> argument fileRead idm
How it works
An applicative Parser
is essentially a heterogeneous list or tree
of Option
s, implemented with existential types.
All options are therefore known statically (i.e. before parsing, not necessarily before runtime), and can, for example, be traversed to generate a help text. Indeed, when displaying the usage text for a parser, we use an intermediate tree structure.
When we examine the user's input, each argument is examined to determine if it's an option or flag, or a positional argument. The parse tree is then searched for a matching term, and if it finds one, that leaf of the tree is replaced with the value itself. When all input has been processed, we see if we can generate the complete value, and if not issue an error.
See this blog post for a more detailed explanation based on a simplified implementation.
Version 0.14.3.0 (03 Oct 2018)
Updated dependency bounds.
Fix tab completion with Commands being unreachable.
Clean ups and Documentation.
Version 0.14.2.0 (26 Feb 2018)
- Updated dependency bounds.
Version 0.14.1.0 (23 Feb 2018)
Updated dependency bounds.
, andHasMetavar
type classes. -
Version 0.14.0.0 (09 Jun 2017)
and related builders to be polymorphic overIsString
. This allowsText
to be used naturally withstrOption
and friends.Note: This change may require additional type signatures in cases where the reader was necessary for type inference.
Export public API explicitly from
instead of re-exporting other modules.Note: Minor changes to exports were made in conjunction to this change.
no longer requires an an extra import, and some internally used functions fromOptions.Applicative.Common
are no longer exported from the main module. -
Add Zsh and Fish completions with rich descriptions for options and commands.
Use "–zsh-completion-script" and "fish-completion-script" to generate scripts for these shells.
Fix bash completions with quoted sections, tilde expansions and completions after "–".
Add suggestions to error message when a user mistypes a command or option.
builder, for styling option descriptions. -
Improve error message for options when a required argument is not supplied.
Fix #242 regarding flags with long options, where a flag given a long option could be interpreted incorrectly.
to be more like its namesakes in other libraries. When on, options will be accepted until an argument is passed, after which all options will be treated as positional arguments. -
builder, which will allow unknown options and flags to be passed to an argument builder. This is useful to mixed parsing environments, or wrappers to other commands. -
instances forCompleter
. -
Forwards compatibility with
proposal. -
Version 0.13.2.0 (9 Mar 2017)
Updated dependency bounds.
Version 0.13.1.0 (10 Feb 2017)
Updated dependency bounds.
Add required test files to cabal package.
Version 0.13.0.0 (15 Aug 2016)
Implement command groups, which allow subcommands to have their own usage description.
Implement showHelpOnEmpty, which is similar to showHelpOnError, but only fires when a command or subcommand is begun, and suppresses the "Missing:" error text.
Fix ghc 8.0 warnings
Fix ghc 7.10 warnings
Bump dependency bounds
Add maybeReader function for convenient ReadM creation
Move eitherReader to Readers section (for better discoverability)
Fix hsubparser metavar override
Remove ComplError, which was dead code.
Reimplement Missing error generation, which overly complicated evalParser.
Export Semigroup instances for types which are also Monoids. Removes mempty synonym
export, as it clashes with Semigroup exports. One may need to import Data.Monoid or Data.Semigroup when upgrading. -
Use a Cabal test suite for tests, simplify test dependencies.
Version 0.12.1.0 (18 Jan 2016)
Updated dependency bounds.
Improve subparser contexts to improve usage error texts
Fixed bugs
- # 164 - Invalid options and invalid arguments after parser has succeeded not displaying
- # 146 - multi-word filename completion is broken
Version 0.12.0.0 (17 Sep 2015)
Add "missing" error condition descriptions when required flags and arguments are not provided.
Allow multiple short flags to be concatenated together behind a single hyphen, e.g. "-xcf".
Updated dependency bounds on
. -
instances to some types for easier debugging. -
Add defaultPrefs, a default preferences value
Version 0.11.0.2 (17 Feb 2015)
- Updated dependency bounds.
Version 0.11.0.1 (5 Oct 2014)
- Updated documentation.
Version 0.11.0 (4 Oct 2014)
Added Alternative instances for
. -
monad is now aReaderT
for the argument being parsed. User defined readers do not need to handle their argument explicitly, but can always access it usingreaderAsk
. -
Argument builders now take a
parameter, just like options. -
Fixed bugs
- #106 - argument should perhaps use
- #106 - argument should perhaps use
Version 0.10.0 (1 Sep 2014)
Parser execution and help text generation are now more modular, and allow for greater customisation.
More consistent API for
builders: nowoption
takes a reader as argument, andnullOption
is deprecated in favour ofoption
. Thereader
modifier is gone. Quick migration guide:option
(without areader
modifier) =>option auto
(without areader
modifier) =>option disabled
(with areader r
modifier) =>option r
Added convenience builder
, equivalent toargument str
. -
Removed functions deprecated from at least version 0.8.0.
Switched test infrastructure to
. -
Fixed bugs
- #63 - Inconsistency between 'argument' and 'strOption' types
Version 0.9.1.1 (31 Jul 2014)
- Fixed bugs
- #97 - Version 0.9.1 fails test suite
Version 0.9.1 (30 Jul 2014)
Documentation tweaks.
Added low-level function to handle parse results (pull request #94).
now has aShow
instance (see issue #95). -
Fixed bugs
- #93 - Formatting problem for several sub-parsers
Version 0.9.0 (23 May 2014)
- The option returned by
is now visible by default.
Version 0.8.1 (5 May 2014)
- Fixed bugs
- #74 - Missing newline
Version 0.8.0.1 (19 Mar 2014)
- Fixed bugs
- #73 - Release 0.8.0 is broken
Version 0.8.0 (16 Mar 2014)
Help page formatting. Added
preference modifier, which can be used to specify the number of columns in the output terminal. -
builders. Usingmany
on a parser built usingargument
now returns a multiple argument parsers that behaves correctly with respect to--
. -
Fixed bugs
- #60 - runParser can't be called
- #64 - –help behaviour
Version 0.7.0.2 (18 Oct 2013)
- Fixed bugs
- #51 - Build fails with ghc 6.12.3 and ghc 7.0.4
Version 0.7.0.1 (18 Oct 2013)
- Minor docs fixes
Version 0.7.0 (17 Oct 2013)
Added builders for options that always fail. This makes it easier to create options that just print an error message or display some brief information and then exit (like
). -
functions (pull request #49). -
Fixed bugs
- #47 - Current master prints help text instead of error
- #48 - Can we have an eitherReader convenience function?
- #50 - In order parsing problems.
- #22 - Strict (no-intersperse) arguments
Version 0.6.0 (11 Oct 2013)
Arguments are now always parsed in order.
Fixed bugs
- #40 - Add context information to error messages
- #41 - Readme uses old reader API
- #38 - Internal types leaking into public API
- #44 - Can the build input restriction process == 1.1.* be relaxed?
- #28 - Help for subcommands
Version 0.5.2.1 (24 Dic 2012)
- Minor docs fixes.
Version 0.5.2 (23 Dic 2012)
- Fixed compatibility with GHC 7.2.
Version 0.5.1 (23 Dic 2012)
There is a new parser preference
, that controls whether how a failure in a subparser is propagated. By default, an unknown option in a subparser causes the option to be looked up in parent parsers. WhennoBacktrack
is used, this behavior is disabled. This is useful to implement subcommands that have no relations with their parent commands. -
Fixed bugs
- #35 - Artifacts of "hidden"
- #31 - Backtracking on commands
- #25 - Allow for using Maybe in options types to specify optional arguments
- #34 - No simple/obvious way to add a –version switch
- #29 - Document Mod
- #26 - Improve docs for the
Version 0.5.0 (22 Dic 2012)
Fewer GHC extensions required.
Improved error handling: unrecognized options now result in an error message.
By default, the full help text is not displayed on parse errors anymore. This behavior can be controlled with the
field ofParserPrefs
. -
operator is now deprecated. Modifiers can still be combined using(<>)
. -
Fixed bugs
- #37 - Use (<>) instead of (&) in documentation
Version 0.4.3 (09 Dic 2012)
- Updated dependency bounds.
Version 0.4.2 (26 Nov 2012)
- Fixed bugs
- #27 - Please include the test source files in the cabal sdist tarball
Version 0.4.1 (04 Sep 2012)
- Fixed bugs
- #19 - Regression
Version 0.4.0 (05 Aug 2012)
Brief help text for nested commands now shows the full command line.
Fixed inefficiency in the
parsers for long argument lists. -
Added automatic bash completion.
modifier forprefs
, which enabled automatic disambiguation of option abbreviations. With disambiguation on, a command line like:foo --out
will match an option called
, as long as its the only one starting with the stringout
. -
modifier. -
Fixed bugs
- #8 - Long options not disambiguated
- #10 - Shell completions
- #16 - Possible memory leak?
Version 0.3.2 (31 Jul 2012)
Fixed bug where both branches of an alternative could be matched.
Improved brief help text for alternatives.
Version 0.3.1 (30 Jul 2012)
Added new
modifiers, which will result in the default value (if present) to be displayed in the help text. -
Fixed bugs
- #12 - Optionally display default values in help
Version 0.3.0 (30 Jul 2012)
Option modifiers are now instances of
instead ofCategory
. -
Dropped dependencies on data-default and data-lens.
Fixed bugs
- #14 - "arguments" can no longer take a list as a default
Version 0.2.0 (23 Jul 2012)
Parser is now an instance of Alternative. This makes it possible to build certain complex parsers that were not definable before. See
for a simple example. -
modifier. You can now use themany
methods fromAlternative
, instead, to create parsers for options that can appear more than once. -
Added new
builder that returns a flag without a default value. Although flags without default values were not useful before, with the addition ofAlternative
combinators, they do have valid use cases. -
Added new
modifier for options. An internal option is completely invisible in the help text. -
Added a new
function, which takes an additionalParserPrefs
parameter. At the moment,ParserPrefs
can only be used to control how many-valued option metavars are displayed in the help text. Setting itsmultiSuffix
field to e.g....
will result in anarguments
parser description like[METAVAR]...
. -
Fixed bugs
- #6 - "arguments" swallows options
- #5 - Help formatting for "arguments" misleading
Version 0.1.1 (21 Jul 2012)
New arrow interface
Fixed bugs * #7 - "arguments" reads positional arguments in reverse
Version 0.1.0 (07 Jul 2012)
Improved error reporting internals
Removed template-haskell dependency
Fixed bugs: * #3 - No help for subparsers * #4 - Extra empty lines around command list
Version 0.0.1 (09 Jun 2012)
- Initial release.


text:
I have a String that is the (full) name of a contact.
Can I get the main number of that contact?
I know how to call a phone number using
Intent I=new Intent(Intent.ACTION_CALL,Uri.parse("tel:"+tel number));
But if the number that I get isn't a String how can I call it?
What packages I have to import?

subset: commoncrawl


text:
Please do not use this website if you do not agree with these terms and conditions.
- Please read these terms and conditions carefully before using the www.cfps.co.uk ("Website") which is operated by The Class 40 Preservation Society ("We"/"Us"). By accessing or using the Website you agree to be legally bound by these terms and conditions as they may be modified and posted from time to time.
- Without prejudice to the above, by using the Website, you accept and agree to these terms and conditions of use as they apply to your use of the Website.
- All registration data and information relating to you is subject to our Website Privacy Policy.
- In addition, the following also applies to all messages, emails, bulletin board postings, ideas, suggestions, concepts or other material submitted by you to Us ("Content"): you must own or have the right to submit Content for publication on the Website and all Content submitted by you must be legal, honest, decent and truthful and comply with all applicable laws, regulations, standards or codes of practice; and you must ensure that all Content submitted to Us does not infringe copyright, design, privacy, publicity, data protection, trade mark or any other rights of any third party, nor be obscene, abusive, threatening, libellous or defamatory of any person; and must ensure that the Content does not advertise or otherwise solicit for funds or is a solicitation for goods or services; We have the right to monitor Content and may edit, reject or remove Content if We believe it does not comply with the above and, in particular, We reserve the right to block incoming emails and other Content if We believe that their content is or may be inappropriate or otherwise does not comply with the above.
- You grant Us a non-exclusive, perpetual, irrevocable, royalty free, world-wide license to publish all Content which you submit to Us except any portion of the Content which is Personal Information (as defined in our Website Privacy Policy).
- You have sole responsibility for the Content which you submit to Us and you shall indemnify and shall keep Us fully and effectively indemnified on demand from and against all actions, claims, losses, liability, proceedings, damages, costs, expenses, loss of business, loss of profits, business interruption and other pecuniary or consequential loss (including legal costs and expenses) suffered or incurred by Us and arising directly or indirectly out of the publication of Content submitted by you to Us.
- You warrant and undertake that you will not use the Website for any purpose that is illegal or prohibited by these terms and conditions, including without limitation the posting or transmitting of any libellous, defamatory; inflammatory or obscene material. If you breach these terms and conditions then your permission to use this Website terminates immediately without the necessity of any notice being given to you. We retain the right to deny access to any person who fails to comply with these terms and conditions.
- We reserve the right to make changes or corrections, alter, suspend or discontinue any aspect of the Website, the content or services or products available through it, including your access to it. Unless explicitly stated to the contrary, any new features including new content, our provision of new products or services, or resources shall be subject to these terms and conditions.
- Please note that the Website may contain typographical errors or other inaccuracies.
You are solely responsible in all respects for all use of, and for protecting the confidentiality of, any email verification number and password that may be given to you or selected by you for use on the Website. You may not share these with or transfer them to any third parties. You must notify Us immediately of any unauthorised use of them or any other breach of security regarding the Website which comes to your attention.
- Unless otherwise specified all content and materials published on the Website are presented solely for your private, personal and non-commercial use.
- The Website is controlled and operated by Us from our offices in England. We make no representations that the materials on the Website are appropriate or available for use in other locations. Those who visit the Website from other locations do so on their own initiative and are responsible for compliance with all applicable laws. If use of this Website and/or viewing of it, or use of any material or content on the Website or services, or products offered through the Website are contrary to or infringe any applicable law in your jurisdiction(s), you are not authorised to view or use the Website and you must exit immediately.
- Where content published on the Website is supplied by third parties, you understand that We do not control or endorse their content in any way. All such content which is offered by third parties that are not affiliated with or otherwise connected with Us, is published in good faith but We do not in any circumstances accept responsibility for the accuracy or otherwise of such content published (on or off-line) and the use of such content.
- All content, materials and information on the Website are provided on an "as is" basis and you assume total responsibility and risk for your use of the Website and use of all information contained within it.
- To the fullest extent permissible by applicable law, We do not make any express or implied warranties, representations or endorsements whatsoever with regard to the Website or any information, service or product provided through the Website.
- To the fullest extent permitted by applicable law, We accept no liability for any loss or damage of any nature whatsoever and howsoever arising out of or in connection with the viewing, use or performance of the Website or its contents whether due to inaccuracy, error, omission or any other cause and whether on the part of The Class 40 Preservation Society or our servants, agents or any other person or entity.
- If We are liable to you for any reason (other than death or personal injury arising from our negligence), our liability will be limited to £100.
- Notwithstanding any other provision of these terms and conditions, The Class 40 Preservation Society does not attempt to exclude or limit its liability for death or personal injury resulting from its negligence in any way.
- You are responsible for ensuring that your computer system meets all relevant technical specifications necessary to use the Website and is compatible with the Website. You also understand that We cannot and do not guarantee or warrant that any material available for downloading from the Website will be free from infection, viruses and/or other code that has contaminating or destructive properties. You are responsible for taking sufficient precautions and virus checks (including anti-virus and other security checks) to satisfy your particular requirements for the accuracy of data input and output.
The contents of the Website are protected by intellectual property rights. The owner of these rights is The Class 40 Preservation Society, its affiliates, or other third party licensors. All product and company names and logos mentioned in the Website may be the trade marks, service marks or trading names of their respective owners, including Us. You may print individual pages of content on paper (but not photocopy them) only for the purposes of making use of our service but otherwise you may not modify, copy, reproduce, republish, upload, post, transmit or distribute, by any means or in any manner, any material or information on or downloaded from the Website including but not limited to text, graphics, video, messages, code and/or software without our prior written consent except in order to complete any survey or questionnaire.
We make no representations whatsoever about any other websites which you may access through the Website or which may link to the Website. When you access any other website you understand that it is independent from www.cfps.co.uk and that we have no control over the content or availability of that website. In addition, a link to any other site does not mean that We endorse or accept any responsibility for the content, or the use of, such a website and shall not be liable for any loss or damage caused or alleged to be caused by or in connection with use of or reliance on any content, goods or services available on or through any other web or resource. Any concerns regarding any external link should be directed to its respective site administrator or web master.
We will try to make the Website available but cannot guarantee that the Website will operate continuously or without interruptions or be error free. You must not attempt to interfere with the proper working of the Website and, in particular, you must not attempt to circumvent security, tamper with, hack into, or otherwise disrupt any computer system, server, Website, router or any other Internet connected device.
- We may assign or subcontract any or all of our rights and obligations under these terms and conditions.
- We may alter these terms and conditions from time to time and post the new version on the Website, following which all use of the Website will be governed by that version.
- If any provision or term of these terms and conditions shall become or be declared illegal, invalid or unenforceable for any reason whatsoever, such term or provision shall be divisible from them and shall be deemed to be deleted from them.
- Any failure or delay by Us enforcing an obligation or exercising a right, under this Agreement, does not amount to a waiver of that obligation or right or any other obligation or right.
- You acknowledge that they have not entered into these terms and conditions in reliance on any statement or representation, except in so far as the representation has been incorporated into these terms and conditions. You irrevocably and unconditionally waive any right you may have to claim damages and/or to rescind these terms and conditions by reason of any misrepresentation (other than a fraudulent misrepresentation) not contained in these terms and conditions.
- These terms and conditions and your use of the Website are governed by English law and you agree to submit to the non-exclusive jurisdiction of the English court.
All notices shall be given by email to Us at firstname.lastname@example.com, or to you at either the email or postal address you provide to Us. A notice will be deemed received 24 hours after an email is sent or 3 days after the date of posting.


text:
Happy Birthday Leo and Virgo! Stackable size 9 August birthstone rings in 14kt gold filled!
Crystal:3mm light peridot green cubic zirconia 3A-Quality
Bezel measurements:
- Circumference: 2.45mm
- Depth: 1.20mm
Band Measurements:
- OD: 20.9mm
- ID: 18.9mm
- Wire Thickness: 1.00mm, 18ga
Want to know more about Gold Filled vs other gold options? Read on or Watch Here
Gold Filled VS Gold Plate and Vermeil.
Gold Filled is an American metal manufacturing process and legal standard of quality. GF is two sheets of solid karat gold. Most popular being 14kt gold. These sheets are bonded over (or for wire, rolled in tube) a core of brass. For jewelry to be legally stamped with the 'GF' marking, its weight must be at least 1/20th gold. This explains the typical stamp you would expect to see on gold filled articles: "1/20 14K GF", which means that 5 percent of the piece is 14 karat gold. Due to the surface layer of gold-filled jewelry being about 100 times thicker than any plating, gold-filled pieces tend to last much longer, and are considered 'lifetime jewelry'
Gold plated jewellery is made using a thin layer of gold to surround base metals or sterling silver. The fine layer of gold is set using the method of chemical or electro-chemical plating. It is the cheapest of the three forms of gold jewellery (solid karat gold, gold filled and gold plated), and is the quickest to tarnish. When sterling silver is used as the interior metal, with at least 2 microns of gold plating, the item is primarily labeled as Gold Vermeil. Gold filled is not to be mistaken for gold plated over sterling silver – which is far less expensive than gold filled.
American standard gold filled does not have any sterling silver in it, and although it is more expensive, it lasts far longer than gold plated over base metal and over sterling because it has 100 times more gold than any possible plated process. How long gold filled or plating lasts depends largely on the chemical makeup of and the care with which the person wearing the jewellery takes – which varies widely.
View Abbreviation Guide
Tips, Tricks and How To's! Follow Stones and Findings on YouTube


text:
Don't worry, these things happen. Just enter the email address you used to register with Cambridge Dynamic Science for the Australian Curriculum and your username, and we'll send you a link to reset your password.
If you have changed your email address since you registered please ask the teacher who administrates your school's Cambridge Dynamic Science for the Australian Curriculum account to update your email and reset your password.If you have forgotten your username then ask your teacher administrator.
If you still can't log in then contact us.
Contact us to trial Cambridge Dynamic Science today
Trial option
*Teachers, see the full benefits of Cambridge Dynamic Science.
We can also organise a class trial for you and your students, plus we'll extend your free trial for a school term*!
If you are a user of Science for Children please email contact us with your access code to gain access.
To find out more please email us or call 1300 887 907** Available only to teachers within school.
Science in action using the latest teaching and learning technology.
Cambridge Dynamic Science harnesses the power of interactive digital technology to deliver a comprehensive online resource for teaching and learning in the science classroom.
Developed from the outset as an online resource, Cambridge Dynamic Science visually demonstrates science processes and concepts in a way that's just not possible in a printed resource. A range of interactive media caters for different learning styles and encourages students to question and engage in science in action.
Cambridge Dynamic Science also streamlines classroom management with online tasks, tests and reports, and full coverage of the Australian Curriculum.
Education Publishing Awards Australia 2015 Winner - Secondary Teaching Resource
Bett Award 2015 finalist - Secondary Digital Content
Cambridge Dynamic Science subscriptions provide access to all years 7-10 content for the Australian Curriculum.
The Teacher Edition for each course is available for purchase separately.
for a 1x 1 year activation
Use of the websites at www.hotmaths.com.au and www.cambridge.edu.au/seniormaths is subject to these terms and conditions of use. The Sites are operated by The Chancellor, Masters, and Scholars of the University of Cambridge, acting through its department Cambridge University Press ("Cambridge University Press") and HOTmaths Pty. Limited trading as Cambridge HOTmaths (ACN 094237233) ("HOTmaths"). Users who do not accept these Terms of Use are not authorised to use or continue using this website. We may amend these Terms of Use at any time and any revised version will be effective immediately, once it is displayed on this website. Except as permitted by the copyright law applicable to you or these Terms of Use, you may not reproduce or communicate any of the content on this website, including files downloadable from this website, without the written permission of the copyright owner.
In these Terms of Use:
There are three categories of Subscriber: Students, Teachers and Schools (on behalf of one or more students and/or teachers). In the case of a Student who is not at the time 18 years of age, the Application must be made by that student's school or by a parent, tutor, teacher, guardian or carer of that student. The Subscriber agrees with that the following terms and conditions will apply to the use of the Site by the User. The full texts of titles and ancillary materials (referred to below as 'content') available through Cambridge HOTmaths, Cambridge Senior Mathematics for the Australian Curriculum/VCE and Cambridge Essential Mathematics for the Australian Curriculum Second edition may only be accessed by Authorised Users.
An "Authorised User" is defined as:
An Authorised User will be provided with an access code that will need to be registered to an individual email address. Once registered, the Authorised User will have access to specific content on Cambridge HOTmaths. The Subscriber warrants that all information contained in the Application is true and acknowledges that it is their responsibility to advise HOTmaths within seven (7) days of that information changing in any way including, but not limited to, updating email addresses by means of the relevant link.
The Subscriber will take, and where applicable will ensure that the user takes, all reasonable steps to prevent the Subscriber/User's password becoming known to any other person. The Subscriber will advise Cambridge University Press or HOTmaths immediately if the Subscriber or the User becomes aware of any unauthorised use of the password.
Subject to clause 4 below, the Subscriber acknowledges that the Site Material is the property of Cambridge University Press and/or HOTmaths and is copyright © Cambridge University Press or Cambridge HOTmaths or published under exclusive license from the copyright holder by Cambridge University Press. Except as permitted by law or these Terms of Use, the Subscriber will not, and where applicable the Subscriber will procure that the User will not, allow any other person to use the Site or reproduce or otherwise transmit any of the Site Material in any way whatsoever without first obtaining the written permission of HOTmaths or Cambridge University Press. HOTmaths reserves its entitlements under Part VB and Section 183 of the Copyright Act. For information about Part VB (educational use) and Section 183 (government use) visit www.copyright.com.au and www.copyright.org.au.
A Teacher, or a User who is a teacher, may use Site Material for classroom instructional purposes such as projecting it onto a whiteboard, displaying it by means of other electronic media or printing it and distributing it to their students. Site Material also may be downloaded to digital media for use within a school by Subscribers but must be immediately removed upon expiry of the subscription unless renewal is pending. The use of the Site Materials by a Teacher, or by a User who is a teacher, for any purpose other than the instruction of the students in their class at a time when their right to use the Site Materials is current or in the process of renewal, will constitute a breach of these Terms of Use
The Subscriber will indemnify HOTmaths and/or Cambridge University Press for any loss or damage sustained by it as a result of any breach of these Terms of Use by the Subscriber, including the Subscriber's obligations in respect of the activities of the User. The Subscriber acknowledges that circumstances may exist where damages are not an appropriate remedy and Cambridge University Press/HOTmaths are entitled to obtain injunctive relief.
Cambridge University Press and/or HOTmaths may terminate this agreement immediately if at any time the Subscriber is in breach of the Subscriber's obligations (including as a result of some act or omission by the User). The Subscriber acknowledges that termination for any reason will not entitle the Subscriber to a refund of any payments made to Cambridge University Press or HOTmaths prior to the date of such termination.
Cambridge University Press or HOTmaths will refund Subscriber payments upon receipt of a written submission from the Subscriber that the site does not deliver that which it claims to provide. Refunds will not be given where the Subscriber is using systems other than those identified in the 'System requirements' or where the Subscriber is misusing the system.
Cambridge University Press and HOTmaths reserve the right to alter their product and pricing systems at any time.
You are entitled to download and store PDF Textbooks on your local machine. However they may not be transferred to another party as an electronic or print version. The downloaded PDF Textbook is expressly available for personal use only.
Schools are entitled to load the downloaded PDFs onto their school network for use only for the same number of users as they have purchased printed or digital texts.
Authorised Users may access, search and view content for personal use only. Print, copy and download permissions may vary depending on the sensitivity and rights available for the content.
Access to the PDF Textbook for individual use is included with Online Teacher Resources. The PDF Textbook may be downloaded onto one computer but may not be placed on the school network or transferred to another party. Other downloaded materials, except for the PDF Textbook, may be placed on your school network for use by other teachers at your school.
No other uses are permitted under these Terms of Use.
Authorised Users are not permitted to:
Cambridge University Press' /HOTmaths's explicit written permission must be obtained in order to:
Users acknowledge that all rights relating to Cambridge HOTmaths are the property of Cambridge University Press and HOTmaths and that these Terms of Use do not convey any right, title or interest therein except the right to use Cambridge HOTmaths in accordance with the terms and conditions of the Access Agreement accepted by you or your institution. Users undertake to ensure that the intellectual property rights of the copyright holder and the software owners and the moral rights of the authors of the content are not infringed. The content in the form published on Cambridge HOTmaths is copyright © Cambridge University Press or HOTmaths or published under exclusive license from the copyright holder by Cambridge University Press. Nothing in these Terms of Use shall in any way exclude, modify or affect any of these statutory rights under applicable copyright law. Reproduction and communication for educational purpose The Australian Copyright Act 1968 (the Act) allows a maximum of one chapter or 10% of the pages of this publication, whichever is the greater, to be reproduced and/or communicated by any educational institution for its educational purposes provided that the educational institution (or the body that administers it) has given a remuneration notice to Copyright Agency Limited (CAL) under the Act. For details of the CAL licence for educational institutions contact: Copyright Agency Limited Level 15, 233 Castlereagh Street Sydney NSW 20000 Telephone: (02) 9394 7600 Facsimile: (02) 9394 7601 Email: [email protected] www.copyright.org.au
Owing to the nature of the Internet we cannot guarantee that Cambridge HOTmaths or the websites to which it is linked will always be available to users. You should ensure that you have appropriate protection against viruses and other security arrangements in place whilst using the Internet.
Although every reasonable effort has been made to ensure that the information on Cambridge HOTmaths was accurate at the time of publication, it is subject to variation at any time without notice and we do not give any warranty that any such information will be accurate or complete at any particular time or at all.
Cambridge HOTmaths and any information or other material contained in it are made available strictly on the basis that you accept it on an 'as is' and 'as available' basis. Where you rely on any information or other material contained in it, you do so entirely at your own risk and you accept that all warranties, conditions and undertakings, express or implied, whether by common law, statute, trade usage, course of dealings or otherwise in respect of this website are excluded to the fullest extent permitted by law.
We exclude all liability whatever, to the fullest extent permitted by law, in respect of any loss or damage resulting or arising from any non-availability or use of Cambridge HOTmaths or of any other website linked to it, or from reliance on the contents of Cambridge HOTmaths or any material or content accessed through it.
The licence granted for your use of content on Cambridge HOTmaths is limited to the term, which is defined as:
"Year" is defined as running from registration of your Access Code until:
These Terms of Use shall remain in full force and effect for the duration of your access period or until such time as HOTmaths or Cambridge University Press may terminate its agreement for access to Cambridge HOTmaths.
In the event that an Authorised User commits a material breach of these Terms of Use, Cambridge University Press reserves the right at its sole discretion to either (i) withdraw access on a temporary basis, or (ii) terminate access on a permanent basis, to the content in the event of a deliberate and/or systematic breach of these Terms of Use by the Authorised User. Cambridge University Press further reserves the right to exercise all rights and remedies that may be available to it in law or equity.
If you supply personal details to Cambridge University Press and HOTmaths through Cambridge HOTmaths then you consent to our maintaining, recording, holding and using such personal data in accordance with our Privacy Policy.
Links from Cambridge HOTmaths are provided for information and convenience only and we have no control over and cannot therefore accept responsibility or liability for the content of any linked third party website. We do not endorse any linked website.
Users will be prompted to accept to our Terms of Use before they can use content on the Cambridge HOTmaths site. Cambridge University Press or HOTmaths may change, add or remove portions of these Terms of Use at any time and will again prompt users to accept these changes before continuing to use content on Cambridge HOTmaths.
Any notice given under this agreement must be in writing. Notices given to HOTmaths should be forwarded to [email protected] and Notices to be given to the Subscriber should be forwarded to the email address specified in the Application.
All enquiries and comments regarding the Terms of Use should be made to
HOTmaths Pty. Ltd.
PO BOX 300 Ramsgate, NSW, 2211
Tel. 1300 887 907 or 61 2 9990 6067
[email protected]
Cambridge University Press is a syndicate of the University of Cambridge and our principal place of business in Australia is 477 Williamstown Road, Port Melbourne Victoria 3207. In the event of any comments or questions concerning these Terms of Use, please contact your sales representative or 03 8671 1400 or [email protected]
HOTmaths and Cambridge University Press collect information that identifies you when you use Cambridge HOTmaths and products powered by Cambridge HOTmaths. This includes your first and last name, a username, a password, your email address, subscriber type, school and postcode.
Designated school administrators can also access this data to help them manage school subscriptions. They are required to treat this information as confidential.
Cambridge University Press and/or HOTmaths may change this policy from time to time. If it does so, you will be notified by a message in your message centre.
If you would like to lodge a complaint about our privacy policies or the storage and treatment of your personal information, please email us at contact us marked for the attention of the HOTmaths Privacy Officer. We will review your complaint and respond to you within 5 business days.
If you would like further information about this policy, or would like to request a printed version of this policy, please email us at contact us.
Minimum screen width 1024px
Cookies enabled


text:
Your cart is empty
Originating in 1663, Vitale Barberis Canonico has continued to produce some of the world's finest cloth.
The Perennial collection of four-season fabrics includes a wide range of classic plain, semi-plain, checked and striped patterns that are suitable for year-round wear.
A Super 110s yarn is used to create a 9oz/260g cloth that tailors beautifully with a soft hand, elegant drape and durable performance.


text:
Tower City Bed & Breakfast
A unique B&B, conveniently located along I-94 in North Dakota, exit 307. Our house, built in 1904, is very warm and inviting. It has been renovated and is decorated with beautiful antiques. Enjoy swinging on the old porch swing, listening to a wide variety of birds, go for a nice quiet walk or browse our local antique shop. We pride ourselves in North Dakota hospitality and serve our guests a wonderful home-cooked Breakfast.
Member of the North Dakota Bed & Breakfast Association.
Member of the North Dakota Bed & Breakfast Association.


text:
Below you'll see a list of artworks that Cool Artist created pertaining to Cities Subject matter. What is actually depicted in this artwork? What is the artist trying to express to the world... what is his or her message? And how are they conveying that message?
Cool Art India selling Painting, Drawing, Artifact, Handicraft, Sculpture and Statue from emerging artists. Hurry up !!!!
Cool Art India is the best place to buy & sell artwork online. Cool Art India is a form of display visual art in which include various kinds of mediums like erasers, markers, styluses, Ink, Pencil, Pastel, Charcoal, Marker, Ballpoint Pen, Acrylic, Watercolor, Paint, Color, Oil, Wax, Crayon, Spray Paint, Wood, Fabric, Airbrush, Plastic, Metal, Resin, Etching, Rubber, Clay, Glass, Plaster, Fiber, Stone, Fiberglass, metals.
If you or your child having Painting or Drawing? So do not keep it in the drawing book only, Upload art in Cool Art India and focus on the talent of the child by analyzing in future.
Cool Art India, founded in 2016, has been the new and most innovative online art platform in the country. We are strong believers in the transformational power of technology and have long been the pioneering art entity in the country; bringing together artists, collectors, dealers, galleries and resellers onto a single powerful online platform.
Very Simple to submit art information with email / mobile, We will upload art with your new / exiting artist account. Click Here to upload art.
Copyright © Cool Art India 2017-23