Unrecognized escape sequences in string literals

[Hendrik van Rooyen]

In any case, after half a century of left-from-right assignment, I think
it's worth the experiment in a teaching language or three to try it the
other way. The closest to this I know of is the family of languages
derived from Apple's Hypertalk, where you do assignment with:

put somevalue into name

(Doesn't COBOL do something similar?)

Yup.

move banana to pineapple.

move accountnum in inrec to accountnum in outrec.

move corresponding inrec to outrec.

It should all be upper case of course...

I cannot quite recall, but I have the feeling that in the second form, "of"
was also allowed instead of "in", but it has been a while now so I am
probably wrong.

The move was powerful - it would do conversions for you based on the types of
the operands - it all "just worked".

- Hendrik

 

[MRAB]

Douglas Alan wrote:
[snip]

C++ also allows for reading from stdin like so:

cin >> myVar;

I think the direction of the arrows probably derives from languages
like APL, which had notation something like so:

myVar <- 3
[] <- myVar

"<-" was really a little arrow symbol (APL didn't use ascii), and the
first line above would assign the value 3 to myVar. In the second
line, the "[]" was really a little box symbol and represented the
terminal. Assigning to the box would cause the output to be printed
on the terminal, so the above would output "3". If you did this:

[] -> myVar

It would read a value into myVar from the terminal.

APL predates Unix by quite a few years.

No, APL is strictly right-to-left.

-> x

means "goto x".

Writing to the console is:

[] <- myVar

Reading from the console is:

myVar <- []

 

[Douglas Alan]

No, APL is strictly right-to-left.

     -> x

means "goto x".

Writing to the console is:

     [] <- myVar

Reading from the console is:

     myVar <- []

Ah, thanks for the correction. It's been 5,000 years since I used APL!

|>ouglas

 

[Douglas Alan]

One could argue that left-assigned-from-right assignment obscures the
most important part of the assignment, namely *what* you're assigning, in
favour of what you're assigning *to*.

The most important things are always the side-effects and the name-
bindings.

In a large program, it can be difficult to figure out where a name is
defined, or which version of a name a particular line of code is
seeing. Consequently languages should always go out of their way to
make tracking this as easy as possible.

Side effects are also a huge issue, and a source of many bugs. This is
one of the reasons that that are many functional languages that
prohibit or discourage side-effects. Side effects should be made as
obvious as is feasible.

This is why, for instance, in Scheme, variable assignment as an
exclamation mark in it. E.g.,

(set! x (+ x 1))

The exclamation mark is to make the fact that a side effect is
happening there stand out and be immediately apparent. And C++
provides the "const" declaration for similar reasons.

In any case, after half a century of left-from-right assignment, I think
it's worth the experiment in a teaching language or three to try it the
other way. The closest to this I know of is the family of languages
derived from Apple's Hypertalk, where you do assignment with:

put somevalue into name

That's okay with me, but only because the statement begins with "put",
which lets you know at the very beginning of the line that something
very important is happening. You don't have to scan all the way to the
right before you notice.

Still, I would prefer

let name = somevalue

as the "let" gives me the heads up right away, and then immediately
after the "let" is the name that I might want to be able to scan for
quickly.

|>ouglas

 

[Dennis Lee Bieber]

It goes down to the assembler - there are two schools:

mov a,b - for Intel like languages, this means move b to a
mov a,b - for Motorola like languages, this means move a to b

Gets confusing sometimes.

Give me the unconfusing Xerox Sigma instruction set... (working from
memory, my manuals are in storage)

lw,9 a
stw,9 b

Sigma format was:

label opcode,register [*]address[,indexregister]

* indirection indicator; load contents at the address contained in
this address

[,indexregister] optional; load contents at address after adding
contents of indexregister to that address

addresses in the range 0-15 identified registers, so register to
register ops were possible, the direction of transfer specified in the
load/store command. (the w was "word" -- 32bit; options included h and
b)

 

[Dennis Lee Bieber]

But these languages have mostly fallen out of favor. The popular
statistical programming language R still uses the

y <- y + 1

syntax, though.

Last I looked, it also accepts the = format

I would definitely not like a language that obscures assignment by
moving it over to the right side of lines.

Don't read COBOL then (assuming anyone still code COBOL without
using the COMPUTE verb)

ADD 3 TO y GIVING x.
vs
COMPUTE x = 3 + y.


APL, OTOH... (using $name for the greek characters)

hands <- 4 5 $RHO 20 ? 52

Right to left... from a range of 1..52, random numbers (?), generate 20
with no duplicates, reshape ($RHO) into a 4x5 matrix

 

[Nobody]

Now that I understand what the semantics of cout << "Hello world" are, I
don't have any problem with it either. It is a bit weird, "Hello world"

Placing the stream on the LHS allows the main forms of << to be
implemented as methods of the ostream class. C++ only considers the LHS
operand when attempting to resolve an infix operator as a method.

Also, << and >> are left-associative, and that cannot be changed by
overloading. Having the ostream on the LHS allows the operators to be
chained:

cout << "Hello" << ", " << "world" << endl

equivalent to:

(((cout << "Hello") << ", ") << "world") << endl

[operator<< returns the ostream as its result.]

Even if you could make >> right-associative, the values would have to be
written right-to-left:

endl >> "world" >> ", " >> "Hello" >> cout
i.e.:
endl >> ("world" >> (", " >> ("Hello" >> cout)))