Constant command

Richard Gaskin ambassador at
Thu Oct 14 20:13:07 EDT 2010

Bob Sneidar wrote:

 > Well I was thinking more in terms of low level file I/O.

Indeed, and here Rev bests HC by a wide margin.  In HC you had no choice 
but to read and write files in what is the equivalent of Rev's "text" 
mode.  To do a true binary read in HC you had to write or buy and 
external, but in Rev you have that option built-in.

Let's explore this in action:

 > Let's say I need to have a rev stack creating files at a low level
 > on a server, for back end integration into something else. Those
 > files will be accessed by another platform, let's say unix. If I
 > terminated my lines with lf & cr, I would in effect only be creating
 > two line feeds.

...unless you use Rev's built-in CRLF constant, which does what you want.

But if your OS is Unix, it would be using the same native line endings 
that are native to Rev.

You'd only need to write CRLF when writing to Windows, but I believe 
(though I could well be wrong) that IIS is now smart enough to do the 
equivalent of what Rev does when reading files, since it knows that it 
lives in a world dominated by Unix servers, processes, and tools.

Even simpler would be to not think about it at all, but just write your 
data using CR and output it with a non-binary write like:

   open file <filename>


   put tData into url ("file:"&<filename>")

 > It's not a big deal now that I know, because I can create my own
 > constants and use them instead of the built in ones.

Just use CRLF when you need a return followed by a linefeed, CR when 
you're writing to a Unix-based system, or not bother and let the engine 
figure it out when it writes.

The only constant missing is one for ASCII 13, but since OS X stopped 
using that I'm not sure any supported OS uses that anymore anyway.

 > It's just an unexpected quirk that a Carriage Return constant that
 > *should* mean ASCII 13 on ALL platforms and Line Feed constant that
 > *should* mean ASCII 10 on All platforms, means different things
 > depending on Livecode and what it's running on.

Almost.  The constants are the same on all platforms.  The only 
difference between CR as used in Rev and CR as used in HC is that in Rev 
it gives you ASCII 10 rather than 13.  LF is always linefeed, CRLF is 
always return+linefeed, on all platforms.

If HyperCard had never been born chances are CR would have been mapped 
to ASCII 13 and all the xTalk code would have used LF.

But then again, if HyperCard had never been born chances are there would 
never have been a MetaCard, and we wouldn't be here on this list 
enjoying these historic quirks. ;)

 > LiveCode or it's predecessors could have done all the internal
 > conversions and still left these constants what you would expect
 > them to be. That is just my opinion. I just don't think a keyword
 > in any language should mean different things unless it's obvious.

In principle I agree with you wholeheartedly.  But this is just one of 
the several things in the language which are a bit quirky because of 
their HyperTalk/platform-specific origins.

When MC was born in '92, the world was chock full 'o HyperTalk.  If 
Raney had demanded that folks change their scripting habits to adopt LF 
because his text engine wasn't nearly as limited as HC's, that would 
have just annoyed people and might well have killed adoption long before 
it got healthy enough to warrant a company like RunRev to come along and 
move it forward.

So he did something that is indeed impure, but which lets a lot of 
legacy code and typing habits move into the 21st century with relative ease.

What kills me are the oddities like "destroyStack" which doesn't destroy 
the stack at all, or the "listBehavior" which doesn't govern the 
behavior but merely the selection appearance while the actual behavior 
driven by other list-related properties, or the "traversalOn" which 
could have been so less bizarre as simply "traversal", or the "dontWrap" 
and "dontSearch", dontRefresh", and all the other "dont*" properties 
that you have to set to true to get it to not do something, and the most 
bizzare of all, being able to use property syntax ("the") for function 
calls, but only with some functions and not others.

Ah, the mysteries....

  Richard Gaskin
  Fourth World
  LiveCode training and consulting:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

More information about the Use-livecode mailing list