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 w
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
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 li
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 I
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.
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 discusssio
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
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.
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 :
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
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
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 (Tho
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
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 fi
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
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 distorsi
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
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 'set
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 substitut
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
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
it.
Hi John,
Marielle Lange wrote:
OTH, allowing ``a=4'' as a shorthand for ``put 4 into a'' harms
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 myVar
You would loose this with the x
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 no
>OTH, allowing ``a=4'' as a shorthand for ``put 4 into a'' harms
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 myVar
You would loose this with the x = 4 syntax.
Marielle
_
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 t
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 l
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 down
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 onl
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 ups
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
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
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 mai
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 th
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.)
El
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 wou
Jon wrote:
>I doubt that it is verbose enough for this crowd
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 your subs
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
:)
Jon
Eric Engle
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 vi
I doubt that it is verbose enough for this crowd
:)
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 <[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 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
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
42 matches
Mail list logo