Gpc

gpc@gnu.de

5400 discussions

Re: Quo vadis, GPC?
by samiam＠moorecad.com 03 Aug '10

03 Aug '10

Frank heckenbach wrote: >samiam(a)moorecad.com wrote: >> P5 is a much better basis for a compiler front end, being 40 years >> old, very well documented, and completely ISO 7185 compliant (not a >> subset), and completely free of copyright or license encumberments. > Where is the copyright/license/public domain statement from its > authors? I didn't find them in p5.zip from your web site. Note that > "no copyright notice" doesn't mean "no copyright", but in fact the > opposite "all rights reserved" is the default. Like it or not, > that's the legal situation. Only since the Berne convention was adopted. Pascal-P predates the Berne convention (in the USA, I guess it depends on where and which treaty you are talking about, Berne dates back to 1886)[1], it was written in 1972. It was also openly distributed to anyone that asked for it. Steve Pemberton published it without problems (or agreement with the original authors) in his book, and made it available on his web site, again without restrictions (and I asked the author about it personally). You could also ask Wirth about it, but I don't suppose it would make a difference, since he didn't personally write it, his students did. Neither the old nor the new united states copyright laws specifically stated what the exact meaning of public domain was. The former law simply stated that copyright didn't apply by default, but the berne convention says it does. In any case, the courts have weighed in on the subject, and ruled time after time that works given out freely and freely published loose any copyright status. In fact, I have yet to see a single example of a work that was freely given out by the author, but later retracted and successfully sued over (note patents are a completely different subject). However, its not really my office to talk you into anything here, just point out possibilities. Scott Moore Berne convention: [1] This Convention shall apply to all works which, at the moment of its coming into force, have not yet fallen into the public domain in the country of origin through the expiry of the term of protection. US "Berne Convention Implementation Act of 1988" Sec. 12. Works in the public domain. Title 17, United States Code, as amended by this Act, does not provide copyright protection for any work that is in the public domain in the United States.

4 4

Re: Quo vadis, GPC? PL features for compiler
by Frank Heckenbach 03 Aug '10

03 Aug '10

