4) - that might make sense, if also applied to for, with, if, making 'begin' implicit everywhere, like it is done in Component Pascal. However it is major leap, and can be considered only in terms of implementin one more specific non-Borland mode. But personall i'd prefer implicit 'try' there :)
6) - as far as i got it, it is runtime variable initialisation, instead of compile-time one. Syntactic sugar of doubtful quality. I would say that may make sense together with 5), modifiyng with to make shortcuts to some subclasses, record members, whatever.
with Addr = DataSet1.FieldByName['Address'], Phone=DataSet1.Field['Telephone'].AsInteger do begin Addr.Value := Addr.Value + #13#10 + IntToStr(Phone) end;
Hence, turning with into bi-modal operator, like FROM clause in SQL SELECT, ehich can settle default table without alias and other tables with aliases.
However this a major change in compiler, and cons and pros are not clear. - '=' looks absoletely not Pascal-style here, replaccing it with 'is' is even worse, brand new keyword like "beeing" ? Pascal is to be small language, even is not as small as Component Pascal :) - Compiler would have hard time to decide what to stor in aliases: cached value read-only, pointer to original variable, pointer to some object returned by some function, make inline substitution or whatever. + Programmer is no more needed to settle teporary variables, and would never change or Dispose it by mistake. + Programmer have easy way to avoid multiple expensive functions calls, like .FieldByName is. However it would be not making new initialized variables, but rather an aliases to exisiting ones.
......... i tried to giggle here, but later decided to go main page :)
- It should be disallowed to call the constructor from an instace! Or it should have no result when calling from instance.
- "Abstract class" declaration like Java.
- "final" AKA "readonly" variables, a la Java and .Net.
- "final" methods and classes which cannot be overriden or extended, respectively, like in Java.
- "Removal of begin"? Nice :) The only interesting thing in VB (of course done badly :-/ ) is having a different block terminator for each block "type". I guess it would be nice to have these and implicit blocks in all conditionals and loops.
- Non-reusable variables. Most of the time you don't need and you don't want to assign unrelated values to a variable repeatedly (i.e. you only need to use ':=' once on it), just Inc, Dec, use in for loop, etc. To be allowed to reassign a variable it should have to be declared with a special directive.
whats the point of elseif
in a block based language like pascal? Plugwash 21:59, 4 June 2006 (CEST)
Optional trailing separators and empty lists
In many cases it makes sense to allow an additional trailing separator as well as allowing for empty lists, especially when dealing with conditional compilation. As an additional benefit it makes it easier to move around lines of code.
Here are some (more or less stupid) examples:
// no hazzle with the last comma, empty uses (if neither x1 nor x2 defined) uses (*$ifdef a *) unit_a, (*$endif *) (*$ifdef b *) unit_b, (*$endif *) ;
// empty case statement (if neither x1 nor x2 defined) case expr of (*$ifdef x1 *) 1: write('x1'); (*$endif *) (*$ifdef x2 *) 2: write('x2'); (*$endif *) end;
// no hazzle with the last comma: extensable sets / arrays function_call([ 1, 2, ]);
// no hazzle with the last comma: extensable parameters writeln( var_1, var_2, );
// empty type list (if neither x1 nor x2 defined); in some cases types must be in one block type (*$ifdef x1 *) t1=integer; (*$endif *) (*$ifdef x2 *) t2=integer; (*$endif *)
What about better readable numbers such as 100_000 or $_1234_5678 ? This idea is stolen from e.g. Ada.
A base could be specified as well, e.g. 4$123 (=27) or 2$1100 (=12).
Enhanced case of string
The currently realized string-case allows for ranges which is nice but IMHO not really needed. What I need sometimes is matching string beginnings. A more or less stupid idea for the syntax could be:
case str_expr of 'match'.. :; // match all strings beginning with 'match' end;
However probably the parser needs to be changed to accept the missing second argument of '..'.
Half open array definitions
What about arrays with an unspecified upper bound such as this?:
type ta_byte = array [0..] of byte;
No bounds checking should occur on such array accesses. Furthermore incrementing a pointer to such a type could increment it by the size of the base type (in this case 1).