Examine individual changes

[ 0 => 'Charm is a mostly concatenative, stack-based functional language. It operates on the property that all code is a list of data, and that all data can be interpreted as code (very much in the Lisp spirit). It was created in 2017 and is actively maintained by [[User:Aearnus]]. ', 1 => '=== Quick Links ===', 2 => '', 3 => 'Github (Download Charm! Read the README!): https://github.com/Aearnus/charm', 4 => '', 5 => 'Glossary (Browse the functions!): https://charm-glossary-aearnus.hashbase.io/', 6 => '', 7 => '(Or, use this P2P link to support the open web: dat://f6365c0b3fb82a732d125dc091b2dfc3518f39bbe8f0acdbf8956128ddd6b078/)', 8 => '', 9 => '=== The Charm Philosophy (Why Charm?) ===', 10 => '', 11 => '* Lispiness: All code is data and all data is code. With this comes very powerful tooling for metaprogramming and surprising abstractions.', 12 => '* Functionality: Everything written is a function -- with the exclusion of the next point.', 13 => '* Simplicity: There is little syntactic cruft. The only significant syntax in Charm is the space character, '':='', ''"'', and ''[ ]''', 14 => '* Speed: Speed takes a forefront in the Charm Interpreter, with stack manipulation code running at near native speed for comparable operations . More on optimization later...', 15 => '', 16 => '=== Example Charm Session ===', 17 => '', 18 => 'This was taken off the [https://github.com/Aearnus/charm/blob/master/Readme.md Charm Readme] with minimal modifications.', 19 => '', 20 => '<pre>', 21 => 'aearnus@aearnus:~/charm$ ./charm-release', 22 => 'Charm Interpreter v0.0.1', 23 => 'Made by @Aearnus', 24 => 'Looking for Prelude.charm...', 25 => 'Prelude.charm loaded.', 26 => '', 27 => 'Charm$ addOneToN := " n " getref 1 + " n " flip setref', 28 => 'Charm$ printN := " n " getref print pop', 29 => 'Charm$ printN', 30 => '0', 31 => 'Charm$ addOneToN printN', 32 => '1', 33 => 'Charm$ [ addOneToN ] 10 repeat', 34 => 'Charm$ print', 35 => '[ addOneToN addOneToN addOneToN addOneToN addOneToN addOneToN addOneToN addOneToN addOneToN addOneToN ]', 36 => 'Charm$ i', 37 => 'Charm$ printN', 38 => '11', 39 => '</pre>', 40 => '', 41 => '', 42 => '=== About Charm ===', 43 => '', 44 => '==== Basic Syntax ====', 45 => '', 46 => 'Charm has an extremely simple syntax. Everything is space delimited, and there is only one special construct - the function definition. Functions are defined using <code>function name := function body</code> and are tail call optimized for most use cases. Lists are defined using <code>[ ]</code>. Strings are defined using <code>" "</code>. Numbers can be either integers (long longs) or floats (long doubles). The stack is initialized to 20000 zero integers.', 47 => '', 48 => 'Everything in Charm is a function - the four types are number functions, string functions, list functions, and defined functions. Functions always get executed immediately upon being called -- but the first three types simply push themselves to the stack.', 49 => '', 50 => '==== Implementation ====', 51 => '', 52 => 'Many functions are preprogrammed (in C++) into Charm. This includes object and stack manipulation, arithmetic, and some combinators. But, others are in the standard library of Charm, called Prelude.charm. The glossary explains functions with its arguments using calling order, placing the deepest value on the stack first. This mirrors how it would be written with Charm itself.', 53 => '', 54 => '==== Optimization ==== ', 55 => '', 56 => 'Charm uses a self-written optimizing interpreter. I'm very interested in the use cases and the effectiveness of the optimizations. The interpreter performs two optimizations: inlining and tail-call.', 57 => '', 58 => 'Inlining optimization is enabled by default through the compilation option -DOPTIMIZE_INLINE=true. Inlining optimization occurs if the interpreter detects that a function isn't recursive. If it isn't, the interpreter writes in the contents of the function wherever it is called, instead of writing the function itself (like a text macro). This removes 1 (or more, depending on how deep the inlining goes) layer of function redirection.', 59 => '', 60 => 'Tail-call optimization is necessary for this language, as there are no other ways to achieve a looping construct but recursion. There are a few cases which get tail-call optimized into a loop. These few cases are:', 61 => '', 62 => '<pre>', 63 => 'f := <code> f', 64 => 'f := [ <cond> ] [ <code> f ] [ <code> ] ifthen', 65 => 'f := [ <cond> ] [ <code> ] [ <code> f ] ifthen', 66 => 'f := [ <cond> ] [ <code> f ] [ <code> f ] ifthen (gets unrolled into a loop of the first form, ends up looking like f := [ <cond> ] [ <code> ] [ <code> ] ifthen f)', 67 => '</pre>', 68 => '', 69 => '(If you can think of any other cases or a more general case, please open an issue!). These optimizations should allow for looping code that does not smash the calling stack and significant speedups. If there are any cases where these optimizations seem to be causing incorrect side effects, please create an issue or get into contact with me.', 70 => '', 71 => '', 72 => '[[Category:Languages]]', 73 => '[[Category:Functional paradigm]]', 74 => '[[Category:2017]]', 75 => '[[Category:Stack-based]]', 76 => '[[Category:Turing complete]]', 77 => '[[Category:Implemented]]', 78 => '[[Category:Self-modifying]]' ]