On Saturday, October 25, 2003, at 05:39 PM, Martin Baxter wrote:
So if I had a global constant fred=123, I would expect the compiler to
use
"add fred to x" exactly as if I had written: "add 123 to x"
And to use "put fred' the same as if i'd written "put 123"
I recanted a little in other mail.
My
>Dar Scott wrote:
>I don't see how a compiled script can see a constant as other than a
>special global variable that cannot be changed.
Well I'm wading deeper into my ignorance here but I guess that from the
compiler's point of view a constant would presumably look the same way that
a variable lo
>Martin Baxter wrote:
>
>> The major difference I don't think anybody has mentioned is that since the
>> value of a constant is known at compile time, it can be inserted directly
>> into the resulting object code. So the value has only to be looked up once
>> - at compile time - whereas a variable
On Saturday, October 25, 2003, at 04:02 PM, Dar Scott wrote:
...and notice, I didn't even ask you to address the issue of passing
a pointer as an argument. :{`)
That should fall out in the above scheme.
I clicked the wrong something in the middle of writing this and the
above was sent prematur
On Saturday, October 25, 2003, at 04:10 PM, Rob Cozens wrote:
To keep this discussion simple, this can represented in XML format.
How would one get values for pointers, handles, and addresses of call
back routines via Transcript, Dar?
Ow!
Handles can be simply numbers. They have no use except t
To keep this discussion simple, this can represented in XML format.
How would one get values for pointers, handles, and addresses of call
back routines via Transcript, Dar?
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.net/who.htm
"And I, which was two fooles, do so grow thre
On Saturday, October 25, 2003, at 03:13 PM, Rob Cozens wrote:
Transcript already allows a rich representation of values and is
suitable for representing values to be configured as structures or
whatever for system calls.
OK, Dar, show me and I will grovel in mortification...especially if it
inv
On Saturday, October 25, 2003, at 02:33 PM, Rob Cozens wrote:
I don't see how a compiled script can see a constant as other than a
special global variable that cannot be changed.
I could address this a little better in relation to HyperCard...where
I at least thought I understood what was interp
Transcript already allows a rich representation of values and is
suitable for representing values to be configured as structures or
whatever for system calls.
OK, Dar, show me and I will grovel in mortification...especially if
it involves Boxes.rev:
The first argument to the Mac Interapplicatio
I don't see how a compiled script can see a constant as other than a
special global variable that cannot be changed.
I could address this a little better in relation to HyperCard...where
I at least thought I understood what was interpreted and what was
compiled and when.
A compiled script shoul
Martin Baxter wrote:
> The major difference I don't think anybody has mentioned is that since the
> value of a constant is known at compile time, it can be inserted directly
> into the resulting object code. So the value has only to be looked up once
> - at compile time - whereas a variable always
On Saturday, October 25, 2003, at 08:58 AM, Rob Cozens wrote:
In essence, what I want is the ability to declare symbol names &
values to the compiler. If support for data structures and tool box
names were included in such symbol tables, we would be one step closer
to supporting direct access
On Saturday, October 25, 2003, at 11:07 AM, Stephen Quinn Barncard
wrote:
This is the best argument I've seen for global constants. I get it.
sqb
The major difference I don't think anybody has mentioned is that
since the
value of a constant is known at compile time, it can be inserted
directl
this is exactly what Compilit! gave to Hypercard -- and allowed one
to create externals to do anything...faster..in Hypertalk code.
Tom Pittman, where are you now?
It occurs to me that, for what I want to accomplish, perhaps my
focus should be more on "compiler directives" or symbol tables than
On Saturday, October 25, 2003, at 10:39 AM, Rob Cozens wrote:
Programmer error, Jacque: constants 123 and "123" are not the same
and should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent. When
used i
This is the best argument I've seen for global constants. I get it.
sqb
The major difference I don't think anybody has mentioned is that since the
value of a constant is known at compile time, it can be inserted directly
into the resulting object code. So the value has only to be looked up once
-
Programmer error, Jacque: constants 123 and "123" are not the same
and should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent.
When used in arithmetic in a handler, the value is converted to
internal
On Saturday, October 25, 2003, at 09:49 AM, Rob Cozens wrote:
Programmer error, Jacque: constants 123 and "123" are not the same and
should not be used interchangeably.
Do you mean as compiled? Or as a matter of style?
I have gotten the impression that these are exactly equivalent. When
used
In the first case, x must be typed internally as an integer. In the
second case, x must be typed internally as a string.
Programmer error, Jacque: constants 123 and "123" are not the same
and should not be used interchangeably.
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.n
On 10/25/03 6:05 AM, Martin Baxter wrote:
I'm no expert so correct me if I'm wrong, but as I understand it, constants
are a structurally different kind of thing from variables, and there is a
bit more to it than scripting style preference.
The major difference I don't think anybody has mentioned i
Hi Martin,
I would see global constants as a worthwhile
addition, and while mimicing them with variables is obviously workable
right now, I don't think it's really equivalent, or as good a solution.
I must note that, while Alex's global constant concept struck a chord
with me, it isn't getting mu
I'm no expert so correct me if I'm wrong, but as I understand it, constants
are a structurally different kind of thing from variables, and there is a
bit more to it than scripting style preference.
The major difference I don't think anybody has mentioned is that since the
value of a constant is kn
On 10/24/03 9:52 AM, Rob Cozens wrote:
I have no doubt this is workable; but I see nothing here to convince me
that a cat skinned your way is necessarily better or worse than a cat
skinned my way.
Nope. My only point is that there is already a reasonable way to
implement global constants, and i
On 10/23/03 12:13 PM, Rob Cozens wrote:
Jacque, et al:
* My primary constant list is, in effect, an index to lines of text in a
file and/or variable. It is there to facilitate handler readability,
comprehension, and debugging.
Example:
constant badInputWarning = 244
answer sdbMessag
Jacque, et al:
* My primary constant list is, in effect, an index to lines of text
in a file and/or variable. It is there to facilitate handler
readability, comprehension, and debugging.
Example:
constant badInputWarning = 244
answer sdbMessage(badInputWarning)
tells me a lot more than
I was being sar[c]astic when I made that suggestion :-)
I eventually picked up that tone when rereading your message, Alex;
but I wasn't.
Your syntax, fleshed out to include local constants so constants can
persist across the same scopes as variables, makes sense to me and
eliminates my main ne
On Thursday, October 23, 2003, at 09:51 AM, Mark Brownell wrote:
On Thursday, October 23, 2003, at 08:43 AM, Alex Rice wrote:
I was being sarastic when I made that suggestion :-)
I usually never make a comment about typo errors mainly because I do
it so often myself, but...
If you are sarasti
On Thursday, October 23, 2003, at 08:43 AM, Alex Rice wrote:
I was being sarastic when I made that suggestion :-)
I usually never make a comment about typo errors mainly because I do it
so often myself, but...
If you are sarastic perhaps you should check your ass into an emergency
room real fa
On Thursday, October 23, 2003, at 09:23 AM, Rob Cozens wrote:
Judging from a lot of responses to this thread, we may as well throw
out "constant", and "global" keywords as well because we can just use
custom properties for every variable.
While the resulting functionality may be perceived to be
On 10/23/03 9:05 AM, Rob Cozens wrote:
Hi Jacque,
Do you really see custom properties as the preferred means of declaring
constants? Suppose pi was not a built-in constant. Would you "get the
piConstant of this stack" for every stack that used pi? Would you "get
the piConstant of stack const
Judging from a lot of responses to this thread, we may as well throw
out "constant", and "global" keywords as well because we can just
use custom properties for every variable.
While the resulting functionality may be perceived to be the same,
the underlying mechanisms are different. Each has i
Judging from a lot of responses to this thread, we may as well throw
out "constant", and "global" keywords as well because we can just
use custom properties for every variable.
Alex, et al:
In general, I am not persuaded to drop the quest to see a particular
feature implemented correctly just b
On Thursday, October 23, 2003, at 03:04 AM, Pierre Sahores wrote:
The same feeling here : unneed keywords may add unneed confusion in the
ways we can get the best from transcript
Judging from a lot of responses to this thread, we may as well throw
out "constant", and "global" keywords as well
Good morning, Richard.
I understand where you & Jacque are coming from storing constants as
stack properties; but the more I think about it, the more I see the
wisdom of Alex's global constants.
One can define the scope of variables:
global myGlobalVariable
local myLocalVariabl
On 10/23/03 7:05 AM, "Rob Cozens" <[EMAIL PROTECTED]> wrote:
> Do you really see custom properties as the preferred means of
> declaring constants? Suppose pi was not a built-in constant. Would
> you "get the piConstant of this stack" for every stack that used pi?
> Would you "get the piConstant
Although "incorporate any changes in myConstantList.txt at runtime"
maybe too much to hope for- would the script have to recompile
whenever the file is changed?
Alex, et al:
Ideally (?), include file references would be resolved at startup or
the first time each script containing an include sta
Rob Cozens wrote:
>> I'm afraid I don't see any need for global
>> constants when we've got custom properties that can do essentially the
>> same thing.
>
> Hi Jacque,
>
> Do you really see custom properties as the preferred means of
> declaring constants? Suppose pi was not a built-in constant.
Although "incorporate any changes in myConstantList.txt at runtime"
maybe too much to hope for- would the script have to recompile
whenever the file is changed?
Hi again, Alex.
Since I don't fully understand how Revolution's interpreter/compiler
work,I'm inclined to agree with you. Probably th
sez [EMAIL PROTECTED]:
>On Tuesday, October 21, 2003, at 12:16 PM, Dar Scott wrote:
>> On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
>>> Joel and Rob- I think a "global constant" feature would be a really
>>> good enhancement request.
Le jeu 23/10/2003 à 04:20, J. Landman Gay a écrit :
> On 10/22/03 8:44 PM, Stephen Quinn Barncard wrote:
>
> > But wouldn't a custom property, which can only be modified using the
> > IDE, a script or the message box be more of what you want than a
> > constant (which would have to be defined an
Regarding using custom properties as global constants. I understand one of
the issues here is the possibility of the program (or other programmer)
modifying the 'constant' --in this case the custom prop. But, one could
easily envision a setProp handler which would make this impossible.
I use custo
EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joel Rees
> Sent: Wednesday, October 22, 2003 11:21 PM
> To: How to use Revolution
> Subject: Re: cross-stack globa
On 10/22/03 8:44 PM, Stephen Quinn Barncard wrote:
But wouldn't a custom property, which can only be modified using the
IDE, a script or the message box be more of what you want than a
constant (which would have to be defined anyway in a script which would
have to be run) ?
The property is jus
On Wednesday, October 22, 2003, at 07:44 PM, Stephen Quinn Barncard
wrote:
doesn't this make a 'constant global'? -- One has to trust one's own
code somewhere, even if you had constants in Rev, they wouldn't be any
different than a variable as far as Rev cares -- it's still places
data in mem
On Wednesday, October 22, 2003, at 04:56 PM, Robert Brenstein wrote:
The latter might not be correct. At least I haven't managed to get
it working that way, so I consider it a glitch in documentation.
Details of usage Rev team can figure out better than us.
Works for me:
global g
on doit
add
But wouldn't a custom property, which can only be modified using the
IDE, a script or the message box be more of what you want than a
constant (which would have to be defined anyway in a script which
would have to be run) ?
The property is just there, with nothing to do to set it, and
nothing'
Lokking at all the various options, my vote goes for accessor functions.
They keep the value assignments in one place, are universally accessible,
and can be done easily.
I like the global constant option for the future, though. Simple,
elegant...
--
Richard Gaskin
Fourth World Media Corpora
On Wednesday, October 22, 2003, at 05:36 PM, Stephen Quinn Barncard
wrote:
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
You are quite right. I left that for
On Wednesday, October 22, 2003, at 05:36 PM, Stephen Quinn Barncard
wrote:
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
Nope, the custom property can be mod
Please excuse the obvious, but can't a custom property, say in the
main stack, act as a global constant? Set it in the IDE and it will
persist through standalone creation forever...
sqb
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all script
On Wednesday, October 22, 2003, at 04:56 PM, Robert Brenstein wrote:
The latter might not be correct. At least I haven't managed to get it
working that way, so I consider it a glitch in documentation.
Details of usage Rev team can figure out better than us.
Works for me:
global g
on doit
add
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all scripts.
Unlike global, it would not have to be declared in each handler using it.
Like constant, it would be directly usable in any handler that wants it.
Would each script that uses it, but not d
On Wednesday, October 22, 2003, at 09:23 AM, Alex Rice wrote:
Like global, it would be usable in all scripts.
Unlike global, it would not have to be declared in each handler using
it.
Like constant, it would be directly usable in any handler that wants
it.
Would each script that uses it, but not
On Wednesday, October 22, 2003, at 07:44 AM, Rob Cozens wrote:
One can accomplish most of this today:
constant kVersion=1.234
The downside here is one has defined a "constant" that can be changed,
and even globals need to be defined in each script that uses them.
Err- not really the same thin
>global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
One can accomplish most of this today:
constant kVersion=1.234
The downside here is one has defined a "constant" that can be
changed, and even globals need to be defined in each script that uses
t
Joel and Rob- I think a "global constant" feature would be a really
good enhancement request.
It is not clear to me what this would look like. Would this go into
the "first" stack, as "startup" does?
Just like global vars can't be declared outside any handlers, global
constants could not eith
On Tuesday, October 21, 2003, at 12:53 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict sin
On Tuesday, October 21, 2003, at 12:53 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict sin
On Tuesday, October 21, 2003, at 12:39 PM, Alex Rice wrote:
global constant kVersion=1.234
and have kVersion be so defined in script in the entire project.
Hmmm. This will require a decision on what is done if there is a
conflict since all scripts are compiled independently. Would this also
r
On Tuesday, October 21, 2003, at 12:16 PM, Dar Scott wrote:
On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
Joel and Rob- I think a "global constant" feature would be a really
good enhancement request.
It is not clear to me what this woul
On Tuesday, October 21, 2003, at 12:08 PM, Alex Rice wrote:
Maybe I should be submit a feature request?
Joel and Rob- I think a "global constant" feature would be a really
good enhancement request.
It is not clear to me what this would look like. Would this go into
the "first" stack, as "start
On Monday, October 20, 2003, at 10:57 PM, Joel Rees wrote:
Rob wrote:
Example: Serendipity Library defines about 265 constants; but much
of the code independence is lost because a constant must be defined
in each script that uses it rather than in a master list that can be
included in each scri
Hi, Rob, and thanks for the comments ...
> >Is there an easy way to set up something similar to file inclusion?
>
> Not that I've found or read of so far...and it would be nice if one existed.
>
> Example: Serendipity Library defines about 265 constants; but much
> of the code independence is
Hello Joel,
Is there an easy way to set up something similar to file inclusion?
Not that I've found or read of so far...and it would be nice if one existed.
Example: Serendipity Library defines about 265 constants; but much
of the code independence is lost because a constant must be defined
in
64 matches
Mail list logo