Expressions are limited, because they can only return one result. In stack based languages like Forth and PostScript, any function can take and return any number of parameters. In fact they can decide at runtime how many to take and return.

PostScript is a lot like Lisp in that it's purely and simply homoiconic: PostScript code is just normal PostScript data. The "ifelse" operator takes a boolean and two expressions (executable PostScript polymorphic arrays, or any other PostScript object, executable or not -- non-executable objects are just pushed onto the stack), and executes one or the other depending on the value of the boolean parameter.

I think Lisp's multiple-value-bind is an inelegant hack, compared to the simplicity of PostScript.

PS seems like a nice language. Such a shame it's stuck on the printer: it seems like it would be a good alternative to FORTH in less memory-constrained environments.

NeWS is a Network extensible Window System developed by James Gosling at Sun in the 80's, which used PostScript not just to draw on the screen (like NeXT), but also (unlike NeXT but like AJAX) to implement entire window managers, user interface toolkits, applications, and intelligent responsive front-ends to networked applications, all in the NeWS window server (like a web browser).

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

+ used PostScript code instead of JavaScript for programming.

+ used PostScript graphics instead of DHTML and CSS for rendering.

+ used PostScript data instead of XML and JSON for data representation.

http://www.donhopkins.com/drupal/node/97

See the PSIBER and PizzaTool code I posted in the message above for an example of what was possible with NeWS!

Yes, NeWS was cool. But NeWS no longer exists, sadly.

Almost all FP languages typically have a solutions for this... it is called a tuple. With Lisp it is a list or cons cell.

ML languages have true tuples and I have to say is superior to output function variables and allows pattern matching.

Your the first I have seen to ever give a compliment to PostScript the language. I'll have to relook at Postscript (and other stack based languages).

