Likes and Dislikes

[Paul D. Anderson]

Just a list of things I like and, um, like less about Mist at first
glance. None of this is intended to influence the design of the
language.

My background is a lot of Java, some C/C++. I began programming using
FORTRAN, BASIC and Pascal. Currently, like Michiel, I'm interested in
D.

1) I like the '<-' assignent operator. It correctly indicates the flow
of the operation. On the downside, it is a two character symbol, with
one shifted character, making it "hard" to type for such a common
symbol. Of course, it's no worse than ':=' in that regard. You also
lose the occasionally useful C-type operators like '+=', '-=', etc.

2) I like the '<--' identity assignment operator. Sort of gives a pass-
by-value/pass-by-reference capability to assignment. And it's
consistent with '<-'.

3) I'm ambivalent about the '=>' implication operator. I'm not sure it
is needed, although your spec says it comes in handy at times.

4) I'm ambivalent about the '@' assertion operator. It does make
assertions stand out, but I'm used to the 'assert' keyword. And I'd
prefer that the following assertion were enclosed somehow--with
parentheses or curly brackets.

5) I really like the tuples concept as a built-in feature. The only
quibble I have is the partially ordered comparison. I think either
things are ordered or not. But there may be a use case for the
concept.

6) Separation of value comparison and identity comparison is useful.
Other languages do this, but the '=' vs. '==' operators is new to me.

7) Pass-by-alias for parameters. This could be useful. But is it
possible that stack values could be referenced after the function
returns? (BTW, when I googled 'pass by alias' your spec came up 5th on
the list of returns.) And I'm not sure the name is right. Some
languages use the same term to mean pass by reference. In my head I
think 'pass by handle'. But it's a good idea.

8) Nesting vs. non-nesting block comments. This puzzles me (in D
also). Is there a time when you need a non-nesting comment block when
you have nesting comments? Seems like nesting covers both uses.

9) Pointers. One of the things I really like about Java is the absence
of explicit pointers, which suggests to me that they are not
necessary. And Mist uses two types of pointers! I understand the value
of weak pointers, if you're going to make pointers explicit. I'm just
not sure why pointers are included at all.

Overall I think Mist is an interesting and useful language. I'll be
interested to see how it develops.

Paul

[Michiel]

On Aug 8, 9:17 pm, "Paul D. Anderson" <pluto1...@gmail.com> wrote:

> Just a list of things I like and, um, like less about Mist at first
> glance. None of this is intended to influence the design of the
> language.

Your opinion may well influence the design. The language is still
constantly changing. Thanks for taking the time to tell us your
thoughts. I'm afraid our readership is not great, but this thread may
be useful to reference back to when the project starts attracting
developers.

> 1) I like the '<-' assignent operator. It correctly indicates the flow
> of the operation. On the downside, it is a two character symbol, with
> one shifted character, making it "hard" to type for such a common
> symbol. Of course, it's no worse than ':=' in that regard.

Yes, it is a downside I am willing to live with if it gives the
language a more mathematical look and feel. Using = for assignment is
just a silly remnant of C.

> You also
> lose the occasionally useful C-type operators like '+=', '-=', etc.

I'm not sure we do lose them. How would you feel about: '+<-', '-<-',
'*<-', etc.? Well, I'm keeping the option open. There seems to be not
grammatical ambiguity.

> 2) I like the '<--' identity assignment operator. Sort of gives a pass-
> by-value/pass-by-reference capability to assignment. And it's
> consistent with '<-'.

Ah, I see you've read the Mist 0.1 specs. I'm afraid that Mist 0.2 has
changed quite a bit since then. In particular, the entire value/
pointer system has changed. There is no longer a '<--' operator. It's
just '<-', and "real pointers". We've stepped away from reference
semantics for variables in favor of value semantics.

You can read the justification in the conclusion of the Mist 0.1 spec.
The most compelling reason was this: If you copy a container using
standard operators, do you copy the addresses or the values it
contains? There is no right answer, since a variable could stand for
either. Same goes for comparison.

Here's a confusing situation. With reference semantics, when there are
cross-links between two arrays, it an happen that after a copy, the
result is not equal to the original!

----------
A <- B;
@ A != B;
----------

> 3) I'm ambivalent about the '=>' implication operator. I'm not sure it
> is needed, although your spec says it comes in handy at times.

Logical implication occurs exceedingly often in formal program
specification. This justifies a dedicated operator.

This operator has now changed to '==>', since '=>' might be easily
mistaken for a comparison operator.

We've also supplied '<==>', the logical equality operator. It's
different from simple '=' equality in two ways:

* It automatically casts its operands to bool.
* It has low operator precedence. In particular, it binds more weakly
than the other logical operators: 'and', 'or', etc.

And for symmetry, we've also supplied '<=='.

The three are chain-associative (like the comparison operators),
meaning that the following two expressions are equivalent:

----------
A <==> B ==> C
(A <==> B) and (B ==> C)
----------

> 4) I'm ambivalent about the '@' assertion operator. It does make
> assertions stand out, but I'm used to the 'assert' keyword.

Assertions are among the most important constructs in the Mist
language. They're part of the reason Mist exists, as a matter of fact.
We expect they will be used quite often, so they deserve special
syntax. '@' seemed ideal for several reasons. It's a single character,
there's not really another use for it and the symbol contains the
letter 'a' (for 'assert').

