Bootstrap knowledge of LLMs ASAP. With a bias/focus to GPT.
Avoid being a link dump. Try to provide only valuable well tuned information.
Neural network links before starting with transformers.
namespace React.Plugin | |
open System | |
open System.IO | |
open Fable | |
open Fable.AST | |
open Fable.AST.Fable | |
// Tell Fable to scan for plugins in this assembly | |
[<assembly : ScanForPlugins>] |
// Computations with extensible environment, error handling, and asynchronicity | |
// I recently reviewed some F# code that turned out to be using | |
// | |
// Dependency Interpretation | |
// https://fsharpforfunandprofit.com/posts/dependencies-4/ | |
// | |
// and got thinking about whether one could construct a usable Zio like monad | |
// | |
// https://zio.dev/ |
module App | |
open Fable.Core | |
open Browser | |
open Browser.Types | |
open Fable.Core.JsInterop | |
open Fable.Core.JS | |
open Fable.Core.DynamicExtensions | |
[<AllowNullLiteral>] | |
type HTMLTemplateElement = |
(* | |
WHAT'S GOING ON HERE?! | |
Sometimes you don't care about a particular type, you're interested in one field only, let's say `EntityId`. | |
Instead of using interface (which isn't even possible if don't own a type), | |
we can do structural typing in F# using SRTP and Active Patterns. | |
Active patterns are not required for this, but they do make code much easier to use. | |
*) | |
// So we have 2 types with field `EntityId: string`: |
A few years ago when I read the presentation motivating the design behind Nessos Streams I was struck by the beauty of simplistic push streams.
type PushStream<'T> = ('T -> bool) -> bool
LINQ (in .NET) is a pull stream, ie we pull values out of the stream by calling MoveNext
+ Current
. One of the problems with pull streams is the constant checking "Are we done?" at each level in the stream.
Part 1: https://gist.github.com/mrange/1d2f3a26ca039588726fd3bd43cc8df3
Full source: https://gist.github.com/mrange/67553b312bd6a952690defe4bce3b126
In part 1 I briefly described RResult<_>
that I find sometimes is better suited for ROP than Option<_>
(because RResult<_>
allows capture of error information) or Result<_,_>
(because RResult<_>
has a homogeneous error type):
[<RequireQualifiedAccess>]
Full source: https://gist.github.com/mrange/aa9e0898492b6d384dd839bc4a2f96a1
Option<_>
is great for ROP (Railway Oriented Programming) but we get no info on what went wrong (the failure value is None
which carries no info).
With the introduction F# 4.1 we got Result<_, _>
a "smarter" Option<_>
as it allows us to pass a failure value.
However, when one inspects the signature of Result.bind
one sees a potential issue for ROP:
function verify_app_store_in_app($receipt, $is_sandbox) | |
{ | |
//$sandbox should be TRUE if you want to test against itunes sandbox servers | |
if ($is_sandbox) | |
$verify_host = "ssl://sandbox.itunes.apple.com"; | |
else | |
$verify_host = "ssl://buy.itunes.apple.com"; | |
$json='{"receipt-data" : "'.$receipt.'" }'; | |
//opening socket to itunes |