Talk:Modernised Pascal

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

"for" variables as "break" and "continue" labels

As fas as I know, "break" and "continue" can only influence their own "for" loop. When using nested loops (e.g. graphics programming, multi-dimensional array parsing) it can be useful to break out of the entire "for" structure. Currently this requires declaring a label or putting the code into a subroutine and using "exit". A shorter (and imo easier) way would be allowing parameters for "break" and "continue":

 for y := 0 to 2047 do
 for x := 0 to 1023 do
     if (scr[y, x] = 0) then break(y);  // with parentheses

 for y := 0 to 2047 do
 for x := 0 to 1023 do
     if (scr[y, x] < 10) then continue y;  // without parentheses

prefix for binary and hexadecimal numbers

 0b0010110  // binary via letter
 2_0010110  // binary via base

 0x01230ABC  // hexadecimal via letter
 16_01230ABC  // hexadecimal via base

braindump

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

Proposal: 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 semicolon: extensable parameters
procedure f(
  const s: string;
  x,y: integer;
  );

// 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 *)

There should be no problems concerning compatability and implementation.

--Jasper 11:45, 5 August 2010 (CEST)

Proposal: Enhanced numbers

What about better readable numbers such as 100_000 or $_1234_5678 (note the "_" signs)? A number still should be started with "$" or a digit. All occurring "_" shall simply be accepted (and ignored).

A base could be specified as well, e.g.

• 4$123 (=27)
• 2$1100 (=12)
• 36$az (=395)

These ideas are stolen from e.g. Ada.

There should be no problems concerning compatability and implementation.

--Jasper 11:45, 5 August 2010 (CEST)

Proposal: 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 "..".

--Jasper 11:45, 5 August 2010 (CEST)

Proposal: 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. The size of such type should be 0.

Example usages:

• The Windows BMP header type, i.e. the palette
• When simulating dynamic arrays
• Proper replacement of the often used "array [0..0]", see e.g. examples in Delphi's RTL

--Jasper 11:45, 5 August 2010 (CEST)

Proposal: Enhanced case for floats and open ranges

I would like to propose to enhance the case statement for floats. What is needed then is the ability to test for open ranges and half open ranges.

case float_expr of
  <2       : ;   // match all below 2
  >=2 .. <4: ;   // match 2<=x<4
  4        : ;   // match 4
  >4 .. <=6: ;   // match 4<x<=6
  8 .. 9   : ;   // match 8<=x<=9
  >9 .. 10 : ;   // match 9<x<=10
end;

In ranges the left expression should be less than the right one and therefore the first relational operator should be ">" or ">=" and the second one "<" or "<="; if the operators are absent ">=" resp. "<=" should be assumed. In Visual Basic .NET an "is" is added before the relational operator.

An alternative syntax idea could be ranges like 4<..<=6.

Jasper 14:02, 17 August 2010 (CEST)

Proposal: Explicitly discarding results

I often would like to explicitly discard a function result such as

 void my_func(x);

The usual workaround is

 my_func(x);  // using "extended syntax"

or

 dummy := my_func(x);  // dummy is not used, this gives a hint

Both workarounds are not the best way to express the intention. There should be a way to allow for the new syntax and at the same time provide a hint/warning for the workaround with the extended syntax.

There should be no problems concerning compatibility (extra switch) and implementation.

Jasper 12:18, 11 October 2010 (CEST)

Proposal: if 1 > a < 3 then ... {!}

Shouldn't this be this: if 1 < a < 3 then ... {!}

If not, i do not understand the proposal at all.

--Mischi 13:50, 11 October 2010 (CEST)