spir wrote (by PM, but I supposed it was meant for the list): > > Yes, it's possible, but it's IMHO not conformtable. I know I'm > > repeating myself, but I'm really fed up with having to "reimplement > > the list", as I wrote. It's also a psychological thing IMHO -- if > > advanced data structures (objects, trees, hash tables) are readily > > available (as in C++), you tend you use them when useful; if they're > > not (as in Pascal, except for objects), you're much more likely to > > do quick ad-hoc work-arounds, which affect the efficiency, but also > > the design of your program, especially in the long run. GCC's > > TREE_NODEs are a particularly bad example of this, spreading all > > over the code, but also in my Pascal programs, I often find a lot of > > ad-hoc list (or other structures) handling code that obscures the > > actual purpose of my code and thus make it harder to understand > > later. > > This very clearly shows how much a (fully flexible and generic) > sequence type is a fondamental feature for any general-purpose > language. Thus, it must be part of new-GPC (meaning also > prerequisites such a generic & referenced types); then, we have > them available to write the new-GPC compiler in new-GPC ;-) I'd say not only simple lists (sequences), also hash tables, vectors (dynamic arrays) and trees are data structures I use regularly and would like to have readily available. > I take the opportunity to ask a side-question: is there a logical > or practical link between compiler target and implementation > languages? For instance, provided GPC's feature set is good enough > (see above) to write a compiler comfortably, At the moment it isn't yet WRT the above features. That's the chicken and egg problem I referred to. Either one uses C++ initially (which has the features) to implement a new compiler with the features and then ports the compiler to Pascal, or one uses the existing GPC to write the new compiler in a more awkward way and later cleans it up when it's self-hosting. Kevan Hashemi wrote: > I guarantee you that's the case for me. I read through Bison and I liked > it very much, and I am thoroughly convinced of its merit by your ^C > example. But my first look through the Bison manual page suggested that > the output was a C program that we would then compile and link to, which > means that at least part of our Pascal compiler would be written in C. The Bison output basically consists of generated tables (which are mostly numbers), and a fixed parsing algorithm that uses these tables which is more or less verbatim copied from a template file. It provides several such templates, the basic C algorithm, a GLR algorithm (that parses a larger class of syntax, which GPC requires) also written in C, and one in C++. So it's possible to add a Pascal template as well. Of course, it would have to be written (probably by us), which is some work -- though probably minor compared to the rest of the compiler, and of course, a one-time job, independent of grammar changes, and it would be useful to Pascal programmers who'd like to implement their own parsers. > Given the extent of my inexperience, but at the same time my eagerness > to help, perhaps you could explain to me how we could use Bison on the > way to a self-compiling Pascal, or how the C-code output of Bison (if > that's indeed what it puts out) could be part of the project in a way > that left us independent of the GCC back-end problems. It's nothing to do with backend problems. A newly written compiler implemented in C(++) with a non-GCC target (whether C++, Ada or LLVM) could still use Bison as is. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: Quo vadis, GPC?
by samiam＠moorecad.com 03 Aug '10

03 Aug '10

1 0

Re: Quo vadis, GPC? (Managing by license)
by Objective Modula-2 03 Aug '10

03 Aug '10

John L. Ries wrote: > Such a policy would seem irrational to me, as I fail to see any real benefit > to the project, but it's possible I'm misunderstanding something. I didn't say it was policy. I said it has an influence. Many of the developers think that GCC can and should compete on technical merit alone, but a there are those who think that the design needs to protect the license. Sometimes decisions lean in one direction, sometimes they lean in the other direction. Both these groups have an influence. The decision of whether or not to introduce a plugin interface was certainly made at the highest level at the FSF, so you may want to consider than a matter of policy. But many decisions are made further down and they shouldn't be considered matters of policy. There was another incident many years ago where a developer had created a GCC to JVM translator or vice versa and was about to donate his code to the FSF. Richard Stallman was outraged and he trounced this poor guy in public, asking him to destroy his code so it would never leak anywhere. Clearly there is an influence of the school of thinking that says design has to follow the license. I wouldn't call it policy, but the influence is there.

2 1

Re: Quo vadis, GPC? (Community Survey)
by Prince Riley 02 Aug '10

02 Aug '10

Hello everyone, Frank's excellent post raises several issues about GPC that have been nagging at me for quite some time. As I read his post I began to understand several of the issues from the development/maintainers standpoint. There broad range of issue and concerns surrounding the future direction of GPC needs to have some refinement to provide the user community a clearer idea of the priorities and to help summarize their ideas for the maintainers. Perhaps a well structured online survey would both encourage greater response by the user community and make those ideas and opinions more accessible. I'm willing to take on the task of designing a draft user community survey, and making it accessible. Comments on this idea would be most appreciated. Prince Riley >

2 1

Re: Quo vadis, GPC?
by samiam＠moorecad.com 02 Aug '10

02 Aug '10

1 0

Rép : Ada (was: D (was: Quo vadis,
by Pascal 31 Jul '10

31 Jul '10

Hello. My background came deeply from Pascal language before I discovered Ada which provides last modern object programming with last standard Ada 2005. Just as you mentioned them, Ada provides Pascal like range checking, exceptions, generic and more: native tasking model and much more, see http://en.wikibooks.org/wiki/Ada_Programming With my huge legacy Mac Pascal code, I got involved in Pascal to Ada translator P2Ada: http://sourceforge.net/projects/p2ada It comes with some explanations: http://p2ada.sourceforge.net/ pascada.htm It comes with ISO and Borland TurboPascal translation on NewP2Ada branch (pretty stable release http://p2ada.svn.sourceforge.net/viewvc/ p2ada/newp2ada). It comes also with Object-Pascal translation mainly coming from Delphi and FPC on ObjP2Ada branch (alpha release http:// p2ada.svn.sourceforge.net/viewvc/p2ada/objp2ada/). For translating all macro of Pascal Mac interfaces I used GPC pre- processor. At the beginning of the century I was very happy to get a Pascal compiler on Mac new OS X. Thanks to all that make GPC possible. Nowadays, as mentioned, Ada tool chain GNAT is available with GPL (http://libre.adacore.com/libre) thus I switched without forgotten why. Regards, Pascal. http://blady.pagesperso-orange.fr Le 31 juil. 10 à 06:54, gpc-owner(a)gnu.de a écrit : > De : Frank Heckenbach <ih8mj(a)fjf.gnu.de> > Date : 31 juillet 2010 06:01:17 HAEC > À : gpc(a)gnu.de > Objet : Rép : Ada (was: D (was: Quo vadis, > > > J. David Bryan wrote: > >> This raises a point of interest to me. When GPC development >> stalled, I had >> to decide whether to continue with GPC as it was, switch to >> another Pascal >> compiler, or switch languages. I have programmed in Pascal for >> thirty >> years; it was my fifth language, after BASIC, Algol 60, FORTRAN >> IV, and >> SNOBOL, and of those, it is the only one in which I have continued to >> develop new programs. This was due primarily to the existance of >> GPC, and >> especially its good support for ISO 10206. >> >> For a number of reasons, I elected to switch to Ada, as >> implemented by the >> GNU Ada compiler (GNAT). I had studied the language shortly after >> it was >> introduced in 1983 but did not use it seriously until a GCC >> version became >> available. I found the transition from Pascal to Ada to be quite >> easy, >> because many of the implementation concepts are similar. For several >> years, I've done all of my new work in Ada instead of Pascal. >> >> I would think that translating from Pascal to Ada would have some >> advantages over C++. For example, Ada inherently supports scalar >> subrange >> types and range checking. I'm not that familiar with C++, but I >> don't >> believe that subranges are supported. > > No, not directly. However, range-checks are a rather minor issue -- > for comparison, it took me a few days to implement them in GPC, > while the object models took weeks or months (I'm not sure exactly > how much work Peter and Waldek spent on them), exceptions > implemented from scratch would take weeks, and templates probably > much longer. So it's these "big things" that matter most. You might > think checked subranges are more important because they're more > fundamental (which they are), but they're just not so difficult to > implement. For the 3 big things I mentioned, I know C++ has them > already. I don't know if Ada does, perhaps you can give us some > information here, e.g., is its object model comparable to those GPC > supports or that of C++; does Ada supported exception handling and > how; does it support something like templates (IOW, how can one > implement, say, a generic list, applicable to any given type, with > strong type-checking). >

1 0

Re: OS wars (was: Quo vadis, GPC?)
by samiam＠moorecad.com 31 Jul '10

31 Jul '10

1 0

Re: Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

| At some point in time I have to wonder when people will go to use free | pascal at http://www.freepascal.org/ | | They are Delphi and turbo pascal compliant How is free pascal an improvement over gpc in terms of graphics output? I searched both the programmer's guide and the language reference guide for "graphics." I found nothing. | And lets face it, here in the states pascal usage has dropped | significantly since the the infestation of java... Perhaps your intent was to post in the "Quo vadis GPC" thread? I plea for discussions of GPC that have nothing to do with GRX be taken to that thread. Thanks. | | | | | | -----Original Message----- | From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of | twixt(a)cstone.net | Sent: Thursday, July 29, 2010 11:51 AM | To: gpc(a)gnu.de | Subject: Quo vadis GRX? | | | | I would like to use Pascal to generate images in high resolution and at | least 24 bit color depth. There are links to a GRX library, which | provides | 2d graphics, but the user manual there was last updated in 2007, which | suggests they are further behind than GPC. I don't find any grx library | in | my Debian (Lenny) list of available packages, using the search feature | within aptitude. Apparently I would have to compile GRX and then somehow | get it to work with Pascal. As a barely capable programmer, I do not | look | forward to this with glee. (BTW I am not asking for help, just making a | point.) In all the discussion about the future of GPC, I am a bit | surprised that no one seems to talk about graphics output. Did I miss | something? I do that a lot. | | How about incorporating graphics | output directly in Pascal? Is there much interest in this? It seems to | me | that it would make Pascal more attractive. It would be "like POVray | but even more powerful" as any general purpose programming language | naturally would be. Thanks for your time. | | | | | PRIVILEGED AND CONFIDENTIAL | This email transmission contains privileged and confidential information | intended only for the use of the individual or entity named above. If the | reader of the email is not the intended recipient or the employee or agent | responsible for delivering it to the intended recipient, you are hereby | notified that any use, dissemination or copying of this email transmission | is strictly prohibited by the sender. If you have received this | transmission in error, please delete the email and immediately notify the | sender via the email return address or mailto:postmaster@argushealth.com. | Thank you. | | | | |

2 1

Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

I would like to use Pascal to generate images in high resolution and at least 24 bit color depth. There are links to a GRX library, which provides 2d graphics, but the user manual there was last updated in 2007, which suggests they are further behind than GPC. I don't find any grx library in my Debian (Lenny) list of available packages, using the search feature within aptitude. Apparently I would have to compile GRX and then somehow get it to work with Pascal. As a barely capable programmer, I do not look forward to this with glee. (BTW I am not asking for help, just making a point.) In all the discussion about the future of GPC, I am a bit surprised that no one seems to talk about graphics output. Did I miss something? I do that a lot. How about incorporating graphics output directly in Pascal? Is there much interest in this? It seems to me that it would make Pascal more attractive. It would be "like POVray but even more powerful" as any general purpose programming language naturally would be. Thanks for your time.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc