Re: My scripting language - any suggestions?

Johannes <jaluber@gmail.com>
Wed, 27 Aug 2008 03:38:53 -0700 (PDT)

          From comp.compilers

Related articles
My scripting language - any suggestions? licaner@gmail.com (lican) (2008-08-25)
Re: My scripting language - any suggestions? jaluber@gmail.com (Johannes) (2008-08-27)
Re: My scripting language - any suggestions? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-08-27)
Re: My scripting language - any suggestions? licaner@gmail.com (lican) (2008-08-29)
Re: My scripting language - any suggestions? jaluber@gmail.com (Johannes) (2008-08-30)
Re: My scripting language - any suggestions? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-08-31)
Re: My scripting language - any suggestions? ademakov@gmail.com (Aleksey Demakov) (2008-08-31)
Re: My scripting language - any suggestions? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-08-31)
[11 later articles]
| List of all articles for this month |

From: Johannes <jaluber@gmail.com>
Newsgroups: comp.compilers
Date: Wed, 27 Aug 2008 03:38:53 -0700 (PDT)
Organization: Compilers Central
References: 08-08-069
Keywords: interpreter
Posted-Date: 28 Aug 2008 10:04:31 EDT

On Aug 26, 1:41 am, lican <lica...@gmail.com> wrote:
> Anyway I'm having some
> difficulties. One small decision, should variables should be declared:
>
> [code]
> var a = 5; // or
> local a = 5; // like in lua or unreal script, or
> global a = 5; // declaration of a global variable in given scope, not
> like referencing global variables in PHP, or
> a = 5;
> [/code]


IMO, dynamic languages need to require variable declarations. I still
loathe the waste of time PHP caused because I missed a typo in a
variable name. That's something the compiler should catch. Or at least
handle unit test in a simple way like Ruby. I believe the reason typos
don't bite Ruby people so much because they discover them via unit
tests easily. Also ruby complains if you access a name which it hasn't
seen before. I can't remember what PHP does in that situation.


Regarding the way how to declare the variables: It depends on your
needs. If you plan to support proper class support you need to be able
to say which members are public, protected or private. There are two
ways: Either you put the modifier in front of each member (like Java/
C#) or you put the modifier in a separate line and say, that
everything afterwards has this modifier (like C++/Ruby). It depends to
a part on the need of proper declaration and to a part on the
aesthetics - in other words, if it looks ugly or not.


> And the second problem. What kind of scope to implement. In PHP you
> have either global or local (function) scope. So writing:
>
> [code]
> if( variable )
> {
> a = 5;
>
> }
>
> print(a);
> [/code]
>
> gives the result '5'. Something like this would mean a compiler error
> in C++. But I'm willing to implement it as per block (like in C/C++)
> scope. Anyone seeing any prons/cons?


Using scopes has the advantage to reduce the variable life time. If
you only need the variable a certain number of lines, then accessing
it later should give an error as it goes against declared intent. On
the other hand is separating declaration and assignment a tad ugly
(even if you don't use "var a", you have to put the symbol into the
symbol table somehow). Also you can shadow variables, if a declaration
before prior use is required. If you don't like that you can prevent
any total shadowing (unlike shadowing member variables which can still
be accessed via "this.a") like C# does (read its spec as it is a bit
more involved than I hinted on).


> The interpreter is a simple AST
> walking class, but when some problems are fixed I will replace it with
> a bytecode VM (like in Lua). And as for the VM itself... stack or
> register based? :)


IIRC, .NET uses stack because it makes it easier to verify bytecode.
But I haven't looked into VM design myself, so I can't say anymore on
this subject.


Johannes


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.