You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 31, 2021. It is now read-only.
[[ LocalVariableInit ]] Make compiler responsible for initializing locals
This patch moves the 'defaulting' action on local variables from an
implicit behavior to an explicit one by adding a 'reset' bytecode op
and adds defaulting of out parameters.
The compiler generates 'reset' opcodes for all variable definitions
at the point of definition.
Copy file name to clipboardExpand all lines: docs/guides/LiveCode Builder Language Reference.md
+75-56Lines changed: 75 additions & 56 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,37 +5,37 @@ group: reference
5
5
# LiveCode Builder Language Reference
6
6
7
7
## Introduction
8
-
LiveCode Builder is a variant of the current LiveCode scripting language
9
-
(LiveCode Script) which has been designed for 'systems' building. It is
10
-
statically compiled with optional static typing and direct foreign code
8
+
LiveCode Builder is a variant of the current LiveCode scripting language
9
+
(LiveCode Script) which has been designed for 'systems' building. It is
10
+
statically compiled with optional static typing and direct foreign code
11
11
interconnect (allowing easy access to APIs written in other languages).
12
12
13
-
Unlike most languages, LiveCode Builder has been designed around the
14
-
idea of extensible syntax. Indeed, the core language is very small -
15
-
comprising declarations and control structures - with the majority of
13
+
Unlike most languages, LiveCode Builder has been designed around the
14
+
idea of extensible syntax. Indeed, the core language is very small -
15
+
comprising declarations and control structures - with the majority of
16
16
the language syntax and functionality being defined in modules.
17
17
18
-
> **Note:** It is an eventual aim that control structures will also be
18
+
> **Note:** It is an eventual aim that control structures will also be
19
19
> extensible, however this is not the case in the current incarnation).
20
20
21
-
The syntax will be familiar to anyone familiar with LiveCode Script,
22
-
however LiveCode Builder is a great deal more strict - the reason being
23
-
it is intended that it will eventually be compilable to machine code
24
-
with the performance and efficiency you'd expect from any 'traditional'
25
-
programming language. Indeed, over time we hope to move the majority of
26
-
implementation of the whole LiveCode system over to being written in
21
+
The syntax will be familiar to anyone familiar with LiveCode Script,
22
+
however LiveCode Builder is a great deal more strict - the reason being
23
+
it is intended that it will eventually be compilable to machine code
24
+
with the performance and efficiency you'd expect from any 'traditional'
25
+
programming language. Indeed, over time we hope to move the majority of
26
+
implementation of the whole LiveCode system over to being written in
27
27
LiveCode Builder.
28
28
29
-
> **Note:** One of the principal differences is that type conversion is
30
-
> strict - there is no automatic conversion between different types such
31
-
> as between number and string. Such conversion must be explicitly
32
-
> specified using syntax (currently this is using things like
29
+
> **Note:** One of the principal differences is that type conversion is
30
+
> strict - there is no automatic conversion between different types such
31
+
> as between number and string. Such conversion must be explicitly
32
+
> specified using syntax (currently this is using things like
33
33
> *... parsed as number* and *... formatted as string*.
34
34
35
35
## Tokens
36
36
37
-
The structure of tokens is similar to LiveCode Script, but again a
38
-
little stricter. The regular expressions describing the tokens are as
37
+
The structure of tokens is similar to LiveCode Script, but again a
38
+
little stricter. The regular expressions describing the tokens are as
39
39
follows:
40
40
41
41
-**Identifier**: [A-Za-z_][A-Za-z0-9_.]*
@@ -53,27 +53,27 @@ Strings use backslash ('\') as an escape - the following are understood:
53
53
-**\u{X...X}: character with unicode codepoint U+X...X - any number of nibbles may be specified, but any values greater than 0x10FFFF will be replaced by U+FFFD.
54
54
-**\\**: backslash '\'
55
55
56
-
> **Note:** The presence of '.' in identifiers are used as a namespace
56
+
> **Note:** The presence of '.' in identifiers are used as a namespace
57
57
> scope delimiter.
58
58
59
59
> **Note:** Source files are presumed to be in UTF-8 encoding.
60
60
61
61
### Case-Sensitivity
62
62
63
-
At the moment, due to the nature of the parser being used, keywords are
64
-
all case-sensitive and reserved. The result of this is that, using all
65
-
lower-case identifiers for names of definitions should be avoided.
66
-
However, identifiers *are* case-insensitive - so a variable with name
63
+
At the moment, due to the nature of the parser being used, keywords are
64
+
all case-sensitive and reserved. The result of this is that, using all
65
+
lower-case identifiers for names of definitions should be avoided.
66
+
However, identifiers *are* case-insensitive - so a variable with name
67
67
pFoo can also be referenced as PFOO, PfOO, pfoO etc.
68
68
69
-
> **Aside:** The current parser and syntax rules for LiveCode Builder
70
-
> are constructed at build-time of the LiveCode Builder compiler and
71
-
> uses *bison* (a standard parser generator tool) to build the parser.
72
-
> Unfortunately, this means that any keywords have to be reserved as the
73
-
> parser cannot distinguish the use of an identifier in context (whether
69
+
> **Aside:** The current parser and syntax rules for LiveCode Builder
70
+
> are constructed at build-time of the LiveCode Builder compiler and
71
+
> uses *bison* (a standard parser generator tool) to build the parser.
72
+
> Unfortunately, this means that any keywords have to be reserved as the
73
+
> parser cannot distinguish the use of an identifier in context (whether
74
74
> it is a keyword at a particular point, or a name of a definition).
75
75
76
-
It is highly recommended that the following naming conventions be used
76
+
It is highly recommended that the following naming conventions be used
77
77
for identifiers:
78
78
79
79
-**tVar** - for local variables
@@ -85,20 +85,20 @@ for identifiers:
85
85
-**kConstant** - for constants
86
86
- Use identifiers starting with an uppercase letter for handler and type names.
87
87
88
-
By following this convention, there will not be any ambiguity between
88
+
By following this convention, there will not be any ambiguity between
89
89
identifiers and keywords. (All keywords are all lower-case).
90
90
91
-
> **Note:** When we have a better parsing technology we will be
92
-
> evaluating whether to make keywords case-insensitive as well. At the
93
-
> very least, at that point, we expect to be able to make all keywords
91
+
> **Note:** When we have a better parsing technology we will be
92
+
> evaluating whether to make keywords case-insensitive as well. At the
93
+
> very least, at that point, we expect to be able to make all keywords
94
94
> unreserved.
95
95
96
96
## Typing
97
97
98
-
LiveCode Builder is a typed language, although typing is completely
99
-
optional in most places (the only exception being in foreign handler
100
-
declarations). If a type annotation is not specified it is simply taken
101
-
to be the most general type *optional any* (meaning any value, including
98
+
LiveCode Builder is a typed language, although typing is completely
99
+
optional in most places (the only exception being in foreign handler
100
+
declarations). If a type annotation is not specified it is simply taken
101
+
to be the most general type *optional any* (meaning any value, including
102
102
nothing).
103
103
104
104
The range of core types is relatively small, comprising the following:
@@ -210,7 +210,7 @@ definitions can only be used within the module.
210
210
211
211
> **Note**: Properties and events are, by their nature, always public as
212
212
> they define things which only make sense to access from outside.
213
-
>
213
+
>
214
214
> **Note**: When writing a library module, all public handlers are added
215
215
> to bottom of the message path in LiveCode Script.
216
216
@@ -273,7 +273,7 @@ The remaining types are as follows:
273
273
-**Pointer**: a low-level pointer (this is used with foreign code interconnect and shouldn't be generally used).
274
274
275
275
> **Note:***Integer* and *Real* are currently the same as *Number*.
276
-
276
+
277
277
> **Note:** In a subsequent update you will be able to specify lists and
278
278
> arrays of fixed types. For example, *List of String*.
279
279
@@ -313,6 +313,24 @@ The type specification for the variable is optional, if it is not
313
313
specified the type of the variable is *optional any* meaning that it can
314
314
hold any value, including being nothing.
315
315
316
+
Variables whose type has a default value are initialized to that value at the
317
+
point of definition. The default values for the standard types are:
318
+
319
+
-**optional**: nothing
320
+
-**Boolean**: false
321
+
-**Integer**: 0
322
+
-**Real**: 0.0
323
+
-**Number**: 0
324
+
-**String**: the empty string
325
+
-**Data**: the empty data
326
+
-**Array**: the empty array
327
+
-**List**: the empty list
328
+
-**nothing**: nothing
329
+
330
+
Variables whose type do not have a default value will remain unassigned and it
331
+
is a checked runtime error to fetch from such variables until they are assigned
332
+
a value.
333
+
316
334
### Handlers
317
335
318
336
HandlerDefinition
@@ -350,8 +368,10 @@ return.
350
368
351
369
> **Note:** It is a checked runtime error to return from a handler
352
370
> without ensuring all non-optional 'out' parameters have been assigned
353
-
> a value.
354
-
>
371
+
> a value. However, this will only occur for typed variables whose type does
372
+
> not have a default value as those which do will be default initialized at the
373
+
> start of the handler.
374
+
355
375
An inout parameter means that the value from the caller is copied to the
356
376
parameter variable in the callee handler on entry, and copied back out
357
377
again on exit.
@@ -385,8 +405,8 @@ low-level types to be specified making it easier to interoperate.
385
405
386
406
Foreign types map to high-level types as follows:
387
407
388
-
- bool maps to boolean
389
-
- int and uint map to integer (number)
408
+
- bool maps to boolean
409
+
- int and uint map to integer (number)
390
410
- float and double map to real (number)
391
411
392
412
This mapping means that a foreign handler with a bool parameter say,
@@ -524,15 +544,14 @@ can be used after the variable statement, but not before.
524
544
> **Note:** Variables are currently not block-scoped, they are defined
525
545
> from the point of declaration to the end of the handler - this might
526
546
> change in a subsequent revision.
527
-
528
-
Variables are initially undefined and thus cannot be fetched without a
529
-
runtime error occurring until a value is placed into them. If a variable
530
-
has been annotated with an optional type, its initial value will be
531
-
nothing.
532
-
533
-
> **Note:** It is a checked runtime error to attempt to use a
534
-
> non-optionally typed variable before it has a value.
535
-
547
+
548
+
Variables whose type have a default value are initialized with that value at
549
+
the point of definition in the handler. See the main Variables section for the
550
+
defaults of the standard types.
551
+
552
+
> **Note:** It is a checked runtime error to attempt to use a variable whose
553
+
> type has no default before it is assigned a value.
554
+
536
555
The type specification for the variable is optional, if it is not
537
556
specified the type of the variable is *optional any* meaning that it can
538
557
hold any value, including being nothing.
@@ -583,7 +602,7 @@ evaluates to a negative integer, it is taken to be zero.
583
602
584
603
> **Note:** It is a checked runtime error to use an expression not
585
604
> evaluating to a number as the Count.
586
-
605
+
587
606
The **repeat while** form repeats the body until the Condition
588
607
expression evaluates to false.
589
608
@@ -595,7 +614,7 @@ expression evaluates to true.
595
614
596
615
> **Note:** It is a checked runtime error to use an expression not
597
616
> evaluating to a boolean as the Condition.
598
-
617
+
599
618
The **repeat with** form repeats the body until the Counter variable
600
619
reaches or crosses (depending on iteration direction) the value of the
601
620
Finish expression. The counter variable is adjusted by the value of the
@@ -606,7 +625,7 @@ statement.
606
625
607
626
> **Note:** It is a checked runtime error to use expressions not
608
627
> evaluating to a number as Start, Finish or Step.
609
-
628
+
610
629
The **repeat for each** form evaluates the Container expression, and
611
630
then iterates through it in a custom manner depending on the Iterator
0 commit comments