Go Down

Topic: Designing a new programming language for Arduino (Read 14042 times) previous topic - next topic

GrooveFlotilla

Why not use the Pascal trick (inherited from ALGOL) of distinguishing an assignment ( x := y ) from a comparison ( if ( x = y) )?
Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

UKHeliBob

Why not use the Pascal trick (inherited from ALGOL) of distinguishing an assignment ( x := y ) from a comparison ( if ( x = y) )?
or the C trick of distinguishing an assignment ( x = y ) from a comparison ( if ( x == y) )?

I'm sorry, but if a beginner cannot use = and == properly then they are unlikely to use := and = properly.
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

GrooveFlotilla

The thing is, at school you're taught that = is part of an equation ( left side of = sign is identical to right hand side), so in C, "x = x + 1;" is clearly arithmetically nonsensical.
Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

UKHeliBob

Quote
in C, "x = x + 1;" is clearly arithmetically nonsensical.
True, but I am not convinced that beginners worry about such niceties.  Personally I have never had any problem understanding the x = x + 1 construction and have never given a single thought to the fact that both sides of the = are normally identical.  My brain simply says that as a result of the operation x will now equal its original value plus 1.

Quote
at school you're taught that = is part of an equation ( left side of = sign is identical to right hand side)
Quote
( if ( x = y) )
Here both sides of the = may or may not be identical.  Where does that leave the notion that both sides must be identical ?
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

GrooveFlotilla

Quote
Here both sides of the = may or may not be identical. 
You've just asked the question "Here both sides of the = may or may not be identical.  the left side is equal to the right".

Quote
Personally I have never had any problem understanding the x = x + 1 construction
It was one of the hardest  things I had to overcome, converting from ALGOL and Pascal.
Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

Robin2

#35
Nov 15, 2015, 09:46 pm Last Edit: Nov 15, 2015, 09:48 pm by Robin2
Quote
in a system with no declaration types and no semicolons this converts into:
Why wouldn't you treat the end-of-line as the end of a statement if there is no semi-colon?

It is possible to have continuation character for the odd occasions when code needs to run on to a second line.

Indeed, if semi-colons don't matter why not just run over the code and delete them and always use the EOL as the delimiter.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

YemSalat

#36
Nov 16, 2015, 01:39 am Last Edit: Nov 16, 2015, 08:28 am by YemSalat
Why not use the Pascal trick (inherited from ALGOL) of distinguishing an assignment ( x := y ) from a comparison ( if ( x = y) )?
I have been thinking about this myself, I am not entirely convinced this is a good solution, I think it makes the language a little bit more 'cryptic'. I've been playing with Go language a couple month back, it is similar to Pascal in this respect, and guess which question comes up ever so often in Go community ( http://stackoverflow.com/questions/16521472/assignment-operator-in-go-language )

or the C trick of distinguishing an assignment ( x = y ) from a comparison ( if ( x == y) )?
This is what I am doing now. Overall I would prefer to keep the syntax more similar to C (since it is so popular among embedded systems programmers)


I remember I was using some program back in the day to generate simple animations, I can't remember what was the name of the program, but it had a simple scripting language built into it, and in that language the '=' sign was treated differently depending on the context.

So for example, this is assignment: a = 23
But this is equality check: if ( a = 17 ) - since you rarely want to actually assign something inside an if statement.

This makes sense when you translate the code into English and replace '=' with 'is', so you get:
a is 23
if a is 17


I remember that I never had problems with this concept, perhaps could do something similar? I am not a big fan of context-dependent behaviour though.


Why wouldn't you treat the end-of-line as the end of a statement if there is no semi-colon?

It is possible to have continuation character for the odd occasions when code needs to run on to a second line.

Indeed, if semi-colons don't matter why not just run over the code and delete them and always use the EOL as the delimiter.

...R
That's pretty much what is happening now, Assignment expressions were just one of the edge cases where this can actually break things. All other expressions seem to be 'multi-line safe'.
E.g. you can also define multiple variables like so:
Code: [Select]
int a = 1,
    b = 2,
    c = 3

CrossRoads

Quote
Why not use the Pascal trick (inherited from ALGOL) of distinguishing an assignment ( x := y ) from a comparison ( if ( x = y) )?
Two symbols are two symbols, I have no problem with ==.
At the same time, context within an if( ) makes sense too, I've never written anything where I assigned a value within an if ( ) statement, that is just too convoluted for me. Write it as two lines, let the compiler deal with it.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

Especially where : needs a Shift press too.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Robin2

Especially where : needs a Shift press too.
Agree 100%. That's also why I hate underscore characters in code.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

YemSalat

#40
Nov 16, 2015, 10:56 am Last Edit: Nov 16, 2015, 11:06 am by YemSalat
Ok, so far we have the following options:

1)
Code: [Select]
=          // assignment
==         // check

 

2)
Code: [Select]
:=         // or..
int x = .. // assignment

==         // check


3)
Code: [Select]
=          // both assignment and equality check

I personally prefer #1, as it is the most C-like. (And indeed does not require pressing additional keys)
I am not a huge fan of #3 because it would have to be excluded from expressions where its hard to tell whether its an assignment or a logical operation:
Code: [Select]
bool isPressed = (reading = 3) // or
bool isPressed = isOn = 1 // etc.

pYro_65

Two symbols are two symbols, I have no problem with ==.
At the same time, context within an if( ) makes sense too, I've never written anything where I assigned a value within an if ( ) statement, that is just too convoluted for me. Write it as two lines, let the compiler deal with it.
Agreed, it is far easier to recognize what is happening with two lines, however both switch and if statements have an exception; initialization.


if( int valueNotZero = random(0,10)){
  //use valueNotZero if value not zero
}


switch( int resultOfComplexAlgo = ...){
  case whatever:
    //use resultOfComplexAlgo in case easily
  break;
}


Of course this is still subject to personal preferences, but a very tidy use none the less (keeps locals scoped to where they belong).
Forum Mod anyone?
https://arduino.land/Moduino/

UKHeliBob

I would favour option 1, ie =/== as in C

The new programming language is unlikely to expand to become as feature rich as C++ unless something extraordinary happens, so making it as C like as possible to allow a smooth transition at a later date would seem to make sense.

What might make even more sense would be to make it a subset of C++ but with better possible error trapping at the time of input and more informative error messages.  For instance, assignment in an if statement is possible as has been shown but is relatively unlikely.  Maybe the preprocessor could query the use of a single = in an if statement and the use of a == in what is probably an assignment statement with an option to turn off the querying of such uses.
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

westfw

I know!   For comparison, we should use something less symbolic.   Maybe "if a .eq. b then xxx" ?
Maybe for assignment, we can add an additional keyword to make that more obvious, say "let a = b"

 :-)  (some people should recognize this as a joke.)


Robin2

The thing that I want to see made more intuitive is * and & as used for pointers. I understand pointers but I just can't get my brain to interpret those symbols intuitively in the same way that it does with +, -  and = (or even ==).

...T
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up