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.

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.