The Road Ahead

[SeanBDurkin]

Colleagues,


Looking back on it, I think I made a hash of the vision pages relating
to classes and variables. The language as it envisaged it at the time
was getting too far away from Delphi. Keeping faith with the objective
of pascali being a pascal based language that will be familiar to
Delphi programmers, means I need to keep the syntax of the language,
in relation to class and variable declarations close to Delphi.

But of course, because it is an interpreted language, and because we
dont want web-hosts to fear the power of scripts to reach outide of
the authorised environment, we MUST remove from the language:
* pointers, pchars and the like;
* hard-casting
* unchecked array indexing.

I like what I have done with lists and REST functions. These
expansions to the language solve a lot of problems and are still a
good fit the for objectives. I havn't got any negative feedback on
these features, so I must be doing alright in relation to them.

So whats the plan for moving forward? How about this:
1. Formal Syntax Definition for pascali, using EBNF. Written onto
wiki pages.
2. Set-up development environment on a virtual machine(s). Document
instructions how to reproduce on a wiki page.
3. Develop proof-of-concept script engine on IIS using a dummy
script parser.
4. Promote the project as an OSS project to other Delphi mailing
lists around the world. There are about 10 English speaking ones.
5. Either customise and existing script engine or develop a new one,
as needs require.

I don't have any time-scales yet.

How about that guys? Is that a workable plan?


Faithfully,
Sean B. Durkin

[Jonathan Bishop]

Hmm actually I don't like the dummy procedure routine either. A simple
begin ...end is sufficient to establish a scope block.

We need to consider what we are doing about variable declaration.
Interpreters really do not need forced pre typing on variables. There might
be an argument for allowing dynamic typing where a variable is not
predeclared. This deals with your scoping issue that the dummy procedure
addressed, or simply allow a var declaration to (optionally) always proceed
a begin end (which might be preferable).

Also I don't have a view on pchar, but I think dropping pointers is a bad
idea as records depend on them, and classes and var params are really just
pointers anyway. In classic pascal a pointer is typed anyway. Since the
interpreter will operate in it's own sand box memory unit, I can't see why a
pointer is a problem. We can easily range check a pointer on assignment,
and treat the pointer as an offset into our own managed memory space.

Whether a pointer is a risk comes down entirely to how we implement them.

Same goes for hard-casting, but I agree about unchecked array indexing, as I
think prevention of buffer over-flows is one of the advantages in classic
pascal. Same goes for array typing which if it had been handled properly in
Delphi in the first place would have made the entire issue of Unicode to
ansi string conversions and string array indexing moot. If an array is
declared as an array of char - indexing in increments one char size in
bytes, if integer: one integer size in bytes, If ansistring one ansichar in
bytes, etc. The ability to be able to index through a string as an array
is an essential programmer's tactic - which is why everyone does it. (And
this also applies to pointers).

One of the many things we need to think about, is the function call stack
handling. Here, I think, C got it right and pascal got it wrong. In C the
stack is normally pushed from the last (right most) argument to the left
most argument, while pascal is normally pushed from the first (left most)
argument to the right. The C version makes for better stack management and
coincidentally supports indefinite argument lists well. However, pascal
programmers are probably used to relying on left to right evaluation of
procedure arguments - even if they should not.

Regards

Jonathan Bishop
Managing Director

Bishop Phillips Consulting | Melbourne, Australia - Vancouver, Canada
Mobile +61 411.404.483 | Office +61 (3) 9525.7066 | Fax +61 (3) 9525.6080
bis...@bishopphillips.com | www.bishopphillips.com

[Jonathan Bishop]

By the way - can't register on the wiki. It complains that my email can not
be verified.

[Sean Durkin]

Thanks Jonathan,

You always have something good to contribute.

I will reply to your communication on the weekend.

I heard from somewhere that someone has already made a BNF study of the
Delphi 7 syntax. If I had to make a syntax definition, this would be a
great starting point. I will search for it on the weekend, and
hopefully, I can leverage it.

Faithfully,
Sean.

[Jonathan Bishop]

KK.

Vars
-----
I missed your trick with the VAR statement in the syntax examples. That is
a good idea, and possibly preferable to the default dynamic typing idea.

We could decide a variable without a declaration assumes a default type
(maybe variant) - but we should discuss the pro's and con's of this. It
might be preferable to explicitly allow an untyped, but declared variable
which is therefore treated as a variant, eg:

Var myvar;

Rest
-----
Is it essential to have the full URL as part of the rest declaration? That
means the code in one site can not be transported to another without
recoding. I think we will regret that.

Maybe, either the URL part should be able to be defined by a variable. In
anycase, for the purposes of speed of parsing we might be wise to surround
the URL part with a symbol that is not legal in a URL - otherwise the parser
will have to parse the URL - which it won't be otherwise needing to
understand.