New sections to the Standard Pascal website
Scott Moore
* *
* THE STANDARD PASCAL WEB PAGE *
* *
* http://www.standardpascal.org *
* *
{**********************************************************************}
The Standard Pascal web site has been extensively updated. It has the
following new items:
* The CDC 6000 compiler page, containing the source and documents for
The original Pascal compiler at ETH Zurich, has been extensively
updated. It now includes source for the 1972 unrevised compiler, the
first compiler Wirth created for Pascal, as well as the source and
documents for the last CDC 6000 series compiler, the 1984 compiler
modified by the University Minnesota for ISO 7185 standards
compliance.
* The P5 compiler project was added in beta version. The P5 compiler is
the P4 compiler updated to include full Pascal, as well as updated
to compile all features of the ISO 7185 language.
This site is the only web site specifically devoted to the J&W and ISO
7185 versions of the Pascal language (the original Pascal language).
The features you will find on the site are:
* A list of available ISO 7185 Pascal implementations available for your
use.
* The ISO 7185 Pascal FAQ, including
+ What is ISO 7185 Pascal ?
+ The history of Pascal.
+ Status of standards.
+ Difference between several nonstandard implementations such
as Borland, Delphi, and Apple with the standard.
+ What subset of Pascal is acceptable to ALL implementations,
even non-standard ones.
+ Can standard Pascal be crashed ?
+ How to perform strings in standard Pascal.
+ How to perform a "type cast" in standard Pascal (yes, really).
+ What is the extended Pascal standard.
* A complete overview of the rules and working of ISO 7185 Pascal.
* History and BIO on Niklaus Wirth, Pascal's originator.
* The complete standards documents, including the ISO 7185 standard.
* A collection of ISO 7185 Pascal compatible programs, including:
+ Pascal-s, a compiler/interpreter for a Pascal subset.
+ P4 compiler/interpreter, the same one UCSD was based on.
+ P5 compiler/interpreter, P4 brought up to the ISO 7185 standard.
+ Pretty printer.
+ Basic-s, a tiny basic intepreter.
* The Yacc and Flex parsing grammar for ISO 7185 (for people building
Pascal compilers as a student project).
* Information on the original CDC 6400 working basis of Pascal,
including source code to the early compiler implementations.
* The complete scans of the original PUG or Pascal Users' Group
newsletters. This includes a huge amount of the original history of
Pascal.
thomas...@gmx.at
What about the 'otherwise' or 'else' clause of 'case'
statements. I neither found it in your P5 nor in the FAQ.
I consider this one of the most important extensions of
Pascal. Do you want to extend the P5 with 'otherwise' or
'else' clauses for 'case' statements?
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Scott Moore
>> + P5 compiler/interpreter, P4 brought up to the ISO 7185 standard.
> What about the 'otherwise' or 'else' clause of 'case'
> statements. I neither found it in your P5 nor in the FAQ.
> I consider this one of the most important extensions of
> Pascal. Do you want to extend the P5 with 'otherwise' or
> 'else' clauses for 'case' statements?
>
> Greetings Thomas Mertes
>
Good question. The P5 compiler is P4 brought up to the original pascal
language standard or ISO 7185. It never had a otherwise or else clause
for a case statement (nor did p4). This was a common later extention.
Scott Moore
thomas...@gmx.at
Pascal 6000 which predates P4 already had an 'otherwise'
clause. IMHO it was a big mistake to omit it in the P4
compiler and in the ISO 7185 standard. Do you plan to
add 'otherwise'/'else' to the P5? Since I switched
from Pascal to C in the early 90s, I am not sure if
modern Pascals prefer 'otherwise' or 'else' for 'case'
statements.
BTW.: Under which license is the P5 released?
GPL would be great.
Would there be a conflict the public domain P4 and the GPL?
Scott Moore
>
> Pascal 6000 which predates P4 already had an 'otherwise'
> clause. IMHO it was a big mistake to omit it in the P4
> compiler and in the ISO 7185 standard. Do you plan to
> add 'otherwise'/'else' to the P5? Since I switched
> from Pascal to C in the early 90s, I am not sure if
> modern Pascals prefer 'otherwise' or 'else' for 'case'
> statements.
Yes, it was (the otherwise) an extension that was local
to the University of Minnesota version.
Remember that the P4 compiler was designed in the 1970's
by Wirth's students in Zurich, and was not designed to implement
the entire Pascal language as it existed at that time, it was
deliberately subsetted.
I have considered P4 to be a historical item. There are actually
a lot of copies running around the net, as you have seen in
this thread (Steve pemberton has a copy, so does the CDC 6000
history group). I updated it to be ->source<- compliant with
ISO 7185 because otherwise, I wouldn't be able to compile it,
since I don't use a CDC compiler from the 1970s (even the 1984
CDC 6000 compiler would have refused to compile it in the
original form). Of course it would be useful to also have
a more modern, updated P4, which I did, and called it P5.
Now, lets go over my plans for P5 (and beyond), then lets
go over yours :-)
1. P5 was P4 brought up to accept ISO 7185 as well as to be
written in ISO 7185. Basically ISO 7185 is the 1970's Pascal,
with clarifications made by the Pascal standards committees.
It is P4 with the "subsetting" removed.
2. I agree that P5 should go further, such as extended
constructs. I would tend to call that P6 or more (p7, p8, etc).
Of course, its according to time permitting.
How about your plans? Its really up to you if you want to go
to town adding new constructs. That's what Wirth wanted when
he (they) issued the P4 kit.
So I would say, if you want an otherwise clause, that would
be a good starting place for you to get used to
changing/extending the compiler!
Remember that Steve Pembertons description of the P4 compiler
is online, and so are other original documents on it written
back in the 1970s (see the
http://www.standardpascal.org/documents.html section on the
website).
P5 adds new SC (Stack Computer) operation codes, but the changes
are well documented in the source, so the P4 documentation plus
the source will be adequate. I also hope to produce more
supporting documents for the P5 compiler in the near future.
>
> BTW.: Under which license is the P5 released?
> GPL would be great.
> Would there be a conflict the public domain P4 and the GPL?
>
> Greetings Thomas Mertes
I don't see any. Public domain is a centuries old concept, and
the P4 compiler has been public domain since the 1970s (since
it was created).
Of course, it is debatable what GPLing a public domain software
means, since anyone can take the old, public domain version of
the P4 compiler and do whatever they want with it, without
regard to the GPL.
It seems to me that what you would be effectively doing by
taking a P4 or P5 compiler, changing it and GPLing that, would
be that nobody could use your version of the compiler without
obeying the GPL.
In the immortal words of Billy Crystal, "yee hah", have fun with
the code.
Scott Moore
thomas...@gmx.at
> thomas.mer...@gmx.at wrote:
>
> > Pascal 6000 which predates P4 already had an 'otherwise'
> > clause. IMHO it was a big mistake to omit it in the P4
> > compiler and in the ISO 7185 standard. Do you plan to
> > add 'otherwise'/'else' to the P5? Since I switched
> > from Pascal to C in the early 90s, I am not sure if
> > modern Pascals prefer 'otherwise' or 'else' for 'case'
> > statements.
>
> Yes, it was (the otherwise) an extension that was local
> to the University of Minnesota version.
>
> Remember that the P4 compiler was designed in the 1970's
> by Wirth's students in Zurich, and was not designed to implement
> the entire Pascal language as it existed at that time, it was
> deliberately subsetted.
>
> I have considered P4 to be a historical item. There are actually
> a lot of copies running around the net, as you have seen in
> this thread (Steve pemberton has a copy, so does the CDC 6000
> history group). I updated it to be ->source<- compliant with
> ISO 7185 because otherwise, I wouldn't be able to compile it,
> since I don't use a CDC compiler from the 1970s (even the 1984
> CDC 6000 compiler would have refused to compile it in the
> original form).
In the middle of the 80s a friend an I copied the P4 from the Book
"Pascal Implementation" from S.Pemberton / M.C.Daniels. We used a
CDC Cyber and therefore we only used upper case characters. Our
p4.pas was identical to the book. Our p4r4.pas had the changes
necessary to compile it with the Pascal-6000 Compiler. Later I
created also a p4t.pas for Turbo Pascal. Recently I created a
p4g.pas which can be compiled with the gpc. All of them are written
in upper case characters. An attempt to use the P4 as basis for a
Seed7 compiler at the beginning of the 90s failed (at that time I
did not use the name Seed7). The development of the current Seed7
interpreter (hi) started as Pascal program with no relationship to
the P4. Later I switched to C. So the current Seed7 implementation
does not use Pascal.
For Pascal programmers Seed7 programs will look very familiar.
Seed7 tries to take over some of the Pascal philosophy.
> Of course it would be useful to also have
> a more modern, updated P4, which I did, and called it P5.
>
> Now, lets go over my plans for P5 (and beyond), then lets
> go over yours :-)
>
> 1. P5 was P4 brought up to accept ISO 7185 as well as to be
> written in ISO 7185. Basically ISO 7185 is the 1970's Pascal,
> with clarifications made by the Pascal standards committees.
> It is P4 with the "subsetting" removed.
>
> 2. I agree that P5 should go further, such as extended
> constructs. I would tend to call that P6 or more (p7, p8, etc).
> Of course, its according to time permitting.
>
> How about your plans? Its really up to you if you want to go
> to town adding new constructs. That's what Wirth wanted when
> he (they) issued the P4 kit.
>
> So I would say, if you want an otherwise clause, that would
> be a good starting place for you to get used to
> changing/extending the compiler!
At this place I should explain my plans.
I started to rewrite the P4 in Seed7. The reason I do this, is to
show what can be done with Seed7. There are also other Seed7 example
programs like a Basic interpreter and other stuff. The Seed7 version
of the P4 is already capable to compile the original P4. The
resulting P-Code is identical to the one that the GPC version of the
P4 creates when the original P4 is compiled. There are still things
to be done, so it will take some time unil I can release the p4.sd7.
An improved version of p4.sd7 could be called p7.sd7 (A name which I
plan to use to reflect that it is a P4 written in Seed7). Such an
improved p7.sd7 could support ISO 7185 and other extensions like
'otherwise' clauses. Since I use most of my energy/time to improve
Seed7 I am interested to reuse your impovements of the P4. I asked
for the GPL because I release all my code under the GPL (and the
LGPL for libraries).
> Remember that Steve Pembertons description of the P4 compiler
> is online, and so are other original documents on it written
> back in the 1970s (see the
> http://www.standardpascal.org/documents.htmlsection on the
> website).
>
> P5 adds new SC (Stack Computer) operation codes, but the changes
> are well documented in the source, so the P4 documentation plus
> the source will be adequate. I also hope to produce more
> supporting documents for the P5 compiler in the near future.
I look forward for that.
> > BTW.: Under which license is the P5 released?
> > GPL would be great.
> > Would there be a conflict the public domain P4 and the GPL?
>
> > Greetings Thomas Mertes
>
> I don't see any. Public domain is a centuries old concept, and
> the P4 compiler has been public domain since the 1970s (since
> it was created).
>
> Of course, it is debatable what GPLing a public domain software
> means, since anyone can take the old, public domain version of
> the P4 compiler and do whatever they want with it, without
> regard to the GPL.
>
> It seems to me that what you would be effectively doing by
> taking a P4 or P5 compiler, changing it and GPLing that, would
> be that nobody could use your version of the compiler without
> obeying the GPL.
Since I release all my programs under the GPL this is okay for me.
Marco van de Voort
> Of course, it is debatable what GPLing a public domain software
> means, since anyone can take the old, public domain version of
> the P4 compiler and do whatever they want with it, without
> regard to the GPL.
Agree fully.
> It seems to me that what you would be effectively doing by
> taking a P4 or P5 compiler, changing it and GPLing that, would
> be that nobody could use your version of the compiler without
> obeying the GPL.
While I totally agree with you that slapping GPL on each and everything is
unnecessary, it is more the recycling of the compiler source than using it
that is limited by the GPL.
thomas...@gmx.at
As I explained in the another mail. I plan to release a
Seed7 version of the P4 under the GPL. For this version
(or a later improved Seed7 version of the P4) it would
be interesting to take extensions from other sources.
Therefore I asked for the GPL compatibility.
BTW.: Seed7 is my attempt to improve the ideas of Pascal.
Seed7 programs look familiar for Pascal programmers.
The compilation of Seed7 is not possible with the technic
used by the P4. Seed7 allows user defined statements,
operators and abstract data types. Therefore a hardcoded
parsing like in the Pascal compilers is not possible.
Instead I use a table driven LL(1) algorithm to parse.
I am not iterested to do a Seed7 version of the P4 to
learn compiler construction, but to give a Seed7 example
of how a Pascal compiler works. So for me it is an
iteresting test case and I plan to add the p4.sd7 to the
Seed7 package and to the Homepage, when it is finished.
The final polishing will take some time, so don't hold
your breath.
Marco van de Voort
>> While I totally agree with you that slapping GPL on each and everything is
>> unnecessary, it is more the recycling of the compiler source than using it
>> that is limited by the GPL.
>
> As I explained in the another mail. I plan to release a
> Seed7 version of the P4 under the GPL. For this version
> (or a later improved Seed7 version of the P4) it would
> be interesting to take extensions from other sources.
> Therefore I asked for the GPL compatibility.
PD or BSD is already GPL compatible, and not as restrictive as GPL.
> BTW.: Seed7 is my attempt to improve the ideas of Pascal.
> Seed7 programs look familiar for Pascal programmers.
I'm not interested in Seed. I've seen all arguments in comp.lang.misc
already, and decided it doesn't solve any problems that I have.
Ivan Levashew
> BTW.: Seed7 is my attempt to improve the ideas of Pascal.
> Seed7 programs look familiar for Pascal programmers.
programmers.
--
If you want to get to the top, you have to start at the bottom
Scott Moore
> In the middle of the 80s a friend an I copied the P4 from the Book
> "Pascal Implementation" from S.Pemberton / M.C.Daniels. We used a
> CDC Cyber and therefore we only used upper case characters. Our
> p4.pas was identical to the book. Our p4r4.pas had the changes
> necessary to compile it with the Pascal-6000 Compiler. Later I
> created also a p4t.pas for Turbo Pascal. Recently I created a
> p4g.pas which can be compiled with the gpc. All of them are written
> in upper case characters. An attempt to use the P4 as basis for a
> Seed7 compiler at the beginning of the 90s failed (at that time I
> did not use the name Seed7). The development of the current Seed7
> interpreter (hi) started as Pascal program with no relationship to
> the P4. Later I switched to C. So the current Seed7 implementation
> does not use Pascal.
>
Well, good luck. Thats my main idea with P4/P5, letting people get
to use it/change it as they see fit.
Scott Moore
thomas...@gmx.at
Just curious.
Whad do you expect from a programming language?
What problems do you have that need solving?
Marco van de Voort
>> On 2008-04-28, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>>
>> >> While I totally agree with you that slapping GPL on each and everything is
>> >> unnecessary, it is more the recycling of the compiler source than using it
>> >> that is limited by the GPL.
>>
>> > As I explained in the another mail. I plan to release a
>> > Seed7 version of the P4 under the GPL. For this version
>> > (or a later improved Seed7 version of the P4) it would
>> > be interesting to take extensions from other sources.
>> > Therefore I asked for the GPL compatibility.
>>
>> PD or BSD is already GPL compatible, and not as restrictive as GPL.
>>
>> > BTW.: Seed7 is my attempt to improve the ideas of Pascal.
>> > Seed7 programs look familiar for Pascal programmers.
>>
>> I'm not interested in Seed. I've seen all arguments in comp.lang.misc
>> already, and decided it doesn't solve any problems that I have.
>
> Just curious.
> Whad do you expect from a programming language?
Well, primary not just language, but development system, community and in
general a somewhat healthy ecosystem.
From the language, I'd say make large applications with a minimal overall effort.
A small additional requirment is a GUI system that works easy, is powerful,
but doesn't force a too rigid structure.
In general that means a compromise between debugging and language safety.
> What problems do you have that need solving?
My main problems involve threading. However not the base primitives, but
actually splitting out algorithms over multiple cores.
Fix that, and more people than just me will be interested.
Scott Moore
Sounds a lot like IP Pascal :-)
Scott Moore
Marco van de Voort
>>
>> My main problems involve threading. However not the base primitives, but
>> actually splitting out algorithms over multiple cores.
>>
>> Fix that, and more people than just me will be interested.
>
> Sounds a lot like IP Pascal :-)
Can you give an example? My interests mostly stem from the fact that for non
trivially paralellizable tasks, I manually have to program merging the
datastructures.
And the trade is one of the few where a bit of performance doesn't hurt
(surface defect detection at 100MB/s)
thomas...@gmx.at
This is my second attempt to answer
(the first mail seems to be lost).
Just curious. What problems do you expect to be solved?
I don't want to convince you of something.
I am just interested what people expect from a new
programming language.
thomas...@gmx.at
> thomas.mer...@gmx.at пишет:> BTW.: Seed7 is my attempt to improve the ideas of Pascal.
> > Seed7 programs look familiar for Pascal programmers.
>
> I think CamlP4 programs can also be maid looking familiar for Pascal
> programmers.
I didn't know that. Modula-2, Oberon and also Ada are
looking familiar for Pascal programmers.
I used Pascal almost exclusively for about 10 Years.
For me it was a sad story that Pascal got replaced at many
places where it once was...
Scott Moore
The overview of IP Pascal is here:
http://www.moorecad.com/ippas/index.html
Under the "language" button, third down on the left.
IP Pascal features monitors and processes. The normal "program" module,
along with the modules it can use ("module" = TP "unit") form the main
main or default thread. Another thread can be set up with a "process":
process mythread;
uses mymonitor;
var x, y, z: integer;
procedure q;
begin
end;
begin
<code for thread to run>
end.
Ie., it has the exact syntax of a program, but is actually executed
in its own thread. A process module cannot appear in a "uses" statement
for another module, and a process module can only use "monitor" or
"share" modules. Any number of threads can be created by adding more
process modules.
A monitor module appears as a normal module:
monitor x(input, output);
private
var y: integer;
procedure x(var a: integer);
begin
y := a
end;
begin
{ initialization }
end;
begin
{ finalization }
end.
Except that monitors must have all of their global variables
declared as private. Any call of a monitor procedure or function
from the outside is multitask locked on entry to the procedure
or function, and unlocked on exit. There is one lock for the
entire monitor that locks all of the data in the monitor.
As normal modules do, a monitor can contain both startup and
shutdown sections, or just a startup section. A ';' following
the main block instead of a '.' introduces the shutdown
section.
Globally accessible monitor routines also have the characteristic
that their parameters, and function results, cannot be or contain
pointers. The so called "pointer barrier" prevents the monitor
from breaking its locking mechanisms by effectively exporting
addresses.
In addition, a monitor cannot call an external procedure or
function with a var (call by reference) parameter, but it can
be called by an external module with var parameters. This, again,
prevents the monitor from exporting references to its data.
Monitors can call other monitors, or share modules.
Finally, a "share" module" is simply a module that has no
global variables at all:
share stuff;
procedure x;
begin
end;
.
It has no initialization or finalization block at all, since it
has nothing to initialize. A share module can be called by anyone,
and serves as a place to put routines that can be used by any
thread, since they have no global data to be in conflict.
As described above, a monitor would allow two threads to
communicate, but it would require polling. The final key to
multithreading is the "semaphore" variable:
var mysignal: semaphore;
And the standard functions:
procedure signal(s: semaphore);
procedure signalone(s: semaphore);
procedure wait(s: semaphore);
These standard procedures all must be executed from a monitor
only (because they are associated with the lock a monitor
provides).
Semaphores are FIFO queues for threads awaiting signals between
threads. A thread enters the queue by executing a "wait", and
will hold there until signaled.
Executing signal() or signalone() will cause either all of the
threads awaiting a queue, or just one thread, to be released.
When a thread waits for a signal, it effectively exits the
monitor lock that it was called in on entry to the wait, then
reasserts the lock on exit from the wait.
PUTTING IT ALL TOGETHER
The standard "demo" app for IP Pascal threading is the "marco
polo" program:
monitor linecontrol(output);
type string = array of char;
private
procedure writeline(view s: string);
begin
writeln('Task output: ', s);
end;
begin
end.
process thread1;
begin
while true do writeline('I am process A')
end.
program thread2;
begin
while true do writeline('I am process B')
end.
Which would print:
Task output: I am process A
Task output: I am process B
Task output: I am process A
Task output: I am process B
Task output: I am process A
Task output: I am process B
Task output: I am process A
Task output: I am process B
...
Etc., forever. If the threads wrote directly to the output
themselves, the characters would be mixed at random. The linecontrol
monitor only allows one line to print at a time, and serves as
a line output controller.
The output is interleaved as a/b/a/b... not as a coincidence, but
because the monitor locks are fair, that is, the first come to the
lock is the first served. This is an essential property to avoid
defacto deadlock.
Monitor locks have the property that if they are recursively called,
they will not deadlock. That is, if a monitor calls itself, either
directly or indirectly, it will not deadlock.
However, IP Pascal, although it prevents data corruption via multiple
threads, is not deadlock proof. It is possible to deadlock via two
monitors that call each other.
DATA QUEUING EXAMPLE
monitor queue;
type byte = 0..255; { data type for queue }
procedure inqueue(b: byte); forward;
procedure outqueue(var b: byte); forward;
private
const maxque = 100; { maximum length of queue }
type queinx = 1..maxque; { pointers for queue }
var fifo: array [queinx] of byte; { fifo for queue }
inptr: queinx; { in pointer }
outptr: queinx; { out pointer }
notempty: semaphore; { not empty signal }
notfull: semaphore; { not full signal }
{ queue pointer iterator }
function next(i: queinx): queinx;
begin
if i = maxque then i := 1 { queue has wrapped }
else i := i+1; { next location }
next := i { return result }
end;
{ test queue is full }
function empty: boolean;
begin
empty := inptr = outptr { pointers are equal }
end;
{ test queue is empty }
function full: boolean;
begin
full := next(inptr) = outptr { next input location is out location }
end;
{ place byte in queue }
procedure inqueue(b: byte);
begin
{ if full, wait until a byte clears }
while full do wait(notfull);
{ place input byte }
fifo[inptr] := b;
{ set next input location }
inptr := next(inptr);
{ signal queue is now not empty }
signal(notempty)
end;
{ get byte from queue }
procedure outqueue(var b: byte);
begin
{ if empty, wait until a byte is available }
while empty do wait(notempty);
{ get output byte }
b := fifo[outptr];
{ set next output location }
outptr := next(outptr);
{ signal queue is now not full }
signal(notfull)
end;
begin { constructor }
{ set input = output, and queue is empty }
inptr = 1;
outptr = 1
end.
This basic monitor allows two threads to exchange data. Of course,
the data could actually be any size, including structured types.
So this is the basic outline of a message passing monitor.
CONCLUSION
Besides offering multiple threads, the tasking mechanisim in
IP Pascal offers protection because it unites type security with
the monitor concept, as was outlined by Per Brinch Hansen in the
1970's. Because monitors, semaphores and the rest are built in
language contructs, IP Pascal does not need to have the equivalent
of a C "volatile" statement to declare variables as multitaskable.
IP Pascal knows when and when not to cache variables.
Per Brinch Hansen talked about Java Parallelism in "Java's insecure
parallelisim", which was basically about the fact that Java
implemented monitors as being optional for the user, ie., the
user could create multithreaded programs and easily bypass the
protections of the monitor.
This kind of thing (fortunately or unfortunately) gives the current
advantage in multithread/multicore to type secure languages like
original Pascal and Ada. You can add monitors to an insecure language,
but monitors will then themselves fail to be secure. Java represents
the odd case of a fairly secure language implementing monitors
without their security.
IP Pascal features the ideas of Concurrent Pascal, but is backwards
compatible with general Pascal. For example, CP does not allow pointers,
whereas IP Pascal simply restricts them with respect to monitor use.
Also, CP is designed to prevent deadlock by source level verification,
whereas IP Pascal is not inherently deadlock proof, it it up to the
user to avoid deadlock, although using the monitor concept, instead
of simple user called lock and unlock statements tends to avoid
deadlock by avoiding the need to track when and where such locks are
used. The reason IP is not restricted to the point of deadlock avoidance
is that we found on applying monitors to sample problems in
multitasking, that if the monitors were made deadlock proof, the system
would be unable to solve certain problems, and would be forced to
use the deadlock proof monitors to implement a second level locking
system that could, itself, deadlock.
Scott Moore
thomas...@gmx.at
> On 2008-04-28, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> > On 28 Apr., 15:59, Marco van de Voort <mar...@stack.nl> wrote:
> >> On 2008-04-28, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> >> >> While I totally agree with you that slapping GPL on each and everything is
> >> >> unnecessary, it is more the recycling of the compiler source than using it
> >> >> that is limited by the GPL.
>
> >> > As I explained in the another mail. I plan to release a
> >> > Seed7 version of the P4 under the GPL. For this version
> >> > (or a later improved Seed7 version of the P4) it would
> >> > be interesting to take extensions from other sources.
> >> > Therefore I asked for the GPL compatibility.
>
> >> PD or BSD is already GPL compatible, and not as restrictive as GPL.
>
> >> > BTW.: Seed7 is my attempt to improve the ideas of Pascal.
> >> > Seed7 programs look familiar for Pascal programmers.
>
> >> I'm not interested in Seed. I've seen all arguments in comp.lang.misc
> >> already, and decided it doesn't solve any problems that I have.
>
> > Just curious.
> > Whad do you expect from a programming language?
>
> Well, primary not just language, but development system, community and in
> general a somewhat healthy ecosystem.
I guess that with 'development system' you mean an IDE.
One design criteria for Seed7 is: It should be usable without IDE.
That does not mean that I am aggainst IDEs, but IMHO simple things
should stay simple. I am sceptical aggainst languages which are
only usable with an IDE. I think that compiled languages lost
ground to script languages because some IDEs became more and more
heavy. Switching between IDEs is more effort than switching editors.
I expect that a community will grow out of nothing. :-)
I do not know what you mean with 'a somewhat healthy ecosystem'?
All bytes in the Seed7 releases are 100% recycled from old programs.
> From the language, I'd say make large applications with a minimal overall effort.
I hope that the features listed in the signature make this possible.
> A small additional requirment is a GUI system that works easy, is powerful,
> but doesn't force a too rigid structure.
Leonardo Cecchi wrote a gtk-server connection library. This is just
a beginning, but at least something is there.
> In general that means a compromise between debugging and language safety.
>
> > What problems do you have that need solving?
>
> My main problems involve threading. However not the base primitives, but
> actually splitting out algorithms over multiple cores.
The possibility of native threading was one of the reasons that I
improved the interpreted predecessor of Seed7 (where so much
decisions where postponed to the runtime that compilation to
machine code was not reasonable) to the compileable language
which Seed7 is now. IMHO one of the main reasons to use threading
is the need for performance. Apart from being compilable Seed7 has
currently nothing which is needed for threading.
> Fix that, and more people than just me will be interested.
Okay.
Robert Riebisch
> > Fix that, and more people than just me will be interested.
>
> Okay.
And don't forget to make a DOS port. ;-)
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
thomas...@gmx.at
> thomas.mer...@gmx.at wrote:
> > > Fix that, and more people than just me will be interested.
>
> > Okay.
>
> And don't forget to make a DOS port. ;-)
At the beginning of the 90s, before I switched to Linux,
I used DOS as development platform. Some drivers for DOS
are still in the Seed7 release. I have not tested the Seed7
DOS version for ages, but maybe you succeed compiling. :-)
Marco van de Voort
>> > Just curious.
>> > Whad do you expect from a programming language?
>>
>> Well, primary not just language, but development system, community and in
>> general a somewhat healthy ecosystem.
>
> I guess that with 'development system' you mean an IDE.
Yes. With RAD aspects and a bit of more advanced stuff (like basic
completion of identifiers, Intellisense like)
> One design criteria for Seed7 is: It should be usable without IDE.
> That does not mean that I am aggainst IDEs, but IMHO simple things
> should stay simple. I am sceptical aggainst languages which are
> only usable with an IDE.
I know very few systems that don't come with a commandline compiler. In the
Smalltalk realm there might be some, but in general a cmdline compiler is
always there.
> I think that compiled languages lost ground to script languages because
> some IDEs became more and more heavy.
Personally I don't think they lost ground. It is simply a new application
(or direction) for programming. IMHO it stems more from the sysadmin side of the
IT spectrum than from the programmer side.
> Switching between IDEs is more effort than switching editors.
Well, it is easier to switch from Delphi to Visual Studio then from joe to
vi. Actually it is easier to switch from Delphi to joe than from joe to vi.
> I do not know what you mean with 'a somewhat healthy ecosystem'?
Programmers and projects attached to it. Not being on a small island with
one or two others.