First things first. Dynamic typing is quite common in scripting languages and makes them infinitely
easier to use than 
many strongly typed languages.

Having said that, it was your prompting that got me to move to php v7 and its pseudo strict
typing, which I now much 
prefer. I hope they take the concept further.

So of itself I don't think loose typing is bad. Of course there are some interesting issues
that arise from time to 
time. Its up to the program to track, and where necessary dynamically cast variables, following
a set of in-built rules.

Moving to dynamic scoping, that I think is entirely different!

php for example is essentially FUNCTION scoped, but then there is class scoping as well (via
your much-loved 'this' and 
'self'). However a var in a function may be declared global, which access the global var.

PAL is a  funny mix. Basically everything is global, which I guess back in the day was the norm,
but then adds PRIVATES 
which, like function params, exist in that function scope, and for subsequent called functions,
until a CLOSED function 
is encountered which start the game all over but allows USEVARS vars to come from the previous
scope.

You'll notice in PAL that every global var is accessible even after the script has stopped!

So where was a var defined? How many versions of the same var name exist? Which one am I accessing
right now?

Enough of that..

Converting to function-scoped php requires a way to emulate PAL's scoping system. So I scan
every PROC declaration for 
params, PRIVATES, CLOSED, and USEVARS and find every var referenced in the PROC. There's a bit
of run-time stuff added 
to the generated php function entry and exit to track this. To bring a var into scope within
a function I store it 
globally and link to it via a reference, allowing the var name to be used as-is. Vars, and their
types, are tracked from 
one function to the next. Vars in a proc that PAL knows are accessed from the global pool are
declared at the top of the 
generated function as GLOBAL. Without digging into php internals this seems the simplest way
and seems to be working ok.

In many ways PAL and php have typing conventions, and much can be simply converted directly
without being clever. An 
exception is PAL's '+' which in php is either '+' for numerics or '.' for strings. So we need
to be type-aware to make 
the right choice. Quite often this can be figured out by context, but when stuff is coming from
a database etc you might 
not know its type at convert time. I have added an option to verify database vars against the
actual database table, but 
it may be difficult or impossible to identify the table (all those ups, downs, F3's, F4's etc
etc). So for now I am 
happy that the convert is getting it right MOST of the time, and expecting manual intervention
later. I can see it could 
be done better, but it gets complicated. In my 791KB generated php test program, I can see it
gets it wrong only a 
couple of times (that I have noticed). BTW, it takes about 4 seconds to convert and generate,
 including PAL's library 
generate.

You may notice I am ignoring date type for now. Havn't fully addressed this one, yet.

Multiple tabs are the same as multiple users. As each new client (tab or user) makes a connection
to the websocket 
server it is routed to a completely new instance of php to talk to and the app instantiated
in that instance. So they 
are completely separate. The talk between the websocket server and each instance of php is via
separate socket 
connection. Its fast. Globals are unique to each instance of php.

Finally, there may be better ways to do some or most of this, but I'm at my limit, and it seems
to be working.

BTW, you might find pal2php.php is now friendlier (see the src). The option for referencing
tables is currently in 
PalRTS.php (from memory).

- Bernie
On 13/9/18 11:21 am, Larry DiGiovanni wrote:
> Bernie van't Hof wrote:
> 
>> Looking back, it just seems ridiculous, and is generating a bit of extra work for me!
> 
> I'll bet.  Dynamic scoping is bad, but worse, or at least as bad, is that PAL variables
are also dynamically typed.
> 
> I got curious how you were approaching this, so I started digging.  It looks like you
are handling globally scoped 
> variables in $GLOBALS.  I'm not familiar with PHP variable scopes  (and I'm kinda rusty
on PAL scopes the more I think 
> about it).
> 
> As I recall, you launch the app via the command line, which starts listening on port <whatever>. 
Then you connect on 
> port <whatever> from a browser, and start running the app.
> 
> So what happens when a second browser hits port <whatever>?  Are $GLOBALS in scope
across both?
> 
> This is more a PHP variable scope question, as it relates to your application lifecycle.
> 
> -- 
> Larry DiGiovanni
>