Goals

(some of these are in conflict)

Easy to learn, natural language like.

Powerful enough to make large-scale applications.

make the language work better for us. Who's "us"? Glad you asked.

greater English-like readability

greater language power and expressiveness through English-like abstractions (Geoff Canyon)

better language for teaching

more C-like syntax

make it easier to focus on the task at hand instead of the details of the language/environment (Mark Wieder)

Guidelines

Guidelines allow us to assess the quality of a proposal.

The main guidelines are:

  1. Natural language like syntax
  2. No syntax purely for compatibility with existing languages
  3. No elements purely for backwards compatibility
  4. No surprises

Opinions

A list of opinions:

Questions

Is a core canonical language necessary? (I think yes)

Fragmentation a worry? (…All of these things may happen, and that's great - except insofar as it causes fragmentation, which is not great. (Ben Rubinstein))

Double Negatives

[Klaus Major, Devin Asay]

set the UseQT to true

Pros:

easier on novice: mentally less challenging than
set the DontUseQT to false

Cons:

Caveats:

Don't forget about the 'cant*' properties: cantModify, cantDelete, …

The Result and It

[Mike Kerner]

commands return data in it and any comments, errors, etc. in the result.

Pros:

easier on novice: mentally less challenging than
set the DontUseQT to false

Cons:

Caveat:

If completion is successful, i.e. no errors, the result currently is empty.  Putting "ok" in the result not only breaks code but excludes the setting by the user of the result to "ok" for some specific purpose.

Recommendation:

Keep empty as the value for the result.

Switch and Case

[Peter Haworth, Mike Kerner]

The Switch/Case format suffers from requiring a break at the end of each of the cases.  It should go the other way, forcing a continue on the developer who wants the execution to continue, or a keep going.

Pros:

Statistically cases are separate much more often than they run on, needing break to be inserted.

Cons:

If it is considered that continuation is frequent enough to be needed, then another keyword like keep going must be introduced.

Caveats:

Multiple tests have parsing problems if operands are omitted.

Recommendation:

Break by default.

Multiple tests on one case.

New structure and/or new keyword (old one keeps falling through, new one does not)

Regular Expressions

[Mark Wieder, Monte Goulding, Robert Cailliau]

The filter command should accept regular expressions.  There are other places where regular expressions should work:  replace and replacetext.  replacetext should also use recall of marked subexpressions.

Pros:

Useful (though for advanced users, not novice programmers)

Cons:

Recommendation:

Use regular expressions in filter and replace; abandon replacetext:  add using regular expressions:

replace "A[0-9]*" with "B[0-9]*" in lString using regular expressions replace [expression] <string> with [format] <string> in [[item X of] each line of] <string>

Where format follows the conventions of the format function but the values used come from the matched expression.

Text of image

[Roger Eller]

The text of image 1 should be "the pixels of image 1"

Pros:

Cons:

Caveats:

Recommendation:

Adopt.

Dot notation

[Obleo Beck, Colin Holgate, Mark Wieder, Monte Goulding]

Opt for dot syntax.

Pros:

It's fast, less code, more understandable and more object oriented.

we can have abstract objects without dot syntax:

append newData to MyLinkedList

Cons:

Not LC like.

Needs real object orientedness:  e.g.(Mark Wieder):

class MyLinkedList : CLinkedList local head, tail command append pData --do the obvious thing here tail.next = pData tail = pData end append end class -- append the newData listItem to the MyLinkedList linked list MyLinkedList.append(newData)

Caveats:

Dots may be used in other contexts?

Introducing classes is a truly big change to the execution model?

Recommendation:

Why not genitives:

the building's height

put 123 into field "A"'s line 2

set graphic "G"'s backgroundcolor to red

See alse quotes around identifiers, assigment statement and with statement.

Inheritance and Abstract Objects

[Monte Goulding]

Want inheritance and could do that by setting the behavior of a behavior and to define syntax for an abstract object. Ordered list of behaviors on one object.

Pros:

Cons:

Caveats:

Big change to execution model?

Recommendation:

Do not break people's code

[Rick Harrison, kee nethery, Robert Cailliau]

Many many people that have written code in LiveCode still need that code to work for them. They do not want to have to go back and rewrite all the code just to get back to where they were before the code base was changed.

Livecode needs to flourish. For each one of us "backward compatible users" you need to gain 1000 new users for whom backward compatibility is a gotcha that infuriates them. It is way easier for us old-timers to adapt to doing things in a clean consistent manner than it will be for new users to have to learn all the weird quirks of history.

There was a terrible decision in 1843 whereby the new railroad gauges were forced to change to be backwards compatible with the "standard" narrow gauge (4'8.5"). The argument was that 2000 miles of narrow gauge already existed.  One should have argued that 2 million miles still had to be built.  The result is:  too narrow railroad cars for a lot of cargo, and severe limitations on railway speed.

Pros:

Compatibility

Cons:

Stifles evolution

Caveats:

According to the Team we can have our cake and eat it

Recommendation:

Be vigilant, make sure current system is still available fro at least one year.  Help conversion through tools to identify problem code.

Synonyms

[Jeanne A. E. DeVoto, Robert Cailliau]

A lot of the proposed changes - not all, but many - can be solved by providing a synonym to an existing keyword.

Examples: destroyStack.  The word stack itself should probably become application.

Pros:

Feasible

Cons:

Cluttering the documentation

Caveats:

Recommendation:

Bloatware

[robert Cailliau]

Allowing all wishes for compatibility and alternative syntax will make the engine large, the IDE unwieldy and the documentation unreadable.

Pros:

Cons:

Caveats:

Don't go the way of IBM in the 1960s.

Recommendation:

Organic Evolution

[Ben Rubinstein, Robert Cailliau]

The language would evolve organically as people adopt or reject new syntax.
I really hope this doesn't happen.  I very much hope that RunRev will take a strong leadership role in managing the evolution of the canonical language.

Pros:

Cons:

Caveats:

Recommendation:

Assignment Statement

[Bill at Earthednet, Mike Kerner, Mark Wieder, Dick Kriesel, Robert Cailliau]

Bill: The main syntax annoyance I have, as a new to livecode user, is the "Put ## into myVar" syntax. …Every grade school kid understands myVar = ## syntax.

Mike: I can't disagree with x=1, as long as we are clear that if x=1 then does not mean what it would to someone in C.  I always thought the x:=1 syntax from Pascal was stupid, too. I'm used to put 1 into x, but I don't think it's actually better than x=1

Mark: In C I always write if (1==x) rather than if (x==1) to avoid that kind of trouble.

Dick: And it would be nice to put into and get from array-valued properties:

put "true" into the uPreferences[ "syntax" ][ "array-valued properties" ] of me

Robert: The early programming tutorials (1950s to 1970s!) all made a great effort to point out that myvar = ## did not mean what it appeared to mean (i.e. a test for equalit).  These manuals spent a chapter on the apparent mystery of i=i+1.  The only reason to use = was that did not exist on punch card machines.  An additional problem was then to find a notation for testing equality, whence the C-syntax of == which certainly is not nice.  There was a series of HP desktop programmable calculators (1970s) that had a gazinta symbol.  This symbol was used for assigning values to variables and it was just the .

It is more natural for humans to start a sentence with the object that is changed rather than mention it at the end.  But the compiler and the flow of execution starts with evaluating the expression first, before putting its value into the variable.

So what about:

myVar := expression

set myVar to expression

as possible alternatives.  Mike finds the Pascal/Algol/Ada syntax stupid, and I agree it is not very elegant, but it can be read as myVar: assign to it the value of expression.  I would only accept the left-pointing arrow as a true alternative, but unfortunately those arrows are difficult to type.  Let's certainly not use = !

Pros:

Cons:

Caveats:

Recommendation:

Setting Custom Properties

[Martin Koob]

Could

set the cProperty of me to 10

also be

put 10 into the cProperty of me

Pros:

Cons:

Caveats:

Recommendation:

Adopt.

Autocomplete

[Martin Koob]

Autocomplete works  on all other control structures:
on command function switch repeat try setprop getprop but doesn't work on 'if'.  Autocomplete could also be added for 'if'  so typing 'if' would autocomplete the 'end if'.

Pros:

Helps a lot, often.

Cons:

Single-line if statements now need more editing.

Caveats:

Recommendation:

Clean up the way LiveCoded finds the end of if statements.  Some nesting of ifs causes nested ifs to break.

Named Constructs

[Mike Kerner]

I always wind up adding a comment to the END part of every construct that says what it is referring to

Pros:

Cons:

Caveats:

Recommendation:

Scope of Identifiers

[Monte Goulding, Robert Cailliau, Graham Samuel]

There are other anomalies in scoping of names - do groups belong to individual cards on which the component objects reside, or to the stack as a whole? It seems that both are partly true: if you want to edit a group, you have to be looking at the card it's on, but if the group is a menu, I think it can be accessed from anywhere in the stack. This is messy, and again if it was fixed, I don't think there would be a backward compatibility problem.

Clean up scoping rules for names.

Define global constants in a stack script

Pros:

Define values only once, use everywhere.

Cons:

Still needs defining the list in all scripts that use them (like now for global variables)

Caveats:

Recommendation:

Define better the scope of identifiers across the whole application.  As scripts are linked to objects, this perhaps needs an import/export syntax, perhaps along these lines:

Some object might have this at the start of its script:

define Speedrules constant cNominalSpeed = 80 constant cMaxSpeed = 130 end define

And some other objects could then start with:

use Speedrules <rest of script>