2
\$\begingroup\$

Refer to this challenge in Sandbox.

My major language is Haskell. In Haskell, a parser (type ReadS) is a function that inputs a String and outputs a list of a tuple of the parsed element and the remaining string (ReadS a = String -> [(a,String)]). When the list is empty, there is no parse. When the list has two or more elements, the parse is ambiguous.

There are also types ReadP and ReadPrec, which are equivalent to ReadS and Int -> ReadS respectively, but monadic. They are made invokable by readP_to_S and readPrec_to_S, respectively.

There is also readEither, whose type is String -> Either String a. It outputs an error message when there is no parse or the parse is ambiguous. readMaybe :: String -> Maybe a does the same thing, but outputs Nothing instead. read :: String -> a does the same thing, but throws an error instead.

All these must be considered parsers, right? So a challenge asking for a parser should have the following format:

Objective

Parse a string to (some type).

Valid inputs

A valid input consists of (some format).

Invalid inputs

When the parser encounters (some format), the parser must be in an errornous state. This includes:

  • Monadic failing

  • Returning an errornous value

  • Throwing an error

Rules

  1. When the input is neither valid nor invalid, it falls in don't care situation.

  2. (blah blah blah)

Is this elaborate enough?

| |
\$\endgroup\$
6
\$\begingroup\$

Do not assume any feature about a language, just write down the requirements in the most general words possible

Always remember, many languages don't have functions, many languages don't have data types at all, and many languages don't have any mechanism to signal an error.

A parser can be written as a function (parse a string argument and return a desired object) or a full program (take a string from stdin and print out some representation of the object), just like other code golf tasks. You already described the task that way, no problem.

For the "error" part, you already found out that there are multiple valid ways to indicate error. What you should do is to just say "indicate error in any sensible way for your language of choice". This automatically includes a failure monad (among others) in Haskell, throw/raise in JS/Python, and printing a consistent error value for minimal esolangs.

| |
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .