Right now I am injecting the random generator into the lisp environment, this relays on the interpreter to make sure it does not get trampled upon and special cases here and there, so I think its better to extract this out of the LispEnv into its own Env.

Also I'm wanting to add in 2 more environment items;

1. Execution logging for debugging any execution issues, it would be neat to get a full traceback of the previous execution.
2. Dice roll logging so that we can log what a roll was for and so forth.

http://getskeleton.com/#examples
http://getbootstrap.com/javascript/

Right now the build system is a bit of a mess.

Should be able to use: browserify to do stuff with npm and avoid bower.
should be able to migrate off grunt to say hakyll/shake to stay with haskell for build system.

Basically what I want to be able to do at this point is:

1. Require cabal for installing+building up all of the haskell dependency
2. Use npm to handle all of the js/node/etc deps (like libsass, etc...)
3. Use something like shake to build up the entire site.

One of the main gotchas is probably going to be static deps like "libsass/sassc", so would be good if we can find a haskell wrapper (http://hackage.haskell.org/package/hsass)

I have never implemented it so I have no idea if this would be easy or not.

https://github.com/slamdata/purescript-halogen/blob/master/docs/Halogen.md

I would like to look into using purescript-halogen but it lead to lots of breakage with 0.7 and 0.6

So let's wait for a while and let this ecosystem stabilize a little bit first.

This: http://new-pursuit.purescript.org/packages/purescript-thermite/0.8.0/docs/Thermite.Html#d:component

Seems to support being able to take a component and render its html and you feed it in a set of properties which lets you config the children component.

I think that's pretty much what i wanted.

Would be quite cool to have a website in which you can submit programs and get results back along with submitting stats analysis and so forth and getting back useful graphs and information.

http://hackage.haskell.org/package/hindent-3.7

Right now it is returning a Integer in the range of 1 and N as defined by randInt.

Now here's the idea. we want to also be able to compute the probability of a dice roll right. Replace the Integer returned by randInt with a type-class that implements the majority of what a Integer can do.

Then create a "probability" implementation of these typeclasses for probability, so that for ex (randProb 6) would emit a probability of (1/6, 1/6, 1/6 for 1-6) then each time its summed or what so ever, it will compute the new probability.

The main sticky point is how to deal with branching point, such as IF, may just want to make sure the program execute all possible branches upto some reasonable depth limits and terminate.

Also another issue is how to deal with for example raw integer, IE +6. One solution could be to have these shift the probability around from say 1-6 to 7-12 for ex.

I am not sure how scalable this solution is, the main issue would be having to head down each branch and determine their probability.... and the issue of termination. But I suspect we can just have it terminate past a certain number of iteration down a branch or have it be bounded by a timeout.

The other approach would be to do a monte-carlo approach and just repeat it thousands of time to build up the probability of the result.

Right now its kinda of a pain to debug because error reporting is quite bad.

Invest some solid time into improving this, such as annotating the AST with various metadata such as line and col number, what expression, any type issues, so forth..

Right now there's not much limits other than the fact that the entire interpreter is "pure" plus the addition of ST for the LispEnv.

Need at least the following:

1. Reasonable upper bound on dice rolls
2. Reasonable upper bound on number of rolls
3. Reasonable upper bound on memory consumption
4. Reasonable upper bound on execution time (probably via kernel limits and forking)

PCGEN dice roller rules:

PCGEN RollInfo Dice:

ndm([/\|mM]a)*([+-]b){0,1}([tT]c){0,2}

    n - dices
    m - sides
    /a - keep top a dices
    \a - keep bottom a dices
    ma - Reroll if below a.
    Ma - Reroll if above a.
    |a,b,c - keep a,b,c dice (1-indexed sorted ascending)
    +b - Add b
    -b - Minus b
    tc - Min of c total.
    Tc - Max of c total.

Examples:
    d6
        One roll of a d6 dice

    2d6
        Two roll of a d6 dice summed

    4d6/3
        Four roll of a d6, keep highest 3

    4d6\3
        Four roll of a d6, keep lowest 3

    5d6|1,4
        Five roll of d6, keep roll 1, 4 (1-indexed sorted ascending)

    2d6m2
        Two roll of a d6, min of 2

    2d6M2
        Two roll of a d6, max of 2

    d6+3
        One roll of a d6 dice + 3

    10d6t10
        10 roll of d6 dice, with a min of 10 total.

    10d6T20
        10 roll of d6 with a max of 20 total.


PCGEN Data Dice:
min(v1,v2)
max(v1,v2)
pow(base, exponent)
roll(times, sides)
roll(times, sides, [keep])
roll(times, [sides])
roll(times, [sides], [keep])
roll(times, sides, numToKeep, reroll, modifier)

NOTES:
    [keep] - This is an array of 0-indexed dices to keep in the result. The rolls are generated
        and stored in an array, then they are sorted in ascending order (lowest to highest), then the
        values in [keep] are used as index to pull out the dice rolls to keep.

    [sides] - (doc has it as shape), This is an array of dice sides such as for d6 - [1, 2, 3, 4, 5, 6] in which
        the side is randomly selected out of this array and used as a dice-roll.

    d% - 1d100

    dF - fudge dice (1-2 -, 3-4 0, 5-6 +)

    numToKeep - (highest x dices to keep)

    reroll - roll(sides - reroll) + reroll; - Badly done (if not greater than x, reroll)

    modifier - the sum to add to the dice (ie 3d6 + modifier)


Examples:
    roll("3d6")
        Simulates rolling 3 six-sided dice.

    roll("1d20+10")
        Simulates rolling a twenty-sided die and adds 10.

    roll("min(4,7)")
        Returns a value of "4".

    roll("max(4,7)")
        Returns a value of "7".

    roll("pow(10,2)")
        Returns a value of "100".

    roll("roll(3,6)")
        Simulates rolling 3 six-sided dice.

    roll("roll(4,6,[2,3,4])")
        Simulates rolling 4 six-sided dice and keeps the 3 highest rolls.

    roll("roll(1,[3,5,7,9])")
        Similates rolling one 3, 5, 7 or 9 sided die, randomly selected.

    roll("roll(3,[2,3,4,5,6],[2,3])")
        Simulates rolling three 2, 3, 4, 5, or 6 sided dice, randomly selected and keeps the highest 2.

    roll("roll(4, 6, top(3), reroll(1))")
        Simulates rolling four 6 sided dices and picking top 3 and rerolling if not at least 1.

Example rolls:

roll(")
roll("10+d10")
roll("1d10")
roll("1d20+10")
roll("max(4,7)")
roll("min(4,7)")
roll("pow(10,2)")
roll("roll(1,[3,5,7,9])")
roll("roll(3,6)")
roll("roll(3,[2,3,4,5,6],[2,3])")
roll("roll(4,6,[2,3,4])")
roll("x")
roll()
roll(1,20,|VAR|,'text\n')
roll(4,5,[2,3,4])
roll(4,6,reroll(1))
roll(4,6,top(3))
roll(4,6,top(3),reroll(1))

Citation:

• http://jira.pcgen.org/browse/DOCS-244
• http://pcgen.org/autobuilds/pcgen-docs/listfilepages/globalfilestagpages/globalfilesformulas.html

Look into starting to provide a secondary api for performing stats analysis on dice rolls for the provided dice program.

Would be pretty cool to be able to get back data in tables, because we can always use something like d3 on the client to graph the result.

This is so that we can validate/test the stdlib code quality before generating it to the filesystem. Or alternatively just compile it directly to AST and store it in the binary.

There has been absolutely no performance tuning, it is performing ok for probably moderate load, but past that...

It would be awesome to start to build up a test suite of benchmarks for various stage of the interpreter, web service and so on to start nailing down performance issues.

For example - wrk was used to slam the http endpoint and it performed ok but it had high amount of connection dropped under heavy load which seems sub-optimal.

Look into just deprecating hakyll for static content generation and just do some sort of streaming of the docs and build it in react perhaps, also see if we can't just embed the html/have the html stuff be ingested into the webserver upon build.

Would be pretty neat to also provide a NSQ api endpoint for apps to send in dice requests so if they already have a NSQ bindings they can just send one instead of also having to set up a http client.

Should provide a simple way to parse alternative dice syntax such as roll20.net, pcgen and so forth.

Basically it would take an input string, parse then emit an equivalent instruction but in the scheme AST/Raw Scheme and feed it into the primary dice engine so that we can have a clean scheme core that is extendable with other syntax form.

I would suspect one such example uri routing could be like:

/roll/{subparser}/etc....

Then the person who is interacting with the http api can probably just issue an common call to various sub-parser such as pcgen, roll20, troll, etc... and put the dice expression into the src="" field and have it parsed and transformed into an scheme ast for execution.

Would be good to provide more flexible options such as requesting a log of rolls.

1. log of rolls
2. log of execution
3. debugging facilities such as amount of memory consumed/time consumed and limits.

See if its possible to do some sort of ingest of static asset upon build and upon deploy have the binary have a way to "dump" a default version of the asset locally for local modification for stuff like say the scheme stdlib, the html, couple other assets for quick test/modify cycle, but mostly in deploy mode.

Might be better to just do it as production vs test mode, where test mode just ingest local files, and production makes everything build first (ie shake) then ingest the file for deploy.

Need to implement a test-suite to test the scheme interpreter and the stdlib.

Should implement a test suite for testing and ensuring that the random generator is of the highest possible quality.

Right now most of the limits and various other configuration options such as port number are all hardcoded into the source.

Externalize them.

We have basic EKG instrument of GHC/runtime but we don't have any for the performance of the interpreter, the system, requests/sec and so on. It would be extremely awesome to add these kind of stats to EKG so that we can keep a eye on the service's performance.

Basically what good is a dice generator if it can't do all sorts of odd rolls.

Look up in various source books and finding what types of rolls are out there and implement support for it.
1.Roll a m sided dice (d20)
2. Roll multiple (n) dices of (m) sides (2d6)
3. add n
4. subtract n
5. best n
6. worst n
7. exploding dice (ie if you roll max dice, you roll additional dice till you stop rolling max dices)
8. Additive vs success roll (Ie 2d6 = d6 + d6), and success where (success = count_true([x > 3 for x in [d6, d6, d6]) > 2)

There is a shit-ton of warning generated such as incomplete pattern matching, and various uses of unsafe-head here and there. It would be terrific to go back through this and clean up all of these warnings.

Right now there is absolutely no logging outside of stdout messages that are generated from yesod-routes/warp itself. We should absolutely extend it to include all other useful information such as program submitted, amount of time taken to execute programs and so on.

Useful to start working on some form of GUI for inputting expressions and so forth into a web-page and playing around with the results.

https://babeljs.io/

I've found some good source doc for code gen via LLVM and having a form of primitive JIT. It would be pretty cool to look into code generation so that we can execute custom programs even faster.

Probably can set up a form of caching in that if a incoming program has been seen previously (say md5sum or something) re-execute the cached compiled code so that there's only an initial cost upon the first request.

Right now I am baking in hsass, shake, and a process control library for dealing with running elm-reactor + building the entire system in a self-contained manner.

Would be good to make these bits optional (via cabal dep + build flag) or as an command line argument for ex. Then that way we can have a "dev" version and a "deployment" version which builds the entire thing and ingest all assets into the binary.

Basically right now we are hard-coding some primtives and a form of standard library in a file that we load into the interpreter.

It would be pretty awesome to eventually look into a form of database in which we can store programs in the database and then call up these programs to composite larger program. This way that people can develop custom or weird dice programs that other people can then invoke.

Almost like moving (define func) into a database in which each row is a function or some such....

http://schlocktroops.com/2015/04/21/sums-combinations-permutations-and-d6%C2%B3/

Right now the parsing stage has to be ran inside the ST monad because of the fact that it parses into a stateful AST.

The parsing step and various steps does not need to be LispEnv stateful.

Look into breaking up the AST into a few phases or looking into some form of tagging or alternative AST so that we can tag various pieces of useful information to the AST.

I can envision wanting to tag the following items:

1. Line/source code (for traceback)
2. LispEnv state for closures
3. Annotation for various interpreter stages.

I keep on finding myself referring to lambda somewhat often for various stage of programming. It seems like I need to get more familiar with scheme, or the usecase here is more useful with it having a lazy evaluation model.

If I'm going to have a scheme interpreter it should make sense for me to implement all of the primitives required to support the subset of scheme that I am using up to the R5RS standards for these parts.