I haven't been following this thread closely, but the impression I've
got is that the arguments have centered around whether: var gets val, or
an equivalent is acceptable xtalk *style*.
I would say that var gets val conforms to the spirit of xtalk, but
unfortunately it does not conform to the
Le 24 juin 05 à 04:55, Richard Gaskin a écrit :
I don't really care all that much whether RunRev adds an OPTION for
simpler assignment syntax to make it easier to use for folks
experienced in nearly any other language to pick up Transcript.
Agreed.
Finally, I think that all this
On 24 Jun 2005, at 03:55, Richard Gaskin wrote:
It's hard to get less xTalk-like than RegEx, but those who use it
seem to like it and those who don't aren't bothered by its
availability.
Nobody *likes* RegEx. But it is powerful, and we use it because there
is no practical alternative. I
Jim,
On Jun 23, 2005, at 10:40 PM, Jim MacConnell wrote:
Dennis,
First.. thank you for your intelligent reply to my:
okay.. back into my hole...
Yes, Please stay there.
It is good to so easily learn so much of the people we correspond
with. I'm not surprised that I touched a nerve but
Dennis,
My apologies, I was a bit over the top yesterday in my reply.
Thanks... and I was a wee tad over in my response...
I guess I was a bit too obscure. The ;-) was the clue that the
statements were an example of get, put, gets syntax and a
lighthearted jab not meant to be taken too
So in Transcript left assignment might be better stated using the
familiar syntax: set var to x
The get command becomes the shortcut equivelent of: set it to
So you see Jim, now I get it!
Or,,, get is a shortcut for put the propX into it... the set -
put difference still rears its head
on 24/6/05 7:00 pm, Jim MacConnell wrote :
What a difference a few quotes make. I can hear your voice now and
understand where you were headed. Fine example of dangers of
interpreting email too literally which I am prone to do when
tired. What appeared to be sarcastic and cynical and rude
OTH, allowing ``a=4'' as a shorthand for ``put 4 into a'' harms
nobody, and meets with the expediency criterion; just don't require
it.
Hi John,
I do often write myVar = x. But I like the fact that there is a different logic
for properties and variables.
set the width to 100
put 100 into
John,
Of course you realize that if the = assignment operator was allowed
in Transcript put would all but disappear from scripts. Who wants
to type putinto vs =. Put would go the way of button vs btn. I find
myself reversing my opinion on this one. = would make a nice
shorthand
Marielle Lange wrote:
OTH, allowing ``a=4'' as a shorthand for ``put 4 into a'' harms
nobody, and meets with the expediency criterion; just don't require
it.
Hi John,
I do often write myVar = x. But I like the fact that there is a different logic
for properties and variables.
set the
Hello Richard,
Since it would be optional as it is in other xTalks, nothing would
be lost.
Except the spirit :-)
Grasp all, lose all...
Le 23 juin 05 à 18:53, Richard Gaskin a écrit :
Marielle Lange wrote:
OTH, allowing ``a=4'' as a shorthand for ``put 4 into a'' harms
nobody, and
Here is an answer that everyone might like:
The get x construct is already a syntactic equivalent of it=
x (left assignment).
That could be expanded to the general form it gets x.
Now we have a general xTalk flavored version using the new gets
keyword.
From there just substitute any
On Jun 23, 2005, at 11:17 AM, Dennis Brown wrote:
The get x construct is already a syntactic equivalent of it= x
(left assignment).
That could be expanded to the general form it gets x.
Now we have a general xTalk flavored version using the new gets
keyword.
From there just substitute any
On Jun 23, 2005, at 4:13 AM, Marielle Lange wrote:
But I like the fact that there is a different logic
for properties and variables.
set the width to 100
put 100 into myVar
I'm curious as to why you like the different syntaxes?
I sometimes accidently try to use 'put' when I need
Eric Chatonet wrote:
Hello Richard,
Since it would be optional as it is in other xTalks, nothing would be
lost.
Except the spirit :-)
Grasp all, lose all...
With the current flexibility of xTalk, we can choose to write:
put 1 + tMyVar into tMyVar
..or we can write:
add 1 to tMyVar
Hi Richard,
Don't think it's a problem of religion :-)
Or you want to maintain an every day language or you want to allow
specialists languages come in.
As for me I don't mind : I use both.
But I think that all guys who invented Xtalks principles would not
agree.
In fact, if some
Dar-
Thursday, June 23, 2005, 10:40:06 AM, you wrote:
DS Commands in xTalk follow the English implied-you imperatives. The
DS deviation from that to a descriptive of the dataflow does not fit. I
DS come from a functional programming background, but I accept the
DS imperative style.
Exactly.
Dar,
I am not arguing for =, I am arguing for gets and some shortcut
that suits, if any. Gets is a cousin of get command that is
already a left assignment operator. It does not introduce a new
concept to the syntax, but just makes the get construct more
general. I actually find it a
Dennis-
Thursday, June 23, 2005, 12:57:04 PM, you wrote:
DB easily change my mind later. I would be happy to be able to change
DB get x to myVariable gets x.
That's not the same syntax at all. The analogy for
myVariable gets x is
put x into myVariable
while
get x comes out as
Hi.
I've been listening to this discussion and find it intriguing. I
personally have nothing against := and = for variable assignment
and have used them when using a tool that requires them. I also can
quickly adapt to the == concept for comparisons and =+ for
incrementing (Though that
On Jun 23, 2005, at 4:13 PM, Jim MacConnell wrote:
In contrast I think adding the put x into y construct would help a
lot of other code (C, VB, ++) be more readable
I was thinking of an arrow pointing into the open top of a shoe box
labeled with the variable name on the side.
BTW, I
okay.. back into my hole...
Yes, Please stay there.
I personally have nothing against := and = for variable
assignment and have used them
My problem with the concept of gets is that I can't see how it
fits within the conceptual framework of xTalk
var := x
var == x
var = x --this is a
Dennis,
First.. thank you for your intelligent reply to my:
okay.. back into my hole...
Yes, Please stay there.
It is good to so easily learn so much of the people we correspond
with. I'm not surprised that I touched a nerve but I am surprised at
the scream ... sorry ;-{ )
Second..
var
Eric Chatonet wrote:
Hi Richard,
Don't think it's a problem of religion :-)
Agreed, that was an imprecise choice on my part.
But I do think at the hear of things it's a philosophical issue.
Or you want to maintain an every day language or you want to allow
specialists languages come in.
Dan Shafer [EMAIL PROTECTED] wrote:
(I always found the whole ==, +=, :=, == syntax mess pretty ugly. I
love the elegance of put 32 into x.)
;-)
why not ending lines by a ;
-- but not always, unless the program bugs silently ;-
--
Revolutionario
I doubt that it is verbose enough for this crowd sick grin
:)
Jon
Eric Engle wrote:
Is there any chance that transcript will incorporate the := operator?
This is the pascal operator of affectation (put value into variable -- variable
:= value)
This operator is available in lingo.
Dan Shafer wrote:
(I always found the whole ==, +=, :=, == syntax mess pretty ugly. I
love the elegance of put 32 into x.)
Elegance, verbosity. Poe-tay-toe, poe-tah-toe...
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please
Hi Jon and others,
Transcript is designed to be an XTalk language.
The XTalk basis is to look like every day english language.
If it looses this easiness, it's no longer an XTalk ;-)
Le 22 juin 05 à 16:59, Jon a écrit :
I doubt that it is verbose enough for this crowd sick grin
:)
Jon
Jon wrote:
I doubt that it is verbose enough for this crowd sick grin
I´m sure I´ve got some medication left...
Cheers,
Malte
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
Jon wrote:
Dan Shafer wrote:
(I always found the whole ==, +=, :=, == syntax mess pretty ugly. I
love the elegance of put 32 into x.)
Elegance, verbosity. Poe-tay-toe, poe-tah-toe...
A single-token assignment operator would be a nice OPTION. Those who
prefer the traditional form
I find myself constantly typing tSomeVariable = 5 and then have to go
erase that and type put 5 into tSomeVariable
At 03:56 PM 6/22/2005, you wrote:
Jon wrote:
Dan Shafer wrote:
(I always found the whole ==, +=, :=, == syntax mess pretty ugly. I
love the elegance of put 32 into x.)
How is this even a continuing topic of discussion? Hey Japanese - I
think Katakana is too complicated. Let's stick to 26 symbols, ok?
Yeah. I'd like that next year. Transcript a different language. It
isn't Pascal or APL, or Fortran or Cobol or LISP or anything else, and
thank goodness for
Yep
On Jun 22, 2005, at 8:01 AM, Jon wrote:
Dan Shafer wrote:
(I always found the whole ==, +=, :=, == syntax mess pretty ugly.
I love the elegance of put 32 into x.)
Elegance, verbosity. Poe-tay-toe, poe-tah-toe...
___
use-revolution
Sorry, Richard, I respectfully disagree.
People learning a new environment are constantly confused when there
are too many ways to do the same thing. Same is true of a programming
language. One of the fundamental design principles behind Python is
that there should be only one right way to
Better yet, let's include Smalltalk, too. It uses - as the
assignment operator.
Sheesh.
Dan
On Jun 22, 2005, at 2:24 PM, Mikey wrote:
How is this even a continuing topic of discussion? Hey Japanese - I
think Katakana is too complicated. Let's stick to 26 symbols, ok?
Yeah. I'd like that
Richard-
Wednesday, June 22, 2005, 1:56:20 PM, you wrote:
RG A single-token assignment operator would be a nice OPTION. Those who
RG prefer the traditional form would never need to deal with it, while
RG those of us who are comfortable with it could use it. I see no downside
RG and many
Dan Shafer wrote:
Sorry, Richard, I respectfully disagree.
People learning a new environment are constantly confused when there
are too many ways to do the same thing. Same is true of a programming
language. One of the fundamental design principles behind Python is
that there should be
Mark Wieder wrote:
Richard-
Wednesday, June 22, 2005, 1:56:20 PM, you wrote:
RG A single-token assignment operator would be a nice OPTION. Those who
RG prefer the traditional form would never need to deal with it, while
RG those of us who are comfortable with it could use it. I see no
I could go along with two: the slow simple straightforward logical
way, and the compact high performance but more obscure way. I think
Rev already has both cased covered in the syntax.
Dennis
On Jun 22, 2005, at 6:18 PM, Dan Shafer wrote:
Sorry, Richard, I respectfully disagree.
People
It is fascinating to note that in R (GNU's S) the operator evolved
from ``-'' to ``='' despite the ambiguity of the latter (R has both
assignment operators (- and -), but still simple ``='' won out.
Why? Well, as with the letter ``e'' in English, nobody wants to type
2 characters for the
Is there any chance that transcript will incorporate the := operator?
This is the pascal operator of affectation (put value into variable -- variable
:= value)
This operator is available in lingo.
Yahoo! Sports
Rekindle the
I can't imagine why we'd want that added to the language. We don't
need yet another way to place a value in a variable. What would be
the advantage?
(I always found the whole ==, +=, :=, == syntax mess pretty ugly. I
love the elegance of put 32 into x.)
On Jun 21, 2005, at 6:47 PM, Eric
42 matches
Mail list logo
