Suppose we have two uninteresting rules:

[t1, t2] = map (`makeRule` Just) ["t1", "t2"]

If I set up the strategy

t1 .*. fail

and follow it from the start, allfirsts offers me the single first t1, then nothing, which is completely in line with my expectations. The same happens with the strategy

t1 !~> fail

which is again unsurprising to me. I can now add a choice:

choice [t1 !~> fail, toStrategy t2]

allfirsts offers me both t1 and t2, and choosing either leads to a state with no more firsts.

Both components of this choice are atomic, so I feel I should be able to use interleaving instead of choice and get the same result:

interleave [t1 !~> fail, toStrategy t2]

The result differs: allfirsts only offers me t2. The choice including t1 has vanished -- microsteps does not show it either.

Finally, I can replace the atomic prefix with a simple sequence:

interleave [t1 .*. fail, toStrategy t2]

This gives me the expected result: I can choose t1 or t2, and if I choose t1, I am forced to then choose t2, and after that there are no more firsts. Unfortunately, I really need the transition to fail to be atomic.

It is very likely the cause of this issue is somewhere in concurrent or split2 in Ideas.Common.Strategy.Derived, but that's not very helpful, as those are the most complex functions in that module.

The succeed and fail primitives seem to be insufficient for describing certain strategies that end after a certain rule or strategy.
The introduction of an end primitive would solve this problem. In the below example the need of such a primitive is shown and motivated.

(a .*. ((b .*. end) .|. c)) .*. d

When we choose "a", we expect "b" or "c" to follow and when we choose "c" after "a", we expect "d", but when we choose "b", we expect succeed without sequencing "d" after, because of end.

However currently we cannot define end in terms of succeed and fail, because succeed .*. d = d and fail .*. d = fail, which is also not what we want.

Also defining end as a high-level combinator will lead to a split in the strategy to the point where it is no longer left-factorised. For the above example we would get:

(a .*. b .*. end) .|. (a .*. c .*. d)

This is less efficient and can be avoided by introducing end as a primitive.

Userid is in the request, but not in the userid column

Add support for including or excluding encoders (e.g., JSON, XML, HTML) in
a domain reasoner, or to adapt existing encoders. Specific features/extensions
can then be programmed outside the framework.

The LinkManager contains hardcoded references to http://ideas.cs.uu.nl/, which are used for CSS and images in HTML mode. This breaks online debugging for Communicate, because we use HTTPS and that makes browsers refuse to load CSS and images over HTTP.

One solution would be the ability to configure the base URL used for media.

See inductive tutor

Add generic support for defining IsTerm instances.

The JSON specification allows escapes of the form \uxxxx, which is \u followed by four hexadecimal digits. Considering that the newline character is Unicode code point U+000A, I expect parseJSON "\"\\u000A\"" to yield Right "\n" (note that this is the Showed representation), but in fact it yields a Left containing

(line 1, column 3):
unexpected "u"
expecting space, "&" or escape code

Furthermore, it is also allowed to use surrogate pairs to encode a code point past U+FFFF. A fully conforming parseJSON would parse "\"\\uD835\\uDD4C\"" into "𝕌", a string containing the code point U+1D54C.

This incompatibility is caused by the use of Parsec's stringLiteral parser, which follows Haskell's syntax rules for string literals. This parser also supports a large number of escapes that are not valid in JSON, such as \a and \&.

This issue is not critical for Communicate (certainly not important enough to delay ideas-1.5), but we expect to start working with JSON generated by many different encoders, some of which are likely to use this feature.

Field maxTime from Options (Ideas.Encoding.Options) is overwritten by process in Ideas.Main.Default.

The apply feedback service should have a proper way for reporting buggy rules (in particular for logax).
Information about userid, sessionid, taskid, etc. should be preserved in the loggings.

Hi! I've found some typos or artifacts on the site version of the Tutorial.

