Alternative to PUT value INTO variable

[RickA1]

I would like to be able to write it in a fast way with multiple comma separated evaluations in the algebraic order (x=value, instead of put value into x)

Another semantic for the SET keyword enabling it to handle this could be an option like:

SET theVar = theValue, theVar1 = theValue1, ... theVarN = theValueN

Much like the LOCAL keyword does but just setting the new value of an already created local or global variable.

For properties nothing changes.

SET the property TO value -- Still use TO for properties

------ What's the difference? ----

Code: Select all

# Old Syntax
PUT 54.3 INTO X
PUT X * 17 INTO Y
PUT Y / 4 INTO Z

# Proposed alternative syntax/semantics

SET X = 54.3, Y = X * 17, Z = Y / 4

# Commas starts new attributions, and at end of a line, triggers continuation on the next line,
# and you can do this if you wish:

SET X = 54.3,
    Y = X * 17,
    Z = Y / 4

--Less verbose, a bit more clear to follow the sequence.

[richmond62]

I don't see any particular advantage with what you propose.

[RickA1]

The advantage is listed. Write fast, write less, be more clear.

Code: Select all

# Wordy salad

PUT 54.3 INTO X
PUT X * 17 INTO Y
PUT Y / 4 INTO Z

# Setting X, Y and Z, more comfortable to read in a glance. More Math friendly.
# Ease to write in less keystrokes. Syntax closer to 99% of other current languages
# As an alternative, it does not break current code

SET X = 54.3,
    Y = X * 17,
    Z = Y / 4

[richmond62]

At which point the language starts looking less like xTalk and more like something else.

"Syntax closer to 99% of other current languages"

that certainly doesn't impress me: in fact that is one of the reasons I use Livecode INSTEAD of any othe language.

[dunbarx]

"x = 42". Of course this would be interpreted by the parser as a statement that is evaluated either "true" or "false".

Set x = 42. Well, this could probably be implemented without crashing the whole edifice.

The "put into" construction and its cousins were designed explicitly by Dan Winkler and Bill Atkinson to be palatable to non programmers, "the rest of us, in 1987 parlance, though those two could scarcely be categorized that way. The idea proposed is to use the "set" command without the word "the" to parse subsequent tokens as a new command instead of setting a property. Too close to what we are used to. I would vote no.

Could another construction work? Is it desirable? Like Richmond, I see little gain in compactness.

Craig Newman

[FourthWorld]

Too close to what we are used to. I would vote no.

I'm inclined to like the idea for that exact same reason.

[SparkOut]

I wouldn't mind "set tVar1 to 50,tVar2 to 100" but a definite no from me for the use of = in the structure.

[dunbarx]

Hmmm.

Rereading, and thinking about what Richard felt, maybe "set" could have this entirely new meaning. It would not be the first time a native word was used in more than one way. English speakers are used to that, after al.

I am so accustomed to having a list of preset values where I can quickly find what I am looking for:

put 1 into x
put 2 into y
put 3 into z
...

that I dismissed the linear version out of hand:

set x to 1,y to 2,z to 3...

It would be harder to find a particular value in a long string, but so what, as long as the original option still lived. That is a matter of personal style.

Craig

[mwieder]

The problem with "=" is that the engine's parser is already configured to interpret that as a comparison rather than an assignment.
That said, it's not the difficult to handle this with a preprocessor: convert "x=y" to "put y into x", "==" to "is". I did this in a preprocessor for a while, but later dropped it because a) nobody was interested and b) I got bored playing with it and the only advantage it offered was in translating code from other languages.

[FourthWorld]

Anything but "==", among the dumbest decisions any language designers ever made.

Why can't the parser be context-aware enough to know when=is a comparison and when it's an assignment?

Are there any contexts in which both would be acceptable? I can't think of any, and last time we ran this by this list I don't believe anyone else came up with any either, did they?

[mwieder]

Yes, in C/C++ it's a standard cutesy way of combining both an assignment and a comparison. You'll usually get a warning from the compiler to ensure that that's what you really meant, but you can say things like

Code: Select all

if (x = someFunction(y)) then
...

which both assigns a value to x and checks the boolean result of the function.

Not that I'm recommending this practice, just that it happens, and is an argument as to why the "==" operator exists.

[FourthWorld]

Good example. Thankfully the OP's suggestion was for a statement beginning with"set", which would help us avoid that ambiguity here, no?

[mwieder]

It would. I've never been fond of the "set" verb, or the "let" verb for that matter, but it would solve that problem.
I think a more xtalky syntax, though, would be something like:

Code: Select all

set x to 3
set y to "hello", z to 3.14, myVar to someArray["whatEver"]

[richmond62]

Mark's comment about C/C++ begs the question:

Are we to keep Livecode as "Hypercard for Grownups", or is it going to be transmogrified
into a sort of Visual C++?

If people want a type of Visual C++ then why don't they trot off and develop a C++, which might be a sort of C++ with the
WYSIWYG IDE of Livecode slapped on the front.

But Livecode as it is is "Hypercard ++" with all that entails, and all the historical 'baggage' that goes along with it.

There are quite a few Object Oriented and Object Based programming setups "out there" all ready, and a lot of ones
that have fallen by the wayside (think HyperNext) because they tried to be both things at the same time:

funky Hypercard-like GUI with a non-Hypercard-like progging language underneath the covers: effectively sending mixed
signals to confuse people.

If one views "put" like the "LET" statement in BASIC then it is unnecessary; and that is why in later versions of BASIC "LET" was optional;
but a "put" statement does not work like a "LET" statement, mainly because a "put" statement as well as allowing you to assign values to constants
and variables, allows you to PUT values and strings into FIELDS, to move values and strings between containers, and so on.

-------------------------------------------

It would be entirely doable to have these sorts of statements:

varXXX = 978 and stringZZZ = "with knobs on"

but when you want to start moving things around between containers you'll still need something like a "put" command.

stringHHH = stringGGG + stringJJJ could also turn out to be a right PIB as that sort of code does not wear its colours on
its chest and is difficult to sort out when it goes wrong.

[RickA1]

It would. I've never been fond of the "set" verb, or the "let" verb for that matter, but it would solve that problem.
I think a more xtalky syntax, though, would be something like:

Code: Select all

set x to 3
set y to "hello", z to 3.14, myVar to someArray["whatEver"]

You could write it more readable breaking the line like:

Code: Select all

set x to 3,
    y to "hello", -- this is great for remarks per line
    z to 3.14,
    myVar to someArray["whatEver"]

#And, using "=" as a synonym to "TO" in this context (my initial pledge), if possible, it would be great and likable to newcomers from other languages:

set x = 3,
    y = "hello", -- Here we put the "Hi people"
    z = 3.14,    -- Here we set Pi
    myVar = someArray["whatEver"]

# Remember, LOCAL does this for initialization. SET could do this to replace values. LOCAL should follow the continuation, after comma, in the next line too (currently it's not).

still need something like a "put" command.

Richmond, you probably missed my statement:

# As an alternative syntax, nothing changes, it does not break current code

No one is proposing to remove PUT, just create an alternative shortcut syntax allowing people to choose.