pareas VS Ark

Compared to Halide:

* Futhark does not expose a scheduling language that gives you precise control over code generation. This is probably the main selling point of Halide.

* Futhark has a much broader focus than Halide, which is mainly oriented towards image processing. Futhark wants to support arbitrary data parallel computation. E.g. see this compiler written in Futhark: https://github.com/Snektron/pareas

Compared to Sycl:

* Futhark is a non-embedded language that is more high level than Sycl. The goals are similar in the sense that both systems to try make (data) parallel programming more accessible. The vision behind Futhark is that the conventional functional programming vocabulary is actually a pretty good fit for parallelism, and that an aggressively optimising compiler can reduce or eliminate the overhead of abstraction. I don't think Sycl is as focused on high levels of abstraction, but rather focuses on being a relatively low-level portable programming interface.

This results in two websites: - the documentation of the language on the "main" website, https://arkscript-lang.dev ; - the technical documentation (+ modules) on doxygen: https://arkscript-lang.dev/impl/

1: https://github.com/ArkScript-lang/Ark 2: https://github.com/AFLplusplus/AFLplusplus

# Documentation: https://docs.brew.sh/Formula-Cookbook # https://rubydoc.brew.sh/Formula # PLEASE REMOVE ALL GENERATED COMMENTS BEFORE SUBMITTING YOUR PULL REQUEST! class ArkscriptAT330 < Formula desc "" homepage "" license "" head "https://github.com/ArkScript-lang/Ark.git" depends_on "cmake" => :build def install # ENV.deparallelize # if your formula fails when building in parallel system "cmake", "-S", ".", "-B", "build", *std_cmake_args system "cmake", "--build", "build" system "cmake", "--install", "build" end test do # `test do` will create, run in and delete a temporary directory. # # This test will fail and we won't accept that! For Homebrew/homebrew-core # this will need to be a test that verifies the functionality of the # software. Run the test with `brew test [email protected]`. Options passed # to `brew install` such as `--HEAD` also need to be provided to `brew test`. # # The installed folder is not in the path, so use the entire path to any # executables being tested: `system "#{bin}/program", "do", "something"`. system "false" end end

Lately, I've been working on optimizations for my language, ArkScript, and finally take some time to add tail-call optimization to my compiler.

A nice and bigger example would be this one, a snake game: https://github.com/ArkScript-lang/Ark/blob/dev/examples/games/snake/snake.ark

Still working on ArkScript after releasing the 3.1.0, improving the standard library, adding modules, and working on performance improvements + adding parallel builtins soon!

Until recently, when we wanted to create new releases for ArkScript, we had to build the language on all the system we support (currently Windows and Linux), build the modules (http, console, random, etc), test everything on each operating system, and then package the needed files and directory in ZIPs. We had to go to GitHub, create a new release, add the correct tag (and not mix it with the title as they are different things!), grep the latest changelog, and add our artifacts.