Add a set of keywords to make a printable sequence perform a short-circuiting boolean operation:

Proposal

Make sequences configurable to perform various boolean operations by prefixing them with any of several special @is-keywords. Each printed value acts as a separate operand; whitespace is ignored.

Short-circuiting

Some operations are "short-circuiting"-- meaning that Rant may not evaluate the entire sequence in the scope if the result can be determined early. For example, if the first operand of a short-circuiting AND operation evaluates to false, we know that the result will be false, so we can skip evaluating the rest of the operands.

Eagerness

The + token can be placed after the operator keyword (e.g. @isany+) to disable short-circuiting and make the sequence eagerly evaluated.

@isany

The @isany keyword creates a short-circuiting boolean OR expression.

Truth table

@isall

The @isall keyword creates a short-circuiting boolean AND expression.
Its complement is @isntall.

Truth table

@isntall

The @isntall keyword creates a short-circuiting boolean NAND expression.

Truth table

@isnone

The @isnone keyword creates a short-circuiting boolean NOR expression.
Its complement is @isany.

Truth table

@isone

The @isone keyword creates a short-circuiting boolean XOR expression.

Truth table

@ismany

The @ismany keyword creates a short-circuiting expression that evaluates to true if more than one of the operands evaluates to true; otherwise, it evaluates to false.

Truth table

@issame

The @issame keyword creates a short-circuiting equality expression.
Its complement is @isdiff.

Although the truth table shows boolean inputs, this operation accepts all types.

Truth table

@isdiff

The @isdiff keyword creates a short-circuiting inequality expression.
Its complement is @issame.

Although the truth table shows boolean inputs, this operation accepts all types.

Truth table

Optional parameters in user function signatures should accept an optional default value. This value populates the parameter if the caller does not provide a value for it.

Syntax

The default value should appear directly after the ? modifier and be a compile-time, immutable constant (e.g. any atomic or immutable collection type)

[%opt-func: a ? foo] {
  <a>
}
[opt-func] # should print 'foo'
[opt-func: bar] @ should print 'bar'

Any of the following tokens should be accepted as a fallback:

• String literal
• Single fragment
• Number literal
• Stored block
• Boolean literal
• Lambdas

It says on the readme, "Rant is a dynamically-typed, multi-paradigm templating language designed primarily for procedural generation." So, would calling it a text templating language be right, or is there another phrase that describes it better and or in a more common way? I never heard of software like this, what other pieces of software are there are comparable to Rant lang?

trying to pipe a file into rant-cli with '<' operator causes weird endless loop.

rant < public/rant.rant 
>> Heads
Tails
Heads
Heads
Heads
Tails
Heads
Heads
Heads
Heads

>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>

Add if-else expressions to the language itself to simplify boolean branching

Proposal

Introduce the @if, @elseif, and @else keywords.

@if

@if is non-contextual and requires two parts: a condition and a body. Both can be any Rant expression (not a sequence).

In contrast to the existing [if] behavior, the body is not required to be (but can still be) a block.

# General structure
@if <condition> <body>

# Examples
@if [eq: <a>; <b>] "It's a match!"

@if [eq: <a>; <b>] {
  "It's a match!"
}

@elseif

@elseif behaves the same as @if but only runs if the previous @if or @elseif condition was not met.

@elseif has the same syntax as @if but is contextual: it must directly follow an @if or @elseif body.

<$a = 2>
@if [eq: <a>; 1] "one"
@elseif [eq: <a>; 2] "two"

# should print "two"

@else

@else runs an expression if the penultimate @if or @elseif condition in the current chain was not met.

@else must follow the body of an @if or @elseif and only requires the body component.

<$a = 3>
@if [eq: <a>; 1] "one"
@elseif [eq: <a>; 2] "two"
@else "neither one nor two"

# should print "neither one nor two"

List initializers should allow a trailing semicolon at the end of the element list without automatically creating an empty at the end of the list.

Proposal

The following rules should apply when parsing semicolons in a list initializer context:

An empty list initializer with no semicolons produces an empty list

This is the current behavior, but it is worth noting that this should remain the case.

() # empty list

A semicolon only guarantees a value to its left

Even if there is nothing before the semicolon, it should signal to the compiler that there should be an empty element.

(;) # same as (~)

A final value with a terminating semicolon acts the same one without it

If a list ends with a value and no trailing semicolon, it should compile to the same list as one with the semicolon.

# 2-item list without trailing semi
(a; b) 
# Same 2-item list with trailing semi
(a; b;)

Add support for prototype functions to map objects for OOP workflows, custom access logic, etc.

This is a WIP issue for ongoing design work on prototypes.

Getting and setting prototypes

Map prototypes can be retrieved and assigned with [proto] and [set-proto] respectively:

<$myobj = @()>
<$myproto = @(proto-method = [?]{foo})>
[set-proto:<myobj>;<myproto>]
[proto:<myobj>] # [map(1)]

Prototype methods

Elements of a map's prototype act like elements of the owning map.

<$myobj = @()>
<$myproto = @()>

[$myobj/test] { foo }
[$myproto/test] { bar }

[set-proto: <myobj>; <myproto>]

[myobj/test] # bar

Implement the @on keyword to allow blocks to be used for pattern matching.