From Mist 0.2 and on, '@' is used to delimit an 'assertion area'. An
assertion area starts with the first '@' and ends with the first
newline not directly followed (except for whitespace) by another '@'.
It may also end with a closing bracket that cannot be matched within
the assertion area itself. Within an assertion area, any number of
assertions may be given, terminated by ';'. For example:

----------
@ val < 0 ==> result = -1;
@ val = 0 ==> result = 0;
@ val > 0 ==> result = +1;
----------

The Mist compiler will attempt to prove that a given assertion is
satisfied for any reachable state (this is already possible in our
latest compiler). If it cannot be proved, the assertion will become a
runtime check in debug mode. You cannot get around them, and thus Mist
guarantees that every statement will be executed in a state consistent
with the current contract.

> And I'd
> prefer that the following assertion were enclosed somehow--with
> parentheses or curly brackets.

You can always use parentheses if you wish: @(expression);. But
perhaps you shouldn't hold on to this so strongly.

> 5) I really like the tuples concept as a built-in feature. The only
> quibble I have is the partially ordered comparison. I think either
> things are ordered or not. But there may be a use case for the
> concept.

Partial orders are abundant in mathematics. In Mist they are not
limited to tuples, of course. Booleans are partially ordered. false
and true are equal to themselves, but incomparable to each other.
(Neither greater nor smaller.) The subset relation is another example.
And what about a numeric type that also includes the NaN value?

> 6) Separation of value comparison and identity comparison is useful.
> Other languages do this, but the '=' vs. '==' operators is new to me.

Same story as '<-' vs. '<--'. '==' has been dropped from the language
in favor of value semantics. If you want to compare identity, you can
compare the address of two variables:

----------
if (^a = ^b) ...
----------

> 7) Pass-by-alias for parameters. This could be useful. But is it
> possible that stack values could be referenced after the function
> returns? (BTW, when I googled 'pass by alias' your spec came up 5th on
> the list of returns.) And I'm not sure the name is right. Some
> languages use the same term to mean pass by reference. In my head I
> think 'pass by handle'. But it's a good idea.

I'm sorry, but again your information is out of date. Entirely our
fault. :-)

We needed pass-by-alias because of the value/address duality of
variables. If we wanted to make an 'address-swap' function that
swapped the identities of two variables, we needed a way to give in-
function write access to the identity of the actual parameters.

You know, our decision to step back from that duality has greatly
simplified the language. I'm glad we did.

> 8) Nesting vs. non-nesting block comments. This puzzles me (in D
> also). Is there a time when you need a non-nesting comment block when
> you have nesting comments? Seems like nesting covers both uses.

I asked the very same question on the D newsgroup not a month ago! :-)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=93493

There were, apparently, a few reasons to keep the non-nesting block
comments around. It's the following trick that won me over:

/*/ (add another slash before this line to switch between A and B)
STATEMENT_A;
/*/
STATEMENT_B;
//*/

Note that the comment syntax of Mist has changed since 0.1:

| line comment
|+ nesting block comments +|
|- non-nesting block comments -|

We were not using | for anything (our logical disjunction operator is
'or'). And we wanted to use '//' for floored integer division. :-)

In the short time since we've made the change, I've grown quite
attached to '|' as a comment delimiter. It can be seen literally as a
dividing line between code and comment. And it can be used to make
nice boxes:

|````````````````````````|
| Documentation in a box |
|________________________|

Sometimes it's the little things that make it fun to design a
language. ;-)

> 9) Pointers. One of the things I really like about Java is the absence
> of explicit pointers, which suggests to me that they are not
> necessary. And Mist uses two types of pointers! I understand the value
> of weak pointers, if you're going to make pointers explicit. I'm just
> not sure why pointers are included at all.

I'm afraid we're in disagreement on this one. One of the things that
annoys me most about Java is the reference semantics, with a few value
semantic types thrown in to confuse matters. Higher up in this thread
I've given our rationale for moving to value semantics with explicit
pointers. Do not confuse Mist pointers with those of C/C++ though. For
a comparison, see this page:

http://code.google.com/p/mist/wiki/SmartPointers#Comparison

> Overall I think Mist is an interesting and useful language. I'll be
> interested to see how it develops.

Thanks again for your post. I apologize for the gap in our Mist 0.2
documentation. It's being worked on. We were not actually expecting a
lot of visitors yet.

--
Michiel

[Paul D. Anderson]

On Aug 8, 2:00 pm, Michiel <mhelv...@gmail.com> wrote:
>
> Ah, I see you've read the Mist 0.1 specs. I'm afraid that Mist 0.2 has
> changed quite a bit since then. In particular, the entire value/
> pointer system has changed. There is no longer a '<--' operator. It's
> just '<-', and "real pointers". We've stepped away from reference
> semantics for variables in favor of value semantics.
>
> You can read the justification in the conclusion of the Mist 0.1 spec.
> The most compelling reason was this: If you copy a container using
> standard operators, do you copy the addresses or the values it
> contains? There is no right answer, since a variable could stand for
> either. Same goes for comparison.
>
> Here's a confusing situation. With reference semantics, when there are
> cross-links between two arrays, it an happen that after a copy, the
> result is not equal to the original!
>
> ----------
> A <- B;
> @ A != B;
> ----------
>

> --
> Michiel

The fact that you tried and then moved away is informative in itself,
so it's probably a good thing I read the out of date spec!

Paul