The syntax of xTalk past present future

[OpenXTalkPaul]

As we (mostly Tom) are moving towards our very own implementation of an xTalk, I thought it might be good to open a thread about the syntax and things that makes an xTalk an xTalk.

All xTalks have had a base compatiblility with HyperTalk (either 1.x or 2.x) and then added on from there.
Hypertalk is well documented at this point, even the HC stack file format has been almost completely reverse engineered by now.

Most xTalks include with a visual component library that can be manipulated from xTalk scripts. The metaphor that was used in HyperCard for 'view ports' was the (now a bit dated) 3x5 Card Catalog metaphor, which closely matched the screen resolution of early compact Macintosh computers. Other HyperCard clones that have kept compatible with this metaphor may collectively be referred to as 'xCard' environments. Some other xTalk implementations have used other metaphors such as a Stage / Scene / Frames, or Book / Pages, or altogether don't have any graphical UI.

xCards

xCards have UI objects, originally referenced as 'parts', but in OXT/LC dialect scripts can use synonym 'controls', or in Extension Builder language 'scriptObjects' which its variable type for 'parts'.

Parts can encompass other 'child' parts. A stack contains cards, which can have a background / groups associated with them, backgrounds / groups can contain buttons, fields, images, and other parts.

Child parts can inherit properties such as textStyle or foregroundColor from thier parent 'parts'

Container parts such as a text field may contain data that can be referenced wholely or in segments of data which can be referenced with chunk expressions (byte 1 to 3, character -3 to -1, the second word, sentence 2, paragraph three, etc.)

Various parts can be referenced using abbreviations and may have synonyms for compatibility and plural forms.
Here's a list of how various parts and chunks have been referenced (including OXT/LCS syntax):

Code: Select all

  part            control          controls 
  stack            stacks          mainstack 
  wgt            widget		extensions
  bg            bkgnd          background
  group           groups
  button        btn         buttons       btns
  fld           field             fields        flds
  card          cd         cards         cds
  char          character         chars         characters
  byte         bytes              codepoint
  word          words         sentence         paragraph
  item         items
  token            tokens 
  file           files               URL
  menuMessage   menuMsg
  menuBar             menuItem
  msg           message
  pict          picture              image
  sound           sounds               audioClip
  movie           player               videoClip
  poly          polygon            
  grc              graphic              
  prev          previous                next
  reg           regular              --- i'm not familiar with this one!
  commandChar             cmdChar
  color             colors              colorNames  -- may include UK English spellings Colour
  gray          grey              -- colorNames lists may have different values between xTalks
  

I'm sure there's more, please free to chime in with additions.

[tperry2x]

I'm sure there's more, please free to chime in with additions.

if you look at my script colour stack (attached)

script-colour-test-7.zip

(84.96 KiB) Downloaded 101 times

and then click this button:

2025-04-08-22-21-08.png (9.92 KiB) Viewed 3689 times

You'll see it expands to show a group. If you edit that group, you'll see all the keywords and things divided up into named fields. (this naming and the keywords were pulled from the engine source - so may contain a few things not actually listed in the documentation).

2025-04-08-22-21-46.png (146.64 KiB) Viewed 3689 times

[OpenXTalkPaul]

That seems helpful, thanks.

It's not so much the reserved/keywords I was looking to catalog, more of a reference for part/objects/controls, but that leads into chunks expressions and other things.

Another thing I wanted to sort of catalog here is 'xTalk Data types'.

xTalk's don't exactly have variable 'typing'. xTalks are typically 'loosely type' scripting languages. That is, xTalk scripters never have to declare a variable's data type, in fact xTalkers don't even have to declare a variables at all before using them!
This is unlike any other programming languages such as C++ which are strictly typed. What xTalk interpreters do instead is they infer what sort of data a variable should contain by the context it's being used in.

So what are some the data types being inferred behind the curtains?
Lets start with types that are analogous to types in other languges.

Booleans -
in xTalks Bools are the literal true or false, which like most things in xTalks can be in containers and can be quoted or not so long as the string is a single word "True" or "false" (case insensity of course].

