When If Is Just a Function

You can rarely successfully generalize about languages in the Lisp family. :)

TXR Lisp: (relevant to this article) there is an iff function that takes functional arguments.

Square the odd values in 0 to 9:

  1> (mapcar [iff oddp square use] 0..10)
  (0 1 2 9 4 25 6 49 8 81)

The use function is a synonym of identity: i.e. just use the incoming value as-is

Square the even ones instead by inverting oddp with notf:

  2> (mapcar [iff [notf oddp] square use] 0..10)
  (0 1 4 3 16 5 36 7 64 9)

Get rid of use with iffi: a two-argument iff with an implicit identity else:

  3> (mapcar [iffi oddp square] 0..10)
  (0 1 2 9 4 25 6 49 8 81)

Now about the point about Lisps and if: the regular if operator with value and expression arguments has a companion if function:

  4> (special-operator-p 'if)
  t
  5> (fboundp 'if)
  t

Unlike in some other dialects like Common Lisp, a symbol can have a binding in the macro or operator space, and in the function space at the same time.

But this if is not useful control. It's useful for things like being able to map over a function-like facsimile of the if operator. E.g. take an element of the (a b c d) or (x y z w) list depending on whether the leftmost list has a nil or t:

  6> [mapcar if '(nil t nil t) '(a b c d) '(x y z w)]
  (x b z d)

In the reverse direction, being able to write a macro for a function function exists, allows for ordinary macros to be "compiler macros" in the Common Lisp sense: provide optimizations for certain invocations of a function.

This dialect is not even "weird"; overall it is Common-Lisp-like. Right down to the multiple namespaces, which is why the [...] syntax exists for referring to functions and variables in a combined virtual namespace.

Any concrete feedback on looping mechanisms being confusing is appreciated.

    for { 1 2 3 } fn { x } { print x }
    ; which can also be written with fn1
    for { 1 2 3 } fn1 { .print }
    ; or latest experiment where we have syntax for 3 injected blocks 
    ; .() - same as "with"
    ; .[] - same as "reduce/with"
    ; .{} - same as "fn1"
    ; where it's already decided department from REBOL: 
    ; () is "do"
    ; [] is "vals"
    ; {} is literal block 
    for { 1 2 3 } .{ .print }

    set a 5
    puts $a  #prints 5

    set a b
    set $a 5  #equivalent to set b 5
    puts $b   #prints 5

    set a 5
    set $a b
    puts $5  #prints b

J and BQN (APL has off-ramps...)

https://code.jsoftware.com/wiki/Essays/Tacit_Expressions

https://mlochbaum.github.io/BQN/doc/tacit.html and https://mlochbaum.github.io/BQN/doc/control.html

Forth, Factor and Uiua (which combines the above approach) don't use these concepts yet are also inherently point-free, and without lambdas so you definitely wouldn't be able to rely on functional techniques!

Same here. I guess it's an issue with (system) dark theme (you can simulate that in dev tools. Android here, so must be Chrome.

This is on FF for me. Specifically Zen, which is FF based.

First-class functions are problematic too[1], but function is always a definition. While code block is usually meant to be executed right away.

[1]: https://github.com/ziglang/zig/issues/1048

That makes sense, thanks!

You can do it, but that is not how the (default) control structures work in those languages. There is usually also some syntax cost.

You may not want a fresh scope for control flow as you often want to use variables from the outer scope inside the if statement. Imagine you wanted to do something like this with your if statement implemented with a function (this is how the syntax would look like using a block argument in Ruby):

    state = "inactive"
    if_func(condition) {
        state = "active"
        activate_button.disabled = true
        deactivate_button.disabled = false
    }

In many languages you would need to wrap `state` in something that can be passed by reference, and make the function take multiple parameters. For example in JavaScript it would turn into something like this mess:

    let state = ["inactive"];
    if_func(condition, ({state, activate_button, deactivate_button}) => {
        state[0] = "active";
        activate_button.disabled = true;
        deactivate_button.disabled = false;
    }, {state, activate_button, deactivate_button});

You can't really redefine if because everything is a constant, but you can define if in your own context yes.

I wonder if it's more readable to non-programmers than control flow.

I looked at the code - it uses ternary expressions.

    No instance for (Eq (MyBool a0 -> a0 -> a0 -> a0))
        arising from a use of ‘==’

Undecidability of function equality aside, we could indeed define "myIf = id" instead.

This is both the Church encoding and the Scott encoding of the abstract data type

    data Bool = True | False

making it pretty much the only encoding you find in the literature.

This is quite different from the case of the natural numbers, where not only do the Church and Scott encoding differ, but there are several other reasonable representations fitting particular purposes.

> Python was used as an example because people know Python and reader can compare it to something known.

I don't think you understood the point I made.

My point is that Python supports conditional expressions for years.

Support for conditional expressions already means that in Python indeed "if is just a function".

Therefore, the whole premise of the article is null and void, and the article is thus pointless.

This is evident to anyone who is familiar with Python. If you have any experience with Python and you are familiar with idiomatic Python and basic features such as list comprehension, you are already widely aware how "if is just a function".

> I wasn't trying to make Python look awkward. I was trying to write equivalent Python (...)

Except you didn't. You failed to even acknowledge that Python already supports "if is just a function" with basic aspects such as list comprehension.

This basic aspect of Python is covered quite prominently in intros to Python, but somehow you failed to even acknowledge it exists, and proceeded to base your argument on a patently false claim.

    if( .... )

Bravo, Vince.

You're correct, that is lazy evaluation. The entire article talks about lazy evaluation without mentioning it, which was my point

That analogy may not be suitable for this case because value proposition between the aesthetics vs the function is different for visual art projects compared to software. There is also the maintainability factor where most aged software (especially the closed source ones in private sector) change maintainers every few years. Old maintainers most often lose access to the source code and become unreachable after leaving their job.

By all means, go full avant-garde. I have nothing against experimental stuff like this. The "throw it at the wall an see what sticks" idea.

According to my own experience, it's entirely possible to write a rancid spaghetti carbonara all by yourself. I'm not saying you shouldn't do it (it's a heck of a learning experience) or it should be banned or prevented or anything. But if the language comes with a tin of e. coli, at least list the side effects.

Yes, a lot of REBOL ideas, that Rye took, or various functional, homoiconic langauges implement (haskell, lips, clojure, scheme, Io, Factor) come from search for greater internal consistency than your ALGOL-derived status-quo languages provide. :)

So degrading the core doesn't make much sense if you are not more specific. This is the core.

10 days later... sorry, I didn't see your comment.

The example I gave had a few pieces:

- x is defined prior to the if/else, and overwritten in just one branch - y is defined in both branches

So in the rest of the function, we have both x and y available, regardless of which branch is taken.

I just took a quick read of the context page and the context basics page, but it's still unclear to me whether you can program how scopes/contexts interact in rye.

In my example, we I'd say we have a few different scopes worth mentioning, and I'm curious how programmably we can make them interact in rye:

Scope 1. Right below the first x = ...: we have names available form <beginning of the function> and have x available as the ... stuff. Presumably the `foo` in `if foo` lives in this scope.

Scope 2T. Right after the true branch's y, we have scope 1 plus y introduced

Scope 2F. Right after the false branch's x and y, we have scope 1 plus x "pointing to" something new and y introduced.

Scope 3. Below the if/else, where <rest of the function> lives. This is either scope 2T or scope 2F. x is either scope 1's x or scope 2F's x, and y is either scope 2T's y or 2F's y.

In the original articles language,

So the scope relationships in an if/else are a diamond DAG taking the names from before it, making them available in each branch's scopes, and then making a sorta disjoint union of the branch's names available afterwards. Could that be programmed in rye, to allow the kinds of naming ergonomics in my previous example, but with the if/else being programmable in the sense of the original article? I'm especially interested in whether we could overload it in the traditional autodiff sense.

Responding to a different part of your comment about using names rarely in rye, I've found that I benefit a ton from handing out names more than most people do in functional languages, just for clarity and more self-documenting code. Like, the ide can say "`apples` is broken" instead of "error in location xyz" and I can rebuild my mental state better too when revisiting code.

The `6` is the code, I just put the first thing that came to my mind there :D In my example, if you replace it with a more sophisticated code block, R will evaluate it and print out the result of the evaluation.

Typically, you'd want to parse the unevaluated code, though:

    > `if` = function(a, b) { print(substitute(a)); print(substitute(b)) }
    > if (foo) { print("bar") }
    foo
    {
        print("bar")
    }

It overwrites `if`, in the current scope, of course.