I love PostScript! I haven't written (or stroked) a line of it in years, but it's still fun to think in. I used to do a lot of Forth programming before that, but PostScript is a lot higher level and Lispier (and NeWS's object oriented programming system was very Smalltalky).

Here's a metacircular PostScript interpreter:

http://donhopkins.com/home/archive/NeWS/ps.ps.txt

Also check out Glenn Reid's PostScript Distillery, a partial evaluator for PostScript programs that reads in an input PostScript program that draws text and graphics to print a document, and it partially evaluates it against the PostScript stencil/paint imaging model, and then writes out another canonical output PostScript program that draws the exact same document, but optimized, all in the same default user coordinate system, with redundant graphics state changes removed.

Distillery was the initial idea and working proof of concept that led to PDF, Adobe Acrobat and its Distiller which converts PostScript to PDF.

Of course if the input PostScript program that draws the document is procedural and has loops or recursion, the optimized output program has all the loops unwound and may actually be much larger! But the whole point of PDF and the Distiller is to strip out the programming language parts of PostScript and just represent the effective drawing commands.

http://donhopkins.com/home/archive/postscript/newerstill.ps....

And here's a paper about a visual PostScript programming and debugging environment for NeWS, which discusses the metacircular evaluator and PostScript distillery:

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines - October 1989: http://www.donhopkins.com/drupal/node/97

The Metacircular Postscript Interpreter

A program that interprets the language it is written in is said to be "metacircular". [Abelson, Structure and Interpretation of Computer Programs] Since PostScript, like Scheme, is a simple yet powerful language, with procedures as first class data structures, implementing "ps.ps", a metacircular PostScript interpreter, turned out to be straightforward (or drawrofthgiarts, with respect to the syntax). A metacircular PostScript interpreter should be compatible with the "exec" operator (modulo bugs and limitations). Some of the key ideas came from Crispin Goswell's PostScript implementation. [Goswell, An Implementation of PostScript]

The metacircular interpreter can be used as a debugging tool, to trace and single step through the execution of PostScript instructions. It calls a trace function before each instruction, that you can redefine to trace the execution in any way. One useful trace function animates the graphical stack on the PSIBER Space Deck step by step.

The meta-execution stack is a PostScript array, into which the metacircular interpreter pushes continuations for control structures. (forall, loop, stopped, etc...) A continuation is represented as a dictionary in which the state needed by the control structure is stored (plus some other information to help with debugging).

It is written in such a way that it can interpret itself: It has its own meta-execution stack to store the program's state, and it stashes its own state on the execution stack of the interpreter that's interpreting it, so the meta-interpreter's state does not get in the way of the program it's interpreting.

It is possible to experiment with modifications and extensions to PostScript, by revectoring functions and operators, and modifying the metacircular interpreter.

The metacircular interpreter can serve as a basis for PostScript algorithm animation. One very simple animation is a two dimensional plot of the operand stack depth (x), against the execution stack depth (y), over time.

Printing Distilled PostScript

The data structure displays (including those of the Pseudo Scientific Visualizer, described below) can be printed on a PostScript printer by capturing the drawing commands in a file.

Glenn Reid's "Distillery" program is a PostScript optimizer, that executes a page description, and (in most cases) produces another smaller, more efficient PostScript program, that prints the same image. [Reid, The Distillery] The trick is to redefine the path consuming operators, like fill, stroke, and show, so they write out the path in device space, and incremental changes to the graphics state. Even though the program that computes the display may be quite complicated, the distilled graphical output is very simple and low level, with all the loops unrolled.

The NeWS distillery uses the same basic technique as Glenn Reid's Distillery, but it is much simpler, does not optimize as much, and is not as complete.

PSIBER source: http://donhopkins.com/home/archive/psiber/cyber/litecyber.ps...

The source includes a twisty little version of QuickSort implemented in PostScript by Don Woods, who also wrote Adventure!

PSIBER is a terribly ugly example of 7775 lines of PostScript code that draws and edits and debugs other PostScript code, but here's some better code that is well commented and meant to serve as a programming example, which configures, draws and orders pizzas:

PizzaTool source: http://donhopkins.com/home/archive/NeWS/pizzatool.txt

PizzaTool man page: http://donhopkins.com/home/archive/NeWS/pizzatool.6

If you like everything being an expression, check out tcl. A lot of ideas from lisp show up in tcl, especially the idea of everything as an expression. Tcl embodies this idea while also having the look of an algol-like language. Funny it can pull this off while having basically no syntax.

Rust also has (almost) everything being an expression - things like this aren't uncommon:

    let x = if something {
        foo()
    } else {
        bar()
    }

Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

The empty tuple/unit is not the same as void. It has exactly one possible value, void has zero possible values. A way to write it in Rust is `enum Void {}` (an enumeration with no options).

The point is that both void and Unit can only produce a side effect. In everything-is-an-expression based languages Unit is exactly equivalent to void in C*.

Unit is an empty tuple:

https://en.wikipedia.org/wiki/Tuple

It's the same thing. It's a type with only a single value.

`void` in C does not have a value. You can't make a variable and put a void in it because there is no such object as "void".

That is an artificial restriction if C. Also see how ! In Rust is also loosing it's artificial restrictions.

Indeed, and there has been some talk of removing this restriction in C++ because it makes certain kinds of metaprogramming a lot more cumbersome than they should be.

Yes, and () isn't void; the poster above me is wrong. Void is...the absence of a type? It's awkward.

However, () and Unit are.

It's not the same thing, a value of type Unit can only produce a side effect (or do nothing at all).

How is that different from a value of type "empty tuple"?

True, neither are useful as values, though Unit typically conveys programmer intent (to produce a side effect), whereas the empty tuple is, in Scala at any rate, quite rare.

The empty tuple:

    scala> val empty = Tuple1(())
    empty: (Unit,) = ((),)

vs. Unit:

    scala> val empty = ()
    empty: Unit = ()

Isn't that a tuple containing a unit, and therefore not empty?

It's the closest you can get in Scala to represent an empty value whose type is `Tuple`.

The difference between an empty tuple (also known as unit) and void becomes obvious when you deal with vaguely complex trait impls. For example, if you have a trait:

    trait Foo {
        type ErrorType;
        fn bar() -> Result<u8, Foo::ErrorType>;
    }

How would you specify that your type implements Foo in such a way that bar() cannot return an error? If you were to implement it using the empty tuple (unit), like this, it could actually return an error:

    struct Abc{}
    impl Foo for Abc {
        type ErrorType = ();
        fn bar() -> Result<u8, ()> {
            Err(()) // oops, we don't want to be able to do that!
        }
    }

Instead, you can use Void here:

    enum Void{}
    struct Xyz{}
    impl Foo for Xyz {
        type ErrorType = Void;
        fn bar() -> Result<u8, Void> {
            // No way to create a Void, so the only thing we can return is an Ok
            Ok(1)
        }
    }

Aside from the obvious power to express intent (can we return an error without any information attached, or can we not error at all?), this would allow an optimizing compiler to assume that the result of Xyz::bar() is always a u8, allowing it to strip off the overhead of the Result:

    fn baz<F: Foo>(f: F) {
        match f.bar() {
            Ok(v) => println!("{}", v),
            Err(e) => panic!("{}", e)
        };
    }
    ...
    baz(Xyz); // The compiler can notice that f.bar() can never return a Result::Err, so strip off the match and assume it's a Result::Ok

A super-smart compiler would even make sure it's not storing the data for "is this an Ok or Err" in the Result<u8, Void> at all.

Finally, similarly, you can specify that certain functions are uncallable by having them take Void as a parameter.

I don't think anyone is claiming Void in Scala/Haskell/Rust is equivalent to Unit in Scala/Haskell/Rust.

The question here was Unit vs empty tuple.

Up-thread was the question of whether C "void" is more like S/H/R Unit or S/H/R Void.

Upthread was:

> If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

The implication is that () == Unit == void. The empty tuple and unit are essentially equivalent aside from name, void is something else.

Regardless of who is right, you are arguing the wrong bit of it. I contend that, to a person, everyone saying "C void is Unit" doesn't think C void is Void. Arguing that Void is not Unit is just completely spurious. Of course Void is not Unit. No one disagrees.

In truth, C void is not exactly either Void or Unit. Like Void, you can't exactly make one... but you can call functions declared to take it and write functions that return it, and really it just means "I have no information to pass" - which is more like Unit.

Type names are irrelevant here. Unit could be called "Tuple0", or be defined as a synonym of a type named such. The semantics are identical.

> For historical reasons and convenience, the tuple type with no elements (()) is often called ‘unit’ or ‘the unit type’.

https://doc.rust-lang.org/reference.html

void in C can't be created, used, or passed around - () can.

But void pointers can, and are often used.

So in Rust, the equivalent of void* with references instead looks like:

    enum Void{}
    fn foo(v: &Void){ ... }
    let bar : Void;
    fn abc() -> &Void{ ...}
    fn xyz() -> Void{ ... }

You can't create a Void, and you can't cast to it either - it's not a bottom type. So you can't put anything in bar. And as a result, you can't create a reference to a Void, so you can't call foo. And abc and xyz just can't be implemented in the first place.

On the other hand, you can do all of these just fine:

    fn foo(v: ()){ ... }
    fn bar(v: &()){ ... }
    ...
    let v = ();
    bar(&v);
    foo(v);

The fact that you can create and use an empty tuple as a value shows that it is not equivalent to Void.

(All statements here are made within the safe subset of the language - unsafe allows access to intrinsics that would allow a Void to be made, and a reference to Void.)

void * isn't related to void (or this discussion), they just reused the keyword.

This example of "everything as an expression" doesn't take it as far as Tcl, though. In the above code snippet, the conditional body is surrounded by braces, which are syntax. In Tcl, the second argument to the 'if' command is also an expression, which only uses braces as a quoting mechanism, if it needs to.

I'm not sure I understand why it matters if the syntax requires braces or not. The things inside the braces are still expressions.

It matters because if the braces are not syntax, you can decide what code to execute as the condition body at runtime.

    set condition-body {puts "Hello, world"}
    if { $condition } $condition-body

To get this to run, you need to splice in the condition-body like so,

    if { $condition } {*}$condition-body

But you get the point.

But the "then" and "else" parts of the Rust "if" are expressions. What you're talking about doesn't seem to be related to which things are expressions, it's more like being able to eval code at runtime.

The if expression is not a persuasive example. C/Java/Algol/etc all have it as well.

x = something ? foo() : bar();

The difference is that C/Java/Algol have different syntaxes for things-as-expressions and things-as-statements, and you can't put blocks in the things-as-expressions. In Rust, blocks are also expressions and so have a result (the result of the last expression in the block), so your expressions inside the if can be as complex as you like.

Since functions also have a block, and the return value of the function is the result of the block, this is much more consistent.

In GNU C, you can use a brace-enclosed statement block as an expression.

Funny story; years before I became a C programmer, and at a time when I didn't yet study ISO C properly, I discovered and used this extension naturally.

I wanted to evaluate some statements where only an expression could be used so I thought, gee, come on, can't you just put parens around it to turn it into an expression and get the value of the last expression as a return value? I tried that and it worked. And of course, if it works it's good (standards? what are those?)

Then I tried using the code with a different C compiler; oops!

Anyway, this GNU C feature doesn't have as much of an impact as you might think.

I see two issues with the ternary operator. One, the syntax is much less readable, and two, the consequent and alternate are both single expressions, so you can't do something like:

x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }

