(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 allow us to assess the quality of a proposal.
The main guidelines are:
A list of opinions:
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))
[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, …
[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.
[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)
[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.
[Roger Eller]
The text of image 1 should be "the pixels of image 1"
Pros:
—
Cons:
—
Caveats:
—
Recommendation:
Adopt.
[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.
[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:
—
[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.
[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:
—
[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:
—
[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:
—
[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:
—
[Martin Koob]
Could
set the cProperty of me to 10
also be
put 10 into the cProperty of me
Pros:
—
Cons:
—
Caveats:
—
Recommendation:
Adopt.
[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.
[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:
—
[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>