Ansi Perl

[Eyck]

How much does standarisation(language standarisation) flies in the face of spirit (and practice) of perl?

I once had friend who avoided perl because 'there's no such thing as ANSI perl', and I think he had a point. It would be nice to have such 'certfified', functional standard core. This would enable one to work on this core without constant contact and feedback from community.

For example, one could take 'ANSI Perl' book, a year off, go to a deserted island, and create mini-ponnie.

But, would it even be at all beneficial?

UPDATE: I'm not advocating starting formal ANSI costly comitee, I use 'ANSI Perl' as allegory.

[Corion]

There is only one Perl, namely the Perl. You don't have different vendors developing slightly differing versions of Perl. And for that reason, there is no more need for standards than Perl already is (and backwards compatibility is an altar stone on which lots of things are sacrificed in the Perl world). The only thing an "ANSI" standard would bring would be a development process slow as molasses. Perl 4 and Perl 5 are quasi-standardized, because many OS vendors include it as a crucial part for the utility programs of their OS, so these parts won't change ever.

Also, creating an ANSI comittee costs real money, which isn't that easy to come by for the Perl community, or rather, which is easier acquired and spent for other things. If you are looking for the "standard documentation", I think the Camel book(s) are just that. They lack the ANSI label and the price tag of USD 300+; you can't as easily bludgeon people to death with them and they are more entertaining I believe.

[Eyck]

That's untrue. This is just often perpetuated myth.

I've got lots and lots of perls: miniperl, perl 5.000, perl 5.6, perl 5.8, thos families of perl differ in way more significant ways then C implementations of different vendors.

And I've encountered some features, described in camel book(s), which just don't work in some (or most, or modern ) versions of perl, for example:

while ($sth=~/sth(sth)/g)
 {}

shortcut. This used to work in 5.000, stopped working in 5.6 because of broken optimisation. I reported the bug, but apparently this was considered a buglet, and left as is.

This forced me, (and for example Apache::ASP project) to instead use unefficient replacement:

$mycopyofstring=$sth;
while ($mycopyofstring=~s/sth(sth)//) {
}

The point here, is that important features of language appear and disappear at will, thus you've got to stay in-loop all the time, keeping and eye on changes, hoping that what you've learned won't be thrown out of the window next sumer

Same goes for your argument about vendors forcing stabilisation - debian folks loved perl and created most of their tools in perl. This backfired badly when some crucial parts of perl changed, thus forcing rewrite of large parts of those tools ( and quite complicated upgrade path - keep both perls on your system, for every package - download new package, remove old package, run it's postrm script with odl perl, run postinst of new package with new perl ).

Also please notice, that there is a very stronge movement to remove perl from base systems - OpenBSD, NetBSD, FreeBSD, many Linux distributions, they've already rewrote their perl scripts in sh/ksh, are talking about this or are actively rewriting their perl stuff.

If perl would provide this real basic and stable set of features, nobody would be moving away from it.

[Corion]

So what you want in fact is a really stable distribution of Perl? If what you needed works only in Perl 5.5.x, even that branch is still maintained, or rather, still mostly compiles on a lot of platforms. If you move within Perl5 releases, some breakage is to be expected in my opinion - that's why Perl 5.5.x still has a "maintenance branch", even though 5.5.4 had as its main change some fixes for gcc compatibility.

The Debian folks never got the spirit of Perl in my opinion, as they never released their modules and applications onto the CPAN, which makes integrating their modules with newer Perls quite difficult. But what you consider a "quite complicated upgrade path" I consider a triviality, and have made it into a rule: Never change your vendors perl. Upgrading or changing your vendors perl on your own will inevitably lead to a broken Perl installation and most likely to malfunctioning system tools too. Perl itself can live quite happily in different versions on the same machine and you should take advantage of that instead of fighting against it. Using Debians (or whatever other) package manager to manage Perl modules is, in my opinion, the wrong way to do things if Perl is central to your objectives. I know that others go the other way and maintain everything through their OS' package tool, but to them, Perl is merely one tool and not the central reason to run an OS.

The "very strong movement" is there because the Perl core is too big, and that's a good reason to want Perl out of an operating systems core. Perl 5.8.10 or 5.8.12 are supposed to get a much smaller core. Anybody doing non-trivial programming in any of the shells incurs a much higher development/bug hunting cost than (competently) using Perl. For a Linux distribution, the higher development cost may pay off in a smaller distribution size.

In the end, I think if you stick with Perl 5.5.x, you get the "real basic and stable" part of Perl on which you can rely. But, as the quote goes, biologists have this special word for "stable": dead - you can't have both, a live and evolving use of the language and its features and a stable set that never changes.

[PodMaster]

And I've encountered some features, described in camel book(s), which just don't work in some (or most, or modern ) versions of perl, for example:

001  while ($sth=~/sth(sth)/g)
002   {}


shortcut. This used to work in 5.000, stopped working in 5.6 because of broken optimisation. I reported the bug, but apparently this was considered a buglet, and left as is.

This forced me, (and for example Apache::ASP project) to instead use unefficient replacement:

001  $mycopyofstring=$sth;
002  while ($mycopyofstring=~s/sth(sth)/) {
003  }


I don't know what you're trying to show here, but the second example is a syntaxt error (Substitution replacement not terminated).

The point here, is that important features of language appear and disappear at will, thus you've got to stay in-loop all the time, keeping and eye on changes, hoping that what you've learned won't be thrown out of the window next sumer.

Important features? I think you mean experimental features.

[davorg]

What Corion said :)

ANSI certification serves to guarantee that a certain vendor's implementation of a programming language contains a defined minimum core functionality. As there is only one vendor developing and "selling" Perl, there's no need for an ANSI standard.

Ok, so some groups (for example, Activestate) add extra functionality to their Perl distributions (like the Win32 modules) but that would fall outside the ANSI certification anyway (as it's extra to the standard distribution).

The functionality of a given version of Perl is defined in the perldoc that comes with that version. No further definition is required.

Or am I missing something?

[bart]

Your question isn't new. I recall a very long discussion on this subject years ago, in the newsgroups. This reply from Elian AKA Dan Sugalski is a nice starting point. (The thread is over 100 posts total.) I hope it covers most of whatever questions you might have.

[Anonymous Monk]

$ perldoc -q ANSI
Found in /opt/perl/lib/5.8.6/pod/perlfaq2.pod
    Is there an ISO or ANSI certified version of Perl?

    Certainly not.  Larry expects that he'll be certified before Perl is.

[blazar]

You've read 'perldoc -q ANSI', don't you? This is not just to give you an RTFM-like answer, it's just to stress that with Perl it's like this. I mean it's obvious that we all like it as it is, with its inconsistencies and its magic dwimmeries. There have been non-backwards compatible changes in the past and all sort of things like these, but we also have an extremely powerful language and we can rely on continuous evolution. So in some sense standardization is not in the spirit of Perl. In some sense it could be beneficial, in some other sense it would be all but beneficial: it's once more a matter of personal tastes IMHO. I prefer it like it is FWIW!

[sasikumar]

Hi,
For example, one could take 'ANSI Perl' book, a year off, go to a deserted island, and create mini-ponnie.


If this is what u want then perl already has this support in it. There is no special ANSI Certification required for mainitaining the standards. More over perl is developed by the perl comunity. Its a single comunity as a whole. Even though vendors are different there is no core functionality change that would affect your program.

All these are evident frm the perls portability and the backward compatibility. The code that runs on windows runs the same on unix and all other OS(Though there are some exmptions). I hope your friend was misguided by some one.


No need for standards until or unless u start screwing the langauge.

Thanks
Sasi Kumar

[Eyck]

There is no such thing as single 'perl community' with single voice.

Even accounting for laws of large numbers, members of this community change, some of them start their own churches, many new people come and go....

For example there is extremely large flurry of people with no UNIX background pouring in, this changes the language under our feet.

Perl IS extremely portable (not to small devices though, unfortunatelly, :( ), which is especially shocking when compared to java, which claims to be portable, while it won't run on half of platforms that perl happily supports (without claiming ultra-portability), but it changes from revision to revision.

[r34d0nl1]

I agree with you once that the ANSI spirit is to have a code that can run under
any flavor of OS without beeing modified. That is a minimum set of functions and features that should be avaiable to any distribution.
As far as I know there is no oficial set of modules, for instance, that must come with any perl distribution
or with any basic OS distribution like Unix UX, AIX, Mac, Linux and even(il) windows.
A standard set of modules (and maybe documentation) would help developers to produce final
sw that would run withoung beeing necessary to download and install any specific module (that is default (ANSI) to any distribution.
When talking about Perl I mean that the set of modules that goes with every distribution
and that is tested in every plataform is more important than any syntax issue
because ther Perl language is already very portable (see perldoc perlport)

[Mago]

ANSI
Acronym for the American National Standards Institute. Founded in 1918, ANSI is a voluntary organization composed of over 1,300 members (including all the large computer companies) that creates standards for the computer industry. For example, ANSI C is a version of the C language that has been approved by the ANSI committee. To a large degree, all ANSI C compilers, regardless of which company produces them, should behave similarly.

In addition to programming languages, ANSI sets standards for a wide range of technical areas, from electrical specifications to communications protocols. For example, FDDI, the main set of protocols for sending data over fiber optic cables, is an ANSI standard.


A vocabulary and set of grammatical rules for instructing a computer to perform specific tasks. The term programming language usually refers to high-level languages, such as BASIC, C, C++, COBOL, FORTRAN, Ada, and Pascal. Each language has a unique set of keywords (words that it understands) and a special syntax for organizing program instructions.

High-level programming languages, while simple compared to human languages, are more complex than the languages the computer actually understands, called machine languages. Each different type of CPU has its own unique machine language.

Lying between machine languages and high-level languages are languages called assembly languages. Assembly languages are similar to machine languages, but they are much easier to program in because they allow a programmer to substitute names for numbers. Machine languages consist of numbers only.

Lying above high-level languages are languages called fourth-generation languages (usually abbreviated 4GL). 4GLs are far removed from machine languages and represent the class of computer languages closest to human languages.

Regardless of what language you use, you eventually need to convert your program into machine language so that the computer can understand it. There are two ways to do this:
# compile the program

* interpret the program

See compile and interpreter for more information about these two methods.

The question of which language is best is one that consumes a lot of time and energy among computer professionals. Every language has its strengths and weaknesses. For example, FORTRAN is a particularly good language for processing numerical data, but it does not lend itself very well to organizing large programs. Pascal is very good for writing well-structured and readable programs, but it is not as flexible as the C programming language. C++ embodies powerful object-oriented features, but it is complex and difficult to learn.

The choice of which language to use depends on the type of computer the program is to run on, what sort of program it is, and the expertise of the programmer.


Mago
[e-mail]

[wolfger]

If I understand you properly, you are asking why we don't force people to write for($x=1;$x<=10;$x++){} and disallow for(1..10){}, or vice versa. Similarly, I think you want to force if($x==5){print $x} and disallow print $x if ($x==5) (or vice versa... If my assumptions are correct, then I think the answer is that this flies completely in the face of Perl's spirit...

[Anonymous Monk]

No, I don't think the OP wants that, and I don't think any other person rooting for certification of Perl wants that.

What they want is have a specification which says that "EXPR if CONDITION" is 1) legal, and 2) states what it means. There are benefits to having a specification constructed by a specifications body. The benefits gets bigger if there are more players. Perl, being a relative small language, with just one vendor (that is, just one entity that produces Perl) the benefits are smaller than for instance C, with millions of coders, and dozens of compilers.

I don't know whether Perl would benefit from getting a standard. It depends on what your goals are, I suspect. If you want to get more people to program Perl, and have it being used in more companies, you want specification more than if you want to give more flexibility to the implementors.

[gmpassos]

Perl is not like C/C++ that have a lot of nuances for each compiler/vendor/OS.

Perl5 is Perl5 and developed by only 1 community, Perl.

Perl only have nuances when you talk about Perl 5.6+ series and Perl 5.8+ series, and when we talk about OS. Differences from OS we also have with ANSI C, but Perl also have a good guide, perlport, to make portable codes.

Perl doesn't have an "ANSI Perl" and won't have one because the aspects are very different from C.

[jonadab]

I once had friend who avoided perl because 'there's no such thing as ANSI perl'

This is an oversimplistic way to look at things, and it rather misses the point. Perl5 is significantly more standardised than ANSI C, in terms of behaving the same way on different platforms (assuming you avoid constructs that the Camel specifically warns are inherently unportable).

Sure, there are some differences from one version to another, but if you restrict yourself to what is documented in the 2nd edition Camel (and avoid the aforementioned inherently-unportable things, such as backticks and link, and hardcoded filenames and paths), it will pretty much run unmodified and with the same semantics on any version from 5.003 forward, on any operating system that has Perl5 (except that fork, as documented, won't work on single-tasking OSes).

The same thing is not true for ANSI C.

[Anonymous Monk]

Ansi C is portable to different platforms without problems if you avoid the things that are specified as implementation defined as well.

That, after all, is the point of having a standard.

The problem with unportable C code isn't because every coder is following the standard. The problem is coders targetting their compiler, and (ab)using its extensions. And then of course, there are the different libraries.

Sure, there are some differences from one version to another, but if you restrict yourself to what is documented in the 2nd edition Camel (and avoid the aforementioned inherently-unportable things, such as backticks and link, and hardcoded filenames and paths), it will pretty much run unmodified and with the same semantics on any version from 5.003 forward, on any operating system that has Perl5.

I've yet to write a C program that broke because I upgraded my compiler, or that I had to modify because it needed to be compiled on an older version of the compiler (although I've had to rewrite large portions of C programs because of kernel upgrades). OTOH, every upgrade of perl has broken some program of mine, somewhere.

[dragonchild]

I've yet to write a C program that broke because I upgraded my compiler

Which doesn't explain why I have to downgrade my gcc from 3.2 to 2.9 in order to compile Oracle. It's just an upgrade, right?

[DrHyde]

If you want a proper standard, go to ISO, not ANSI. The ANSI is a small provincial organisation, whereas ISO is the global body.

But that aside, does your friend also eschew Java on the grounds that *it* has no ANSI standard? If he does then he's a damned fool, and his opinions are of no merit. If he doesn't, then he's a hypocrite and his opinions are also of no merit.

[Aristotle]

HTML 4.01, CSS 2.1, and the UTF-8 encoding aren't standards either. People still refer to them as standards all the time, because de facto, they are.

What they are is formally defined, so people can look at the definition to write implementations, unlike with Perl5. That is one of the things Perl6 aims to provide. For Perl5, this is not going to happen.

[helgi]

I would avoid the "ANSI" version of any computer language.

It is usually an outdated version of the language frozen into near-uselessness.