It should work in GNU C:

  x = (something) ? ({ a = foo(); baz(a) }) : ({ b = bar(); baz(b); });

However, since all your forms are actually expression statements, we can happily just use the ISO C comma operator:

  x = (something) ? (a = foo(), baz(a)) : (b = bar(); baz(b));

If C provided operators for iteration, selection and for binding some variables over a scope (that scope consisting of an expression), everything would be cool. E.g. fantasy while loop:

  x = (< y 0) ?? y++ : y;   // evaluate y++ while (< y 0), then yield y.

Variable binding:

  x = let (int x = 3, double y = 3.0) : (x++, x*y);

The problem is that some things can only be done with statements.

The ternary operator is not actually lacking anything; with the comma operator, multiple expressions can be evaluated. What's lacking is the vocabulary of what those expressions can do.

I've always read ternary statements to myself as a question.

  some_condition ? this : that

some_condition? then this, otherwise that

Typing this, I realize how hard it is to explain without speaking it :)

Is the color red? If so, this; otherwise, that.

It's a little tricky, because in the above, the `if` keyword appears after the question mark.

Is the color red? Yes-- this: no-- that.

Trying to make a parsimonious English sentence while maintaining the syntax elements : P

> some_condition ? this : that

Just read it as:

  IF some_condition THEN this ELSE that