1. The first argument is the rule’s identifier
2. The MakeTrans type class that is part of makeRule’s type
3. Step 2: adding traverals
4. calculating with fractions (e.g. 5/7
5. mixed fractions (e.g. 17/14

Make it possible to re-run the requests that are stored in a (logging)
database, e.g. for analyzing differences w.r.t. a previous run.

Some time ago, the Communicate team discovered an annoying asymmetry between how input and output is encoded by the cgi library. Specifically, input is decoded from UTF-8 to a list of Unicode code units (i.e. a "real" String), while output is not touched. This means that it is possible for a client using Ideas to receive a character, send it back unchanged, and get a decoding exception (if the character is not also encoded as an XML entity or JSON escape sequence).

It turns out that this behaviour is not intentional, but caused by an unannounced change in the behaviour of network. See cheecheeo/haskell-cgi#23 for the full discussion. The cgi maintainer has released a new version (3001.3.0.0) that corrects this behaviour (by touching neither the input nor the output).

cgi was imported into the Ideas tree in commit a25385d in order to fix a dependency problem involving mtl. This problem was solved in cheecheeo/haskell-cgi@46a6cb8. Whether it's a good idea to remove cgi from the tree and use the latest version depends on whether support for GHC 7.8 and older will be dropped:

• If Ideas will only support GHC 7.10 and up from now on, the cleanest solution is to remove cgi from the tree and add a dependency on cgi >= 3001.3.0.0.
• If Ideas still wants to support GHC 7.8 and older, doing the above is possible, but will make life harder for Windows users. There's no Haskell Platform that contains both GHC 7.8 and time-1.5, a version cgi-3001.3.0.0 depends on, and time is hard to build on Windows. In this case, I recommend applying cheecheeo/haskell-cgi@42f4ca7 to the in-tree cgi.

Note that in the current state of the master branch, Ideas does not support GHC 7.8 or older, because refers to Applicative without importing Control.Applicative. I don't know if this is intentional or not.

Given one or more requests (input-output pairs), allow customized reports
that summarize the results (or specific aspects).

Ideas.Text.HTML.W3CSS contains very many Haddock comments of the following kind:

container :: BuildXML a => a -> a
container = XML.tag "div" . w3class "w3-container" -- ^ HTML container with 16px left and right padding  

It turns out that Haddock doesn't consider this to be valid Haddock syntax:

src\Ideas\Text\HTML\W3CSS.hs:57:52:
'   parse error on input `-- ^ HTML container with 16px left and right padding

Indeed, the Haddock documentation does not mention placing a -- ^ comment after a binding, only after a declaration.

This breaks Haddock, which will not only prevent documentation generation on Hackage: it is also (one of) the cause(s) of the Slack-based Travis build failures. When I remove these invalid Haddock comments, the lts-6 build succeeds, at least locally.

Warning: only the following two comment styles seem to be processed properly by Haddock:

-- | HTML container with 16px left and right padding
container :: BuildXML a => a -> a
container = XML.tag "div" . w3class "w3-container"

container :: BuildXML a => a -> a
-- ^ HTML container with 16px left and right padding  
container = XML.tag "div" . w3class "w3-container"

Although the following same-line style is silently accepted, it does not actually attach Haddock documentation to the identifier:

container :: BuildXML a => a -> a -- ^ HTML container with 16px left and right padding  
container = XML.tag "div" . w3class "w3-container"

The atomic prefix combinator disallows interleaving inbetween a rule and a strategy that it is applied to by putting atomicOpen before and atomicClose after.

However when there is a choice between sequencing a rule to a strategy with atomic prefix or the normal sequencing combinator, the strategy needs to be split.

(r !~> s1) .|. (r .*. s2)

This is very inefficient for larger strategies where the use of atomic prefix is abundant. The amount of possible paths that are formed by splitting this way, is a product of the amount of choices and atomic prefix combinators. For larger strategies using atomic prefix, performance problems are encountered.

Possible solutions:

• Optimize current functionality of atomic prefix and the split operation
• Check for the atomic symbol when interleaving inside the concurrent function
• Low-level

Currently, escaped characters are unescaped after parsing XML. This leads to issues: notably, "<x>y&lt;</x>" will be parsed as <x>y<</x>, which, when printed again, leads to invalid XML (see Ideas.Text.XML.parseXML).

Introduce a datatype for 'examples' (in an Exercise) with support for single terms, randomly
generated terms (with QuickCheck's Gen), test cases, subsets of examples, etc.