|Subject:||Re: Grrrr dynamic scoping in PAL
|Date:||Thu, 13 Sep 2018 21:57:49 +1000
|From:||Bernie van't Hof <email@example.com>
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
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
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
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
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).
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
> This is more a PHP variable scope question, as it relates to your application lifecycle.
> Larry DiGiovanni