Numbers -
Obviously programming stuff uses numbers, but numbers in xTalks are not broken down into various sub-types or 'kinds of numbers' such as 'floating point 64 bit integer', the underlying type to use is inferred by the interpreter or underlying 'engine'. So for example if a number that needs to be stored in memory is a 8-bit range integer, between -127 and 127, or 0 and 255 (as in standard RGB color values), then it only needs to be a simple integer type that consumes a single byte of memory. Like most things in xTalks, Numbers can be stored in a container, property, or a quoted string, so long as that string or container evaluates to a number. Scientific notation as well a some other literals (such as hex or octals) may be acceptable to the interpreter as well.

Colors -
If you are setting a color property on a part/control, the interpreter would expect a value that is a 'color reference', that is it's one of: a string that is a valid colorName ('the colorNames' returns list of valid names), or three integers to use for RGB values, or three 8bit RGB integers encoded in HTML-color style hex string (like "#FF007F"). Rendering engines that can do higher bit depth color (like 'HDR' color) would likely use reals, 1.0 being 100% of color, so 'blue' would be "0,0,1.0", Extension Builder uses reals in underlying color references. Additionally, transparency channel may be supported in some areas, that is 'RGBA'', its 4th item is 'Alpha' channel so "0,0,255,127" is a 'blue' that is 50% transparent to whatever image is 'below' it in the renderings layers.

Text (aka 'strings') -
The original xTalk HyperTalk used Mac Roman character encoded strings that were limited to 32k in size (which was a pain), with only characters the ASCII range 1-127 (no 'null' constant built-in HyperTalk), which could be then be 'styled text', which could also be stored as styled text resources in the resource forks of classic macOS files. Others implementations have pushed beyond this limited 'MacWrite' text styling adding, Rich Text format ('the RTFText of fld..."), and HTML styling ( 'the HTMLtext'), in OXT/LC CE engine the Styled text is stored in an Array format containing 'style runs' as elements,
Of course now days the standard encoding would be UTF8, any modern xTalk implementation should be Unicode aware at this point. In the past 'the unicodeText' has been used to specifically as an indicator, but as that is now the standard, IMO they should be considered deprecated (as those forms are marked in the OXT dictionary). More useful today may be things like 'codepoint' chunk expressions dealing with multi-byte Unicode (UTF-16, UTF-32, etc.), and functions for attempting to detect if a text is UTF, or other character encodings.

Part/Controls, scriptObjects, and Chunk Expressions ( stacks, cards, backgrounds/groups, buttons, graphic, widget, field, line, word, char, etc.) -
That is the object-like references of elements that make up an 'xCard' user interface, that's a broad topic that goes beyond the scope of this thread. I just want to talk about them as a type of data here. That is, as referneces to typically visible, but maybe not, objects, also referenced broadly as 'parts' or controls. Stack,Substack,Card,Background/Groups, Field, Text in Field, etc. can all inherit properties from their parent. xTalks refernce them with 'chunk expressions'.
Some examples of object references as a 'type' (chunk expressions):

Code: Select all

stack "PopUpWindow' of stack 'MyApp" -- 'PopUpWindow' is a substack of stack 'MyApp'
-- can  be reference by generic index or visual layer number
button 1 of the currentCard -- 
part 1 of this stack -- whatever the 1st UI element is, btn, fld, image, etc., in the topStack / defaultStack is

If you use the keyword 'the selectedObjects' (or abbrev. form 'selectedObjs' ) while multiple controls are selected, it should return a line-delimited list of the object references as full chunk-expression 'paths', which can then be stored and later used to re-select the objects with using the 'select' command.
What I mean is, for example, the full chunk-expression path to some text in a card field could be like:

Code: Select all

the last char of word 12 of fld "TextDisplay" of group "cardText" of card "Greetings" of stack "/User/Paul/Documents/CardMaker.oxtstack"

Media / Resources -
Sound / Music, Movie Video, Pictures / Images, Fonts, Vector graphics

... to be continued ....