Module: moona.http.response_headers
Handler: auto_conent_length: HTTPHandler

Sets current response body length to "Content-Length" response header as bytes (number is converted to bytes representation.

• Repository improvements

  • Add license (MIT)
  • Add used git flow information to CONTRIBUTING.md
  • Add explanation for Makefile scripts in README.md or CONTRIBUTING.md
  • Fix Develop section in README.md (how to via Makefile)
  • Ignore .vscode folder
  • Add issue templates (Feature; Bug)
  • Add pull request template
  • Provide extensive explanation of core concepts in README.md

• Improve pyproject.toml for pipy

  • Add readme link to pyproject.toml
  • Fix license in pyproject.toml
  • Add homepage to pyproject.toml
  • Add repository to pyproject.toml
  • Add documentation for pyproject.toml
  • Add keywords to pyproject.toml
  • Add classifiers to pyproject.toml (for pypi)

• Improve documentation at github.io

  • Migrate to Starlette/FastAPI documentation theme. See ref.

• Examples

  • Provide new "Hello, World!" example application
  • Provide "Calculator-Calca" example application (Fibonacci and Factorial calculation)
  • Provide "Lifespan" example application
  • Provide Maybe monad examples
  • Provide Future monad examples
  • Provide Result monad examples

• Docstrings

  • Add more imports to mona/__init__.py
  • mona.asgi.create: Explain "lifespan" and "http" handling in ASGI root
  • mona.core.BaseContext: Fix LifespanContext to implemented
  • mona.core.LifespanContext.copy: Remove complete field from coping as there is no one
  • mona.core.HTTPContext: Fix docstring (it is for "http" scope and not replication of it)
  • mona.core.ContextError: Fix typing and relation to HTTPContext
  • mona.core.HTTPContext.create: Fix dot in Return section
  • mona.monads.core: Fix dot in Return section
  • mona.mondas.future.Future.__await__: Remove docstring as it is not required for dunder methods (?)
  • mona.core: group classes based on scope type
  • mona.monads.future.Future.identity: add example
  • Fix all docstrings 😄

• State module
  • Add module-level docstring with explanation on State monad itself
  • Add detailed explanation of State class
  • Add detailed explanation of Right state class
  • Add detailed explanation of Wrong state class
  • Add detailed explanation of Error state class
  • Add detailed explanation of Final state class
  • Add better explanation for unpacks with example (and type hints)
  • Add better explanation for guards (accepts/rejects right/wrong/error/final) with examples (and type hints)
  • Add better explanation with examples for switchers (and type hints)
  • Find way to provide documentation for Type Aliases (or make them dedicated classes in hierarchy)
  • Fix return type hint for switch_to_final (now: Right[T]; should be: Final[T]
  • Add return value type hints for _wrapper functions inside guards (now: no hint)

Module: moona.http.request_route
Handler: bind_query: (**kwargs -> HTTPHandler) -> HTTPHandler

Works like bind_json/bind_text and other request body handlers. Request query is interpreted as keyword arguments.

• Maybe state
• Wrapper around Some value (from Maybe)
• Mock value for Nothing from (Maybe based on _Nothing singleton type)
• Recovery function recover: V -> (Maybe[T] -> Maybe[T] | Maybe[V])
• Choose function choose: (Maybe[T] -> Maybe[V]) list -> Maybe[V]

• Reimplement http.bind_query: BaseModel, (BaseModel -> HTTPHandler) -> HTTPHandler

Describe the bug
A clear and concise description of what the bug is.

Describe expected behavior
How app should work

Describe possible solution
Optional explanation of what in code should be fixed

⛔ #43

Feature description

Maybe monad requires also working with async functions. For that we need to provide separated, but compatible FutureMaybe monad.

Tasks

• >> operator for async Some binding
• > operator for sync Some binding
• << operator for async Nothing binding
• < operator for sync Nothing binding
• >> operator of Maybe returns FutureMaybe
• << operator of Maybe returns FutureMaybe
• > operator of Maybe for sync Some binding
• < operator of Maybe for sync Nothing binding

• http.receive caches raw request body in HTTPContext

Links

• FastAPI CORS documentation
• Mozilla CORS documentation

Module: moona.http.response_headers
Handler: content_length: int -> HTTPHandler

Sets response header "Content-Length" to passed value.

• on_lifespan handler (accepts only Context with type_ == "lifespan" (like on_http)

To be continued... (need to study ASGI Lifespan Protocol)

When query string is first converted to dict this value must be cached for possible further usage

This handler should work exactly like req.set_body_from_bytes, but take str and than assign it to bytes body.

Module: moona.http.request_route
Handler: bind_params: (*args -> HTTPHandler) -> HTTPHandler

Request params are bound as *args of handler generating function.

States are nice, but they make code too complex I believe and make some mismatch as currently State instead of its classical implementation of (state, value) pair is some mix of Safe and Result monads.

In this way it seems much more profitable to use Maybe monad (#4) in combination with Future monad just to keep everything nice and clean.

OLD

Based on Giraffe project I see that it makes sense to get rid of complex State management in favor of Middleware-like continuation style.

There would be 3 core function types:

import typing

# function that accepts context changes something about it and returns context
ContextFunc = typing.Callable[[Context], Future[Maybe[Context]]]  

# this is a handler. Handler = application (must be composable, curried)
ContextHandler = typing.Callable[[ContextFunc, Context], Future[Maybe[Context]]]

• Why handler returns Future[Maybe[Context]]?
  Each handler is a sync function, but it might have some async operations inside. Async operations should be performed using Future. Maybe is needed for railroad-oriented basis - when we have Some[Context] than everything is OK and we go next, but when Context is actually Nothing than the way we went is wrong and we need to pick some other handling option.

Tasks

• Get rid of State monad usage (do not delete, but do not use) Think how to restructure it;
• Provide base types ContextFunc and ContextHandler (possibly shortcut for Future[Maybe[Context]];
• Provide ContextHandler composition via << (__lshift__) operator - class wrapper + decorator;
• Improve Future's >> (bind) for Future returning function (might need complete redesign);
• Rework existing handlers to ContextFunc and ContextHandler;
• Rework existing tests;

Feature description

Functional languages provide so called pipe operator. In F# for example it is |>. Pipe operator does very simple thing it moves argument on the left to be on the right from the right argument of pipe:

let (|>) x y = y x

This allows writing code in pipelines like:

obj 
|> do_smth_1 
|> do_smth_2 
|> do_smth_3

Override of >> and << operators had been initially inspired by this. Currently it is implemented only for Future monad, but why not to provide functionality for sync values too?

Tasks

• Pipe container that wraps some sync value inside
• >> operator for executing async functions (Pipe converted to Future)
• > operator for executing sync functions (Pipe remains Pipe)
• unpack static method for unwrapping value from Pipe
• Aliases for > and >> - then and then_future

Target syntax example:

result: Future = (
   Pipe(path) 
   > read_file 
   > to_url 
   >> fetch_user
)

• pipe then f: x->y --> pipe
• pipe then_future async f: x->y --> future
• pipe then_result f: x->result y --> result
• pipe then_maybe f: x->maybe y --> maybe
• pipe then_result_future async f: x->result y --> future_result
• pipe then_maybe_future async f: x->maybe y --> future_maybe
• future then f: x->y --> future
• future then_future async f: x->y --> future
• future then_result f: x->result y --> future_result
• future then_maybe f: x->maybe y --> future_maybe
• future then_result_future async f: x->result y --> future_result
• future then_maybe_future async f: x->maybe y --> future_maybe
• result then f: ok->result y --> result
• result then_future async f: ok->result y --> future_result
• result otherwise f: bad->result y --> result
• result otherwise_future async f: bad->result y --> future_result
• maybe then f: some->maybe y --> maybe
• maybe then_future async f: some->maybe y --> future_maybe
• maybe otherwise f: nothing->maybe y --> maybe
• maybe otherwise_future async f: nothing->maybe y --> future_maybe
• future_result then f: ok->result y --> future_result
• future_result then_future async f: ok->result y --> future_result
• future_result otherwise f: bad->result y --> future_result
• future_result otherwise_future async f: bad->result y --> future_result
• future_maybe then f: some->maybe y --> future_maybe
• future_maybe then_future async f: some->maybe y --> future_maybe
• future_maybe otherwise f: nothing->maybe y --> future_maybe
• future_maybe otherwise_future async f: nothing->maybe y --> future_maybe

Feature description

Future monad is required for processing pipelines with both sync and async functions when Pipe (#42) is only for sync functions (that can be then converted to Future).

We need to bring some general interface for this functions and provide multiple changes in Future monad for common intuitive syntax.

Tasks

• add > operator for working with sync functions
• make >> operator work only with async functions

⛔ #43

Feature description

When working with Result monad and async functions we might bump into variety of wrappers around functions to make it work. For that we need some dedicated FutureResult monad that internally combines everything. Compatible with Result and Future.

Tasks

• > sync Success handler
• >> async Success handler
• < sync Failure handler
• << async Failure handler
• rewrite Result's >> to >
• rewrite Result's << to <
• Result's >> now produces FutureResult (Success)
• Result's << now produces FutureResult (Failure)