Original SCI syntax

[lskovlun]

I haven't posted it on-line because it is really only for investigative purposes, and it does not belong in the main tree (or as a formal patch).
I imagined we would take care of things on IRC, though I must admit I'm not entirely clear on what the next step is after trying this code.
What it does is it clears the underBits of all cast members during DrawPic... SSCI does not do that, so if this patch helps, that would indicate
a tricky bug somewhere in our graphics system.

[lance.ewing]

This is part of script 325 in PQ SWAT (I have been searching in vain for this as well...) - 40 lines out of roughly 4kloc according to the embedded line number info in the script.
So a short piece of code indeed. It seems quite plausible that it is from some kind of paper publication, and scanned in by whoever posted it in the first place - there are typos in the code that look like the errors OCR software would make (setloop instead of setLoop, setcel instead of setCel, etc.)
There are also arguments against that, however: I can see that the code is unfinished in places (compared to the version of the game that I have), indicating that the
game may have been a work in progress at the time this was leaked. This would make it less likely to be an official publication, right?

Thanks Omer, for finding this!
(btw, I came up with a small piece of code to test that sq5 issue of yours - but you haven't been back to the ScummVM forum for a long time)

Hi Lars. I was trying to track you down a few days ago. I tried emailing but not sure if I got the right email address. Is it still the one on your profile page on this site?

[lskovlun]

Hi Lars. I was trying to track you down a few days ago. I tried emailing but not sure if I got the right email address. Is it still the one on your profile page on this site?

Hmm... *checks* no, it's not... *fixes* done.
Should be good now.

[troflip]

Resurrecting this old thread...

I took a look at the PQ Swat syntax snippet a bit today:

Code: [Select]

(instance hitNineShot of Script

   (method (changestate newstate)

      (switchto (= state newState)
         (
            (theGame handsOff
            (qualProd dispose:,delete:)
            (messager say: ALL ALL QUAL-HIT-9-C ALL self 320)
         )

         (
            (++ nineShotCntr)
            (qualList dispose:)
            (target1 dispose:)
            (messager say: ALL ALL QUAL-RELOAD-9-C ALL self 320)
         )

         (
            (if (== nineShotCntr 9)             
               (Bset fQualifiedSniper)
               (curroom newroom: ANGELES-TABLES)
            else
               (targetl
                  view:    3329,
                  setloop: 2,              ;One inch target
                  setcel:  0,
                  posn:    495 370,
                  setPri:  470,
                  init: ((snipeplane casts?) at: 0)ftrlnitializer,
               )
               (= qualList (List new:))
               (qualProd setReal: qualprod 6)
               (theGame hands0n:)
               (self dispose:)
            )
         )
      )
   )

) ;hitNineShot

I know there are some typos in there, and there were a couple of things that left me with questions. I found a copy of Swat and compared the disassembly (using SCI Viewer) with the script snippet and found a few answers.

One question I had was the syntax in this line:

Code: [Select]

             (Bset fQualifiedSniper)

There's no selector colon after like the other statements. It turns out this is a procedure call, so that makes sense (that might be obvious to those familiar with smalltalk too?). Basically it's the equivalent of Bset(fQualifiedSniper) in current SCI Studio syntax.

The other mystery to me was this line:

Code: [Select]

init: ((snipeplane casts?) at: 0)ftrlnitializer,

What on earth is the question mark? From looking at the disassembly, I think this must just be a typo, and should actually be a colon. It's calling the "casts" selector on snipeplane with no arguments. That returns an object (presumably a list), on which we call the "at" selector with a single parameter 0. The result of that is the first argument to init: Then ftrInitializer is the second. So the SCI Studio equivalent is:

Code: [Select]

init( (send (snipeplane:casts()):at(0)) ftrInitializer)


[troflip]

Another tidbit:

It seems the original language supported a do-until construct (instead of, or in addition to, the do-while construct that Brian's language implements), since I see this pattern:

A: a bunch of instructions
    bt B    // branch to B if true
    jmp A   // jump back to A otherwise...
B: more code...

[MusicallyInspired]

Fascinating...it's too bad that there was no one else with the knowhow and interest to delve into SCI other than Brian. I can't help but imagine how much more we could have had much earlier. Can't blame him for losing the will, though.

[troflip]

Some more things I found out using the "write cast to file" and "path writer " functionality built into QFG2.

Write cast to file produced output like this:

Code: [Select]

(instance gate of Actor
(properties
view 290
loop 0
cel 0
palette 1
x 134
y 132
priority 7
signal (| fixPriOn ignrAct notUpd)
)
)
You'll note that the value for signal uses a bitwise-OR operator, and provides three values. So the original syntax supported operators that works on an arbitrary number of values. This is a LISP-like thing. Neither SCI Studio or SCI Companion handle this properly.

The above also provides us with some of the names of the constants that were used (fixPriOn, etc...). Not particularly important.


Using the polygon writer, I generated this file:

Code: [Select]

;** Path points for picture #100

(local
pts1 = [21 157 89 158 93 165 91 174 80 177 61 179 41 179 18 171]
pts2 = [92 137 95 123 161 116 169 129 149 142 100 142]
pts3 = [131 132 181 154 208 129 167 99 94 103 46 128 104 152 134 159]
pts4 = [159 161 198 150 203 137 177 130]
pts5 = [145 152 114 155 85 150 92 137 128 142]
pts6 = [218 134 131 132 129 104 199 131)

;** The following belongs in the room's init:

(poly1 points: @pts1, size: 8)
(poly2 points: @pts2, size: 6)
(poly3 points: @pts3, size: 8)
(poly4 points: @pts4, size: 4)
(poly5 points: @pts5, size: 5)
(self
addObstacle:
poly1 poly2 poly3 poly4 poly5
)

;** Necessary objects:

(instance poly1 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly2 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly3 of Polygon
(properties
type: PTotalAccess
)
)
(instance poly4 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly5 of Polygon
(properties
type: PNearestAccess
)
)


The main thing here is the array syntax, which is different from the one Brian invented for SCI Studio. Otherwise, I don't think there is anything new. It confirms the pointer syntax Brian used ('@'), and that comments were done with ';'.


Here's another for editing a "freeway" path, whatever that is.

Code: [Select]

;** Path points for picture #100

(local
ePData = [2 0 0  0
  (| PATHSTART SLICK ACTIVE 162) 146 ;** path#0
  208 137
  194 159
  146 163
  111 153
  145 (| PATHEND 147)

  (| PATHSTART SLICK ACTIVE 172) 154 ;** path#1
  184 133
  189 149
  201 157
  199 (| PATHEND 129)

  0
]
)
Like the first snippet, it shows that you can use expressions in constants. Neither SCIStudio or SCI Companion let you use a '|' operator to initialize arrays or properties.

I managed in activating the feature writer in LSL6 too, and output this:

Code: [Select]

(instance gregory of Actor
(properties
x 118
y 120
z 8
heading 0
  view 200
loop 0
cel 0
  sightAngle 40
  approachX 118
approachY 112
approachDist 55
_approachVerbs $0
  noun eat
)
  (method (doVerb theVerb)
(switch theVerb
  (else
(super doVerb: theVerb)
)
)
)
)

There's a couple things of note here. The PQ SWAT code had a "switchto" statement, and but here we have a "switch" statement. It's possible they changed the name of the statement by the time SCI32 came along, or it's possible they do different things. In the PQ SWAT code, there were no "case" values for the switchto statement... they were implied (0, 1, 2 ,3 ,etc...). So perhaps switchto just automatically numbered cases, while switch requires explicit cases (we can't tell from the above code, because filling in the doVerb method is left to the programmer).

One other thing to note is the else clause in the switch statement. This suggests that the "default" clause is called "else".

[lance.ewing]

Code: [Select]

init: ((snipeplane casts?) at: 0)ftrlnitializer,

What on earth is the question mark? From looking at the disassembly, I think this must just be a typo, and should actually be a colon. It's calling the "casts" selector on snipeplane with no arguments. That returns an object (presumably a list), on which we call the "at" selector with a single parameter 0. The result of that is the first argument to init: Then ftrInitializer is the second. So the SCI Studio equivalent is:

I think the ? might have been used specifically in the context of requesting the value of a property. I agreed that it seems redundant though and that : could have been used in its place. In fact it doesn't really need either, does it? In Smalltalk syntax, the colon wouldn't have been required (apparently). Read here:

http://www.smalltalk.org/articles/article_20040917_a1.html

"When "getting" a parameter value from an object one simply uses a keyword without the parameter (and colon)."

[troflip]

Hmm, interesting, that could be. It looks like, in all the code segments we have (PQ swat, and the feature/poly writer), there is only one place that retrieves a property, and it's that place with the question mark.

So a method call would always have a colon, as would a property set. But a property retrieve would be a ?.

So does this seem right?

Code: [Select]

(gEgo posn: 35 105) ; set ego position
(gEgo dispose:) ; dispose of ego
(= myVar (gEgo x?)) ; assign ego's x to my var
(gEgo x: 5) ; set ego's x to 5 directly
(gEgo x:) ; this would be a syntax error because x is a property on ego, not a method on ego


Have you given any thought to how handle when selectors themselves are used as arguments/variables? This is the # syntax in SCIStudio:

Code: [Select]

(self:eachElementDo(#init))

Smalltalk, from what I can tell, uses the # syntax to do that also. So in "original SCI", it would look like:

Code: [Select]

(self eachElementDo: #init someInitParams)

The problem is what does this look like on the receiving end in the eachElementDo method? The method definition isn't a problem:

Code: [Select]

(method (eachElementDo aSelector sendParams)

But I'm wondering what the syntax to use the "aSelector" parameter would look like. SCIStudio just uses it directly, but it seems kind of ambiguous. Essentially what it does is this (in "original SCI"-equivalent):

Code: [Select]

     (nodeVal aSelector: sendParams)

The problem comes when you have an actual selector that has the same name as the parameter (e.g. x). Smalltalk would use something like "nodeVal perform: aSelector" (from what I can tell), but "perform" is actually already a selector in SCI which has a different use.  I guess I could make up a new keyword? Objective-c has a special "performSelector:" for this.

[lance.ewing]

So does this seem right?

Code: [Select]

(gEgo posn: 35 105) ; set ego position
(gEgo dispose:) ; dispose of ego
(= myVar (gEgo x?)) ; assign ego's x to my var
(gEgo x: 5) ; set ego's x to 5 directly
(gEgo x:) ; this would be a syntax error because x is a property on ego, not a method on ego


Hard to say on the final example, but  for the first four, that looks right to me.

Have you given any thought to how handle when selectors themselves are used as arguments/variables? This is the # syntax in SCIStudio:

Code: [Select]

(self:eachElementDo(#init))

Smalltalk, from what I can tell, uses the # syntax to do that also. So in "original SCI", it would look like:

Code: [Select]

(self eachElementDo: #init someInitParams)


I hadn't really looked at scenarios like that previously. But after reading your question, I did a bit of Google searching on Smalltalk, and also skimming through the Smalltalk blue book, and I have a feeling that you're probably right. From what I can tell, the #init type of syntax is known as a Literal Symbol, or Symbol Literal, or more specifically a "Selector Literal". This particular wikipedia page is what sold me on the correctness of the syntax:

http://en.wikipedia.org/wiki/Symbol_(programming)#Examples_4

where it has this example:

Code: [Select]

" same as 'foo' at: 2 "
'foo' perform: #at: with: 2 " => $o "

I'm guessing you might have found the same wiki page given what you go on to discuss in the bit below.

The problem is what does this look like on the receiving end in the eachElementDo method? The method definition isn't a problem:

Code: [Select]

(method (eachElementDo aSelector sendParams)

But I'm wondering what the syntax to use the "aSelector" parameter would look like. SCIStudio just uses it directly, but it seems kind of ambiguous. Essentially what it does is this (in "original SCI"-equivalent):

Code: [Select]

     (nodeVal aSelector: sendParams)

The problem comes when you have an actual selector that has the same name as the parameter (e.g. x). Smalltalk would use something like "nodeVal perform: aSelector" (from what I can tell), but "perform" is actually already a selector in SCI which has a different use.  I guess I could make up a new keyword? Objective-c has a special "performSelector:" for this.

Yeah, I can see the problem. I don't actually know much about Smalltalk, other than what I've been specifically searching for examples of. Have you found any examples of it passing such a "selector literal" to a method? And then using it? I haven't yet set aside the time to work out how a method would be defined in Smalltalk. I learnt Objective-C about 20 years ago, but having not used it since, all of that knowledge has gone. - I really should read that Smalltalk blue book from the start and get a proper understanding of it. Obviously Sierra were designing a new language, so would have been picking up ideas that they liked potentially from several different languages that existed at the time, and like what you're contemplating, they may also have come up with their own thing for such a scenario, particularly given the clash with the "perform" method they'd already defined for different purpose. - So as you say, it's a choice of either going with the SCI Studio syntax, or with your own thing. I doubt though that they would have used performSelector: as a syntax if that particular selector name is not in the selector vocab resource (VOCAB.997)., which I don' t think it is.

[troflip]

So as you say, it's a choice of either going with the SCI Studio syntax, or with your own thing. I doubt though that they would have used performSelector: as a syntax if that particular selector name is not in the selector vocab resource (VOCAB.997)., which I don' t think it is.

Yeah, it feels a bit out of place to have a special keyword selector.

What's your opinion on the syntax of switch and switchto statements? From the PQ SWAT code, it's clear they had implied case values (useful for changeStates, where you are often inserting and removing cases, so you don't need to update the case values).

Assuming they use LISP-style syntax for regular switch statements, a switch statement would have cases whose first expression is the case value (i.e. no case keyword is used):

Code: [Select]

(method (handleEvent pEvent)
    (switch (pEvent type?)
        (evKEYBOARD
             Print("keyboard")
        )
        (evJOYSTICK
             Print("joystick")
        )
        (else
             Print("something else")
        )
    )
)

This would make it impossible to distinguish implied cases vs explicit cases, hence necessitating a different kind of switch statement for that... this "switchto".

The alternative is to assume switch/switchto are actually the same thing, and a case statement can optionally start with a "case [expression]", or something else, in which case the case value is implied from the previous one (e.g. previous one plus one).

And then there's another question: did they allow "fall throughs" from one case to the next? Brian's SCIStudio syntax doesn't. I suppose it will become obvious once I decompile some more scripts and encounter that pattern.

[lskovlun]

What's your opinion on the syntax of switch and switchto statements?

I think I would have preferred an extra keyword (say, next) and then say

Code: [Select]

(switch
  (next (...))
  (next (...))
  (next (...))
)
but next was already taken as an identifier by the time switchto came into being.

[troflip]

You mean next was already a selector that was being used in existing code, right?

I suppose switchto might have been a later addition to the SCI language then.

[lance.ewing]

This would make it impossible to distinguish implied cases vs explicit cases, hence necessitating a different kind of switch statement for that... this "switchto".

The alternative is to assume switch/switchto are actually the same thing, and a case statement can optionally start with a "case [expression]", or something else, in which case the case value is implied from the previous one (e.g. previous one plus one).

And then there's another question: did they allow "fall throughs" from one case to the next? Brian's SCIStudio syntax doesn't. I suppose it will become obvious once I decompile some more scripts and encounter that pattern.

Yeah, I think the name switchto feels more like it was a later addition, as you were also suggesting in your most recent post. For switchto, it does indeed appear that the "case" value is implied, and I'm assuming therefore that the implied values are 0, 1, 2, etc.

Regarding your alternative that the one keyword might have supported both implied and explicit, it seems unlikely to me. The name "Switch To" suggests to me that it is saying "switch to this position" rather that switching to the block whose expression value matches. If that is what switchto implies, then it doesn't cater for a more flexible type of switch, which suggests the existence of the more common form.

But why did they choose to support switchto? Just to save typing in a few digits? I'm guessing that this pattern became so common that they decided to simplify it, ever so slightly.

Your example of the standard switch, where it has an expression as the first value of each block, looks good for that type of switch.

I don't think they would have supported fall throughs using such a syntax. If it does align with a LISP-like switch, then I don't think they'd be let in to a block of code unless the expression matched.

The only bit from your example that looks out of place to me are the Print calls. Something like Print("keyword") should be (Print "keyboard"), to be consistent with the Bset example from the SWAT code that you identified as a procedure call. If you think about it a bit, even examples such as (++ counter) or (+ 2 3) are procedure calls. Anything that is a procedure call, rather than a method call, is likely to follow the same syntax.

[lskovlun]

But why did they choose to support switchto? Just to save typing in a few digits? I'm guessing that this pattern became so common that they decided to simplify it, ever so slightly.

I wouldn't call it a "slight" simplification. If you had designed a large state machine, you would almost certainly have to name the states (if nothing else, to keep the numbers in one place for easy reference). In the cases where you don't need to reference the states explicitly, switchto permits you to skip this step. This makes maintenance (adding and removing things) easier.