You compute baz in both branches, you can refactor.

    x = baz(if (something) foo() else bar())

If you insist on the assignments:

x = something ? ((a=foo()), baz(a)) : ((b = bar()), baz(b));

Otherwise:

x = something ? baz(foo()) : baz(bar());

a and b have to be defined before the statement containing the terniary expression here. And the point is that you can embed arbitrary multi-statement logic in your if expressions in Rust in the same way you'd do it anywhere else.

Tcl does have a lispy feel to it, but s-expressions in Lisp are much more elegant than strings in Tcl, imho. Greenspun called Tcl the Lisp without a brain[1], which can be taken both as a compliment or an insult.

[1] http://philip.greenspun.com/tcl/introduction.adp

Tcl commands are lists, not strings. Or more precisely, they are coercible to strings or lists, but a well-formed Tcl command string is always coercible to a well-formed Tcl list (not all Tcl strings are coercible to lists).

Thanks for the correction. It's been a while since I used Tcl and my memory of it was incorrect.

It used to be strings all the way down before the object system was implemented in 8.0.

That incidentally is part of the reason why the expr command was created to process infix expressions since it would be too costly to keep converting sub-expressions back and forth from strings to numbers.

http://www.tcl.tk/software/tcltk/8.0.html

TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago.

When you don't actually care about speed, you can do some pretty cool stuff.

Yes, I worked on a startup that did pretty much something like Ruby on Rails, but with TCL, inspired by AOLServer.

The speed critical parts were written in C and loaded as TCL extensions.

Back in the first .com wave.

It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.

Interesting. There was this company called Vignette (in the same period). They too were doing .com projects for clients, and, IIRC, using AOLServer which I read was in Tcl. Tcl was used for the projects.

Yep, some of our guys went to work for them in projects across the Iberian Penisula.

That's a good idea.

Although they've been working on TCL perf (and even compilation) and there have been some improvements, especially when you're not doing metaprogramming. But still, using it on heavy loads isn't a great idea...

(I mean, honestly. I'm starting to think picolisp might be faster, and picolisp has 3 types and one data structure. Haven't run the benches yet, though.)

Hmm, was that the one headed by Phil Greenspun? Arsdigita or something like that...?

Back in the day, aolserver w/ TCL + (open)acs + pgsql/oracle was teh awesomeness compared to LAMP that everyone else was doing. Oh well... :(

No, in Portugal.

We were eventually acquired by a company doing helpdesk and CRM software.

Yeah the level of dynamicness (dynamism?) you can get in tcl is unparalleled as far as I can see. Having no types or syntax and access to the entire runtime at any point in the program opens up all kinds of crazy doors. But you're right, that slows it down.

But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being developed and a link to a talk given by one of the lead tcl core team members.

http://www.tcl-lang.org/community/tcl2015/assets/talk14/TheT...

https://www.youtube.com/watch?v=RcrqmZV88PY&t=38s

I believe IO lets you do the same. Everything is a prototype with slots, communicating via messages.

I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.

But TCL actually goes beyond that.

Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming.

in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever), you're not passing code objects: you're passing unevaled strings. This is why expr works in TCL: there's nothing special about expr, it's just actually implementing a DSL (sort of) rather than evaling your code straight up.

