Musings

[SeanBDurkin]

Colleagues,

Please find following, my thoughts on Jonathan's ideas.

Comments interleaved below.

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

I agree that a simple statement is sufficient to establish a scope
block. PHP does it this way.
Have a look at section 4. of page
http://www.seanbdurkin.id.au/psstiki/tiki-index.php?page=Vision+for+Pascali
The left-hand column shows the verbose way, and the right-hand column
provides a short-hand.
You can use the short-hand to not use the dummy procedure routine.

>> 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).

I can't see much of an advantage to dynamic typing. Maybe it is more
concise, but it also
increases the probablity of wrong interpretation.
For example:
var
x;
begin
x := 1;
x := x + 1
end;

What is x? It could be byte, integer or double, or even with some
creative thinking string.
The interpreter is going to make its best guess (say integer), but the
programmer
intended double and didnt realise that ambivalence was present. No
error will be
detected, but the program will behave subtly differently to
expectation. I dont think
I like dynamic typing.

>> 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.

Ok, you have convinced me. I was thinking in terms of a compiler. But
your right,
with an interpreter we can wrap pointers and operate them in a sandbox
memory unit.

>> 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).

Agreed. Just one note about strings. Unicode strings are nicer to work
with,
but most webservers and email servers have settled on a defacto
standard of
UTF-8. Since the primary problem domain is making web-server
applications,
our script developers are going to have much more insterest in UTF-8
strings
rather than ansistrings, UTF-7 or unicode (UTF-16). Unfortunately
UTF-8 has
variable bytes per character. There are either 1, 2 or in the case of
indian and chinese
4 bytes per character. Without strong in-language support, it makes
parsing
strings for characters painful work.

>> 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.

I must be missing something here! Call stack handing, IMHO, is
completely
an implementation issue. I doesnt impact on language definition at
all. Even the
issue of parameter evaluation order, can with some work, be separated
from parameter order on stacks.

>> 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:

As a delphi programmer, I really dislike variants. They have always
seemed to
me to be a kludgy inefficient failed attempt to bring polymorphism to
fundamental types.
If we wrap all our fundamental types into objects, then we dont need
variants.
Another was of looking at it, is that TObject is the ultimate variant.

>> Var myvar;

As a compromise, we could say, that the above code fragment declares
myvar to be an object of type TObject. We can still make statements
like...

myvar := 5;

which, assuming that myvar started as nil, construct an object of type
Integer and value of 5, and assign the object
reference to 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.

I see your point. Having said that, 99% of all REST API entry points
will have a fixed defined URL.

>> 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.

Agreed. In the case of a fixed known URL, the URL can be specified as
a literal string
delimited by quotes, like ...
REST MyFunction 'http://www.whatever.com' (AParam:string Get;
AnotherParam:integer Post);

or a resolve-at-parse-time, like ...
const Domain = 'www.whatever.com';
REST MyFunction 'http://' + Domain (AParam:string Get;
AnotherParam:integer Post);

or in the case of a dynamically calculated URL, like this ...
REST MyFunction (AParam:string Get; AnotherParam:integer Post);

which when invoked, the caller must supply an extra parameter, which
is the calculated URL.


Faithfully,
Sean B. Durkin