The practical upshot of this is that unlike smalltalk (I think: Can an ST user actually answer this?), and to a greater degree than LISP and FORTH (;immediate and readtables are a lot more painful to wrangle), you can not only modify the semantics of the language: you can modify the syntax.

Smalltalk just like Lisp has very little syntax, almost everything is built on messages, including data type creation, conditionals and loops, among other things.

Also you can at any time just completely replace one object by other via the becomes: message.

There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.

However, IIRC, unlike Lisp, ST doesn't have any AST transformation or parsing hooks (macros and readtables, in Lisp parlance), so while ST has a lot of the semantic extension capabilities of Lisp (indeed, it's more semantically extensible than some of the less Object Oriented Lisps), it lacks the syntactic capabilities for extension.

However, you know ST better than me. Am I right?

As far as I can remember no (Smalltalk was long time ago for me, 1995).

But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

>But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

That's true. In fact, there are things that messages and metaclasses can do that you can't do with AST transformations without implementing those abstractions.

>After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

I still miss this in Lisp. Some Lisps had that, once, but it's uncommon nowadays. it happens in the commercial CLs, but those are expensive. OS CL implementations rarely have good image support (in SBCL, image saving actually corrupts the RAM state to the point of nonrecoverability, and the docs recomend fork(2)ing if you want to save an image and continue your app).

Aside from the proprietary CLs, PicoLisp is the only modern lisp environment that has this kind of dynamic capability AFAICT (and while it does sort of have images, in the form of external symbols, the language doesn't encourage using them like this. Also, calling it modern is a stretch: it has more in common with LISP 1.5 than, say, CL). And the Schemes? Don't make me laugh. Scheme has many strengths, but reflection isn't one of them. It's something that I really wish the Lisps had.

One of the reasons I want to try my hand at implementing Lisp on the Spur VM at some point.

Picolisp can match it in dynamism.

Seriously, Picolisp is absolutely insane.

I just read a bit of documentation from the Picolisp page. It looks really cool, but can it reach arbitrarily far up the call stack? That's the quality of tcl that I don't see other places. The capabilities of 'upvar' and 'uplevel'.

[Edit] I should say "one of the qualities." The other important one is that Tcl has no types. Even all the lisps I know have types.

The functions you're looking for are called `up` and `run` in picolisp.

And before you ask, yes, picolisp has list interpolation (or quasiquoting, in lisp parlance), so you can control which parts of a certain chunk of code will be run when, and in which contexts. It also includes the `macro` fexpr, which makes interpolation more convenient.

Wow, very interesting. Thanks for pointing out picolisp!

>The other important one is that Tcl has no types.

Is it that it has no types or that everything is a string? asking, not stating.

Yes, everything is a string. But you can pass data around anywhere you like without worrying about coercing. A command will receive its data in string representation and treat it however it likes. So when you go to do math with the 'expr' command, 'expr' will treat its arguments as numbers.

    set x 5
    expr { $x + 3 }

'expr' receives x as the string 5 but knows to treat it as an int.

I'm not sure that's a great explanation. Maybe a decent summary of the concept of 'no types' is "the language does not presume to tell you how you can or cannot use your data."

Thanks. Yes, I get it. I had read part of the Ousterhout book. And also Don Libes' Expect book uses Tcl, since Expect is written in it. Had read a lot of that too. Both very good ones. Didn't get to use Tcl in projects though. I'd read some years ago that Tcl was used heavily in the electronics / EDA industry.

Pity that it became so associated with the Tk GUI toolkit -- half the Linux GUI apps in the 1990s were in Tcl/Tk, and when Tk fell out of favor so did Tcl.

...And with TTK, you can finally have easy-to-write cross-platform UIs that actually look native.

Seriously. If you want a decent cross-platform UI system with minimal effort, which has bindings in just about every language, TK is really worth your time now.

Tk UIs will never be acceptably native as long as scrollbars remain a separate control from the thing being scrolled. This stops OSes deciding where the scrollbars should go based on input device and locale.

On OSX in particular, Tk UIs always stick out like a sore thumb for this reason, even with TTK.

I have looked at it but don't find examples that truly look convincing,and the info in the official page look very sad.

http://wiki.tcl.tk/9485

That's outdated and unofficial. Look at some examples with ttk.

Ok, but where?

TTK is something new?

Should have been made available on the web by some browser vendor in the 90s. Netscape invented a language, Sun wanted to embed Java, but went with the applet approach in lieu of Netscape, Microsoft put vbscript in IE.

Correct me if I'm wrong but doesn't Ruby have everything (maybe just most?) things be an expression. I always liked

    x = if condition
          something
        else
          something_else
        end

Everything is an expression in Ruby, yes. Even `class` and `def` and `module`, for example. Though class, as a specific example, returns nil, so it's not terribly useful that it is one.

In Lisp, "def..." macros, like defclass, defun, etc. return the symbol to which is bound the definition. Not essential, but useful at times. I tend to find Lisp is full of details like this.

Well, Common Lisp!

In the Scheme language, many imperative forms have an unspecified result. For instance, see R7RS 4.1.6: "the result of the set! expression is unspecified".

Also, a related misfeature is that function arguments can be evaluated in any order.

Yes, this is one of the things that I really want to punch the SSC for. Assignment should have a useful return value: even C, so often said to do The Wrong Thing, got that right.

But for those of you who aren't scheme programmers, it gets worse: because when RnRS says that the result of something is "unspecified" many implementations take it literally. That's right: in many Schemes, `set!` returns the literal value #<unspecified>. I swear I'm not making this up. It's awful.

To quote Jonathan Gabriel of Penny Arcade: "Baby, why you always gotta make me hit you?"

Yes, sorry, Common was implied (not claiming it should always be, but here I wrote it without thinking about others). Scheme's unspecified results are annoying indeed.

Your profile says "Ask me about Tcl".

How?

I don't know many other tcl hackers, and I'm really interested in what the community looks like right now. I put that there to drum up conversation with a tcl hacker.

You can reach me via my profile.

Is there any literature on how to translate languages where everything is an expression to ones where it isn't, for example when compiling/transpiling to java? If/then can be translated to the ternary operator, but terms like try/catch are trickier.

An easy to follow example is Coffeescript (where everything is an expression), which transpiles in javascript (where not everything is).

Usually when I'm faced with putting a try/catch in an expression in Java, I end up wrapping it in it's own method.

It's not the nicest solution, but it would allow targeting Java without disrupting the code structure too much.

In Rust, if-else is an expression, and there's no separate ternary operator.

Yep I know. Rust although syntactically looks like an Algol [1] like language it actually barely is one :) . It is more akin to a ML language [2].

[1]: https://en.wikipedia.org/wiki/Generational_list_of_programmi...

[2]: https://en.wikipedia.org/wiki/Generational_list_of_programmi...

My current project is over 90,000 lines of C and I have programmed in C since the 1970's (as well as many other languages). I have never used a ternary operator and I think it reads quite poorly. I just use a few lines of easily read code instead. I also never use a do/while construction with the condition at the bottom of the loop. When I need such a construct I just put in an "if" and "break" where ever needed instead. I don't think C should be dissed because of a few unneeded and probably unused features. In C, you can put more than 1 statement on a line if they are separated by a ';' but I have never done that in hundred's of thousands of lines of C code.

I don't program in C but I use the ternary operator quite regularly. It's quite handy when you're populating large data structures. For limited use in that case I don't find the readability that diminished maybe even enhanced.

It's been a while since I used Common Lisp but isn't it recommended to use "if" for conditional expressions and "when"/"unless" for conditional statements?

It's a matter of code readability. "when" and "unless" are expressions too, but they look the best when they're used instead of "if" for single-branched conditionals when you don't care about return value.

Yes - from what I recall it definitely helped to make things clearer to use "if" and "when" appropriately.

The choice exists only if you have a single form to evaluate subject to the condition. If there are two or more, of course this is imperative programming and (when condition form1 form2 ...) recommends itself over (if condition (progn form1 form2 ...)). If there is only form1, either one will do, so then it's down to a decision based on whether form1 returns a useful value and/or performs a side effect.

Probably a bit off-topic: I always get frustrated with C++ because `if` is not an expression, you can't do conditional initialization under RAII easily.

if-else is an expression in Kotlin ( https://kotlinlang.org/docs/reference/control-flow.html )