Is there such a language...
unknown
>>>>> "kgpl" == kgpl <kg...@uno.edu> writes:
In article <3nfs1c$a...@www.uno.edu> kg...@uno.edu writes:
kgpl> Does a language exist that is both compiled (which is what
kgpl> disqualifies Perl) and has available a regular expression
kgpl> handling setup as powerful (or at least similar to) Perl's
kgpl> /PATTERN/ and /PATTERN/REPLACEMENT/ operations? There are other
kgpl> qualities I'd like, but I'm betting that I can't find even these
kgpl> two, so there's no need to ask for anything else.
It's not exactly what you're looking for, but I'm inclined to suggest
Icon.
Icon doesn't implement regular expressions directly, but it does
provide support for very powerful string scanning operations, which
are more powerful than regular expressions. And if you really need
regexps, it provides support for them through the library distributed
with the system.
By default, it compiles down to an intermediate code, but the
distribution includes a compiler that generates C, which is then
compiled down to machine code by your standard C compiler.
Icon is available from cs.arizona.edu.
<MC>
--
|| Mark Craig Chu-Carroll: <MC> ||"I live to see my fondest dreams realized,
|| CIS Grad, Univ of Delaware || Of living under the sights and sounds of
|| PGP key available by finger || the gifted, Who gave so much to me"
|| car...@cis.udel.edu || - _Feed_the_Fire_, Happy Rhodes
kg...@uno.edu
Perl) and has available a regular expression handling setup as powerful
(or at least similar to) Perl's /PATTERN/ and /PATTERN/REPLACEMENT/
operations? There are other qualities I'd like, but I'm betting that
I can't find even these two, so there's no need to ask for anything
else.
Now before any Perl user tells me that there is no need for a
compiled Perl of any sort because Perl is so efficient, let me
say that I am using Perl to prototype an interpreter for a new
computer language. If I wrote the final version in Perl than
any user would have to run an interpreter on top of an interpreter
to run a program in the new language and I want to avoid this. The
aspect of Perl that makes it most attractive for doing this
prototyping is the regular expression handling stuff. I'd like
to avoid having to dig into the Perl source code and extract the
regular expression stuff for modification and re-use if possible.
Unfortunately Perl itself is not useable for the things I want to
use the new language for, as Perl is not reflective, which is the
primary aspect of my project.
Thanks,
Kevin
Peter da Silva
> Does a language exist that is both compiled (which is what disqualifies
> Perl) and has available a regular expression handling setup as powerful
> (or at least similar to) Perl's /PATTERN/ and /PATTERN/REPLACEMENT/
C. There are a variety of regular expression routines, or you can probably
suck the code you like from Perl. See regexp and re_exec in the manual.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Har du kramat din varg idag?"
Martin Cracauer
implementations. There is NREGEX, a regexpr lib for generic Common
Lisp, availiable at ftp.cs.cmu.edu:/user/ai/lang/lisp/
If you need very fast regexpr then you might be interested in RegExp
ftp.ai.sri.com:/pub/pkarp/regexp, which is written for the foreign
function interface of Allegro Common Lisp.
Not a compiler, but the scheme interpreter elk is focused on loading
and executing functions written in C and the distribution includes a
full binding for one of the UNIX regexpr libs, as I recall. At least
it is availiable somewhere. A fast, small, flexible tool.
tub.cs.tu-berlin.de:/pub/elk/ or
ftp.cs.indiana.edu:/pub/scheme-repository/imp/
The scheme compiler BIGLOO
(ftp.inria.fr:/INRIA/Projects/icsla/Implementations/) compiles scheme
to C and has regual expression support, I think written in Scheme, not
to mention its lexer/parser capabilities. It produces standalone
applications.
I didn't use BIGLOO by myself, but I sounds like the best choice for
your needs. I'm interested in a short notice if you try out one or
more of these tools and can comment on their useability.
BTW, I've almost completely given up complex scanning/parsing in my
application languages, at least for data. Perl is just too handly, so
I transform data to a form that is most easily read by the application
langauge (easy for Lisp) in perl and just do a
popen("perl foo<data"); :-)
Martin
kg...@uno.edu writes:
>Does a language exist that is both compiled (which is what disqualifies
>Perl) and has available a regular expression handling setup as powerful
>(or at least similar to) Perl's /PATTERN/ and /PATTERN/REPLACEMENT/
>operations? There are other qualities I'd like, but I'm betting that
>I can't find even these two, so there's no need to ask for anything
>else.
>
>Now before any Perl user tells me that there is no need for a
>compiled Perl of any sort because Perl is so efficient, let me
>say that I am using Perl to prototype an interpreter for a new
>computer language. If I wrote the final version in Perl than
>any user would have to run an interpreter on top of an interpreter
>to run a program in the new language and I want to avoid this. The
>aspect of Perl that makes it most attractive for doing this
>prototyping is the regular expression handling stuff. I'd like
>to avoid having to dig into the Perl source code and extract the
>regular expression stuff for modification and re-use if possible.
>Unfortunately Perl itself is not useable for the things I want to
>use the new language for, as Perl is not reflective, which is the
>primary aspect of my project.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de>. No NeXTMail, please.
Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a
private address. At (netless) work programming in data analysis.
Stefan Monnier
] compiled Perl of any sort because Perl is so efficient, let me
] say that I am using Perl to prototype an interpreter for a new
] computer language. If I wrote the final version in Perl than
Well, I don't know exactly what your language will look like, nor do I know what
kind of end product you know (I don't even know what exactly you want to use
regexps for), but anyway:
- lex and lex-like tools provide a very convenient regexp interface.
(only for matching, not for replace). It's designed for compilers and
interpreters.
- yacc and friends is also useful for language implementations.
- most languages have some kind of support for regexps. Generally good
for matching and less good for replacing.
- Caml is a really nice language. Furthermore it compiles to byte-code and has a
lex-like utility, a yacc-like utility (it actually has really good support for
writing small interpreters and compilers).
- And don't forget that the byte-code interpreter of caml-light can be used by
your own compiler (it's already used by other languages, but I have no idea
how easy it is to use and how convenieent it is for a largely different
language)
Stefan
--
--------------------------------------------------------------------
-- Suicidez-vous jeune, vous profiterez plus longtemps de la mort --
--------------------------------------------------------------------
Carlton Schuyler
> Perl) and has available a regular expression handling setup as powerful
> (or at least similar to) Perl's /PATTERN/ and /PATTERN/REPLACEMENT/
> operations? There are other qualities I'd like, but I'm betting that
> I can't find even these two, so there's no need to ask for anything
> else.
Let me ask you this: Do you want to specify regexp's at runtime (after you
compile your language interpreter?) Because if you do, then you should ignore
the following paragraphs. The thing is, Perl's power in this area is BECAUSE
it is not a compiled language like, say, C++. Perl actually compiles its
regexps at runtime (into a state machine-type thing) - so you get good per-
formance. I am aware of POSIX specs for regexp compiling and parsing, which
you may want to look into (sorry, that's about as specific a reference as I
can muster).
Now, if you don't need to have runtime specifgication of regexps, then:
I would suggest that you look into using Lex/Flex and perhaps Yacc/Bison
as well. Lex'll allow you to do your regexp thing, and since you're writing
a new language, I'd wage that you'll want some "real" parsing ability (i.e.,
nonterminals and recursive descent etc.) as well. What these things do, for
the unaware, is allow you to write a parser Mind you, there's a learning
curve to overcome if you haven't already, and it can be a bugger to debug
Lex/Yacc code (well, with the tools I;ve got, anyhow). I've written a pretty
large app using Flex and Yacc, and am pretty happy about the outcome.
The O'Reilly book "lex & yacc" is a good book for learning in my opinion.
- -+ +- ++ +-- +-+ ++- +++ +--- +--+ +-+- +-++ ++-- ++-+ +++- ++++ +---- +---+
+--+-
Carl Schuyler "Computational Linguist" ``The Information Refinery'' (TM)
TASC Incorporated
12100 Sunset Hills Road Phone: (703) 834-5000 ext. 2460, 2982,
2134
Reston, VA 22090 Fax: (703) 318-7900
Richard A. O'Keefe
>Does a language exist that is both compiled (which is what disqualifies
>Perl) and has available a regular expression handling setup as powerful
>(or at least similar to) Perl's /PATTERN/ and /PATTERN/REPLACEMENT/
>operations? There are other qualities I'd like, but I'm betting that
>I can't find even these two, so there's no need to ask for anything
>else.
Sorry, you just lost your bet. There are several compiled languages with
good pattern matching facilities. The obvious one is Icon, which has its
own newsgroup comp.lang.icon. Its pattern matching capabilities are far
greater than Perl's, but they are program control structures, not compact
text strings. This means that you have to type rather more to get the
same effect, _but_ it also means that you can use the *same* pattern
matching techniques to "parse" other data structures as well as strings.
There are a couple of books about Icon, and a free implementation. Check
the comp.lang.icon FAQ.
Another programming language of interest is C. On a UNIX system, check for
the following manual pages: regex(3) or regex(3B), recgmp(1), regcmp(3G),
regexpr(3G). There are several free regular expression packages in and for
C, notably Henry Spencer's and the one from the Free Software Foundation.
If memory serves me correctly, the latter is available in libg++ (the FSF
library that goes with the GNU C++ compiler).
For a fixed set of patterns, the method of choice would probably be to
compile them with Flex.
--
"The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Richard A. O'Keefe
a whole bunch of things he thinks are practically exclusive to Perl.
He also sent me the same list in E-mail, but unfortunately didn't bother
to wait for my reply before posting this hymn of praise to Perl.
The gist of my reply to him was, point after point, that Icon provides
the same functionality or better, and has for rather longer than Perl.
The main difference is that Perl regular expressions are a sort of
string, and can only be used for matching strings. Many of the "features"
he identifies are actually rather horrifying syntactic kluges to work
around the decision to represent patterns as a kind of string. Icon does
_not_ make that identification, which means that the syntax is admittedly
clumsier for simple patterns, but it never ever gets as bad as Perl does.
Note that if you have an array of strings, you _cannot_ use regular
expressions in Perl to match the array (character:string :: string:array).
When I first enthused about SNOBOL pattern matching to an anthropologist
more years ago than I care to remember, he said "That's great, but can it
do the same kind of matching with _words_ as with characters." I had to
say no. I'd still have to say no if asked about Perl. But I don't have
to say no when asked about Icon.
I didn't save a copy of my reply to Tom Christiansen; if he reads this it
would be kind of him to post it for me.
Ed Peschko
>Tom Christiansen <tch...@mox.perl.com> writes:
>a whole bunch of things he thinks are practically exclusive to Perl.
>He also sent me the same list in E-mail, but unfortunately didn't bother
>to wait for my reply before posting this hymn of praise to Perl.
He replied to your reply... what's wrong with that? Replying to you as well
makes sure *you* get a chance to reply as well.
>The gist of my reply to him was, point after point, that Icon provides
>the same functionality or better, and has for rather longer than Perl.
If you could give a little bit more than the 'gist' -- people would be a little
bit more willing to listen to you.. and people could also come up with
more intelligent replies.
Give some code examples, etc. and we will see.
>clumsier for simple patterns, but it never ever gets as bad as Perl does.
You forget that 99% of the time, simple patterns is all you need! Hence,
no need to reinvent the wheel, as it seems you need to do in ICON.
I looked at all the documentation, and what was available for icon.
I was not really impressed. No code examples, and very little user support.
As for the complex expressions, in practical terms I have never, ever come
across any regexp problem that was too hard for perl.
>Note that if you have an array of strings, you _cannot_ use regular
>expressions in Perl to match the array (character:string :: string:array).
I guess I don't understand what you are trying to do here..
Match a string *in* an array?
ie:
$result = grep(/^$string$/, @array);
Match an array of strings in *a* string in array increasing order ?
ie:
$xx = 0;
while ($string =~ /($array[$xx])/g) {
print "Matched array element $array[$xx]\n";
$xx++;
last if $xx > $#array;
}
Match an array of strings in a string without *care* to the order?
foreach $element (@array) {
if ($string =~ /$element/) {
print "Could not find element $element.";
last;
}
}
>say no. I'd still have to say no if asked about Perl. But I don't have
>to say no when asked about Icon.
I guess there are two possibilities -- 1) I didn't correctly understand what you
mean about 'you _cannot_ use regular expressions in Perl to match strings to an
array'.
2) *you* have to rethink your concepts of the language.
You see, what you see as 'syntactical kludges', *I* see (and I am sure a lot of
others see) as great power -- because they let you get a lot of simple things
very quickly, and free from error, and yet are extendible (so you can do a
lot of complicated things very quickly and free of error.)
Ed
John Burdick
I'm a beginner with perl, so bear with me. I've been using awk for
simple jobs and Icon for the more substantial ones.
>You forget that 99% of the time, simple patterns is all you need! Hence,
>no need to reinvent the wheel, as it seems you need to do in ICON.
99% of the times that Perl is a good choice Perl patterns will do a
great job.
>I looked at all the documentation, and what was available for icon.
>I was not really impressed. No code examples, and very little user support.
No code examples! I take it you didn't get the Icon Program Library
which has the code examples. It's at ftp.cs.arizona.edu. I don't
remember the path, but it's pretty obvious. The files are bipl and
gipl with tar.Z and lzh versions.
>As for the complex expressions, in practical terms I have never, ever come
>across any regexp problem that was too hard for perl.
What does 'regexp problem' mean? If it's defined as when you use
regexps, then naturally good regexps will suffice. The question should
be about any pattern manipulation problem being too hard for Perl.
Icon is unusual in trying to be good at both string and list handling.
Part of the difficulty is that 'array' doesn't capture the idea very
well. Perl doesn't have any special facilty for list processing. If
you know what unification is, that would illustrate it. Unification is
fitting two trees together to make one tree containing all constants
from both sides and matching all variables from both sides. Some
variables become bound to constants from the other tree, while some
variables are bound to other variables. A variable can be bound to a
sub-tree.
Consider what it would be like to have a list be the subject of a
match. \1 and \2 might represent slices of the list, instead of
substrings.
Your effort at array driven string matching is interesting in itself,
so I'll go on to talk about it.
> $xx = 0;
> while ($string =~ /($array[$xx])/g) {
> print "Matched array element $array[$xx]\n";
> $xx++;
> last if $xx > $#array;
> }
Keeping in mind my being new to Perl, I'll try to analyze the
fragment. I'll suppose there are 3 patterns in the array. You test
that $array[0] matches once and only once; $array[1] matches once and
only once, without moving the end of the previous match; $array[2]
matches once and only once, without altering any pervious match points
and doesn't test for the end of the string. This is like an array
equivalent to /^012/. How do you implement the other usual regexp
tools like /0[12]+$/?
The easy way to do this in Icon is to hard code some procedures, which
isn't what you're interested in, so I won't bother. It's ironic that
Icon has limits resulting from compile time definitions since SNOBOL
is one of the most dynamic languages around. LISP and SNOBOL both get
much of their power from run-time definitions.
One of the main limitations I see in Perl is the apparent lack of
recursive patterns. Another is the inability to do expressions inside
a pattern. The g option mitigates this to some extent, but I don't
know how well it works with complex cases. It seems like the ease of
normal regexps is missing.
John
Tom Christiansen
:pesc0002@seasnake (Ed Peschko) writes:
:>He replied to your reply... what's wrong with that? Replying to you as well
:>makes sure *you* get a chance to reply as well.
:What's wrong is that he sent me E-mail *and* posted it.
:I saw the mail, and replied to that, but by the time I found out that
:he had posted, I didn't have my reply any more.
:It's a form of deception, that's what's wrong.
Wrong? Deception? What *ARE* you talking about?? It was a COURTESY to
reply to you directly as well as posting. It assures that you see the
reply, and that you should see it in a timely manner. As for deception,
perhaps you merely overlooked the header line that read Newsgroups:
comp.lang.perl, or whatever. It indicated that I directed the message to
the listed newsgroups as well. Please do not accuse people of deception
when in fact you were the one deceiving yourself. If you're using a
mailreader that suppresses that header, I suggest you do something about
it. But it's not my faultand it wasn't deception, and no offense was
intentionally given.
"Attribute not to malice that which might be better explained by ignorance
or sloth." You should append to that "on their part -- or on yours".
:What do you mean "reinvent the wheel"? You are trying to rewrite history.
:SNOBOL has been around for a very long time.
:Icon is a descendant of SNOBOL.
:Icon has been around longer than Perl.
:It is _Perl_ that is reinventing wheels.
Perl is not trying to solve the problems solved by tools like yacc and
other parsers. It's merely synergized existing regular expressions.
:What I mean is this kind of thing. My pattern is
:
: <create>
: ( <setread> <read> *
: | <setwrite> <write> *
: ) *
: <destroy>
:
:and a typical sequence to match against this pattern is
: ["create", "setwrite", "write", "write", "setread", "read", "destroy"]
:In a realistic example, the array elements are actually complex data structures.
:The Prolog equivalent of a pattern like this is
:
: example --> create, operations, destroy.
:
: operations --> [].
: operations --> setread, read, operations.
: operations --> setwrite, write, operations.
:
:where create, destroy, setread, setwrite, read, write could be arbitrarily
:complex predicates on data structures.
As I said, perl doesn't attempt to address through its primitives the
recursive sorts of operations necessary for recursive descent parsing.
Having written such algorithm in C, pascal, yacc, perl, lisp, scheme, and
prolog, I'm quite aware of what regexps solve, and what more sophisticated
search techniques solve. In raw C, pascal, or perl, it's not a lot of
fun. You don't have any form of recursive search, blind or otherwise,
that's built in to the language. It uses regular expressions, which are
the only place that any kind of backtracking occurs. Prolog, icon, yacc,
and more sohpisitcated incarnations of yacc-like language tools certainly
address this kind problem more than simple regular expressions, which are
not able to handle recursive patterns.
That being said, Larry would *like* to have a search engine in perl so you
could for example, read in an S-expression or a C-style {brace block} wiht
one simple expression, but I suspect that these days this would be done
via a library module rather than an addition to the fundamental primitives
of the language. I certainly wouldn't expect it to be overloaded in the
regular expression mechanism.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
if (shm == (char *)-1) /* I hate System V IPC, I really do */
--Larry Wall, from doio.c in the v5.0 perl distribution
ozan s. yigit
I looked at all the documentation, and what was available for icon.
I was not really impressed. No code examples, and very little user support.
i am not sure what it takes to impress anyone these days, but several
things are worthy of note: ICON has a substantial user population, one
very good book on the language itself[1], one good book on its internals[2].
it has been around since early eighties [my copy of the book is dated 1983]
has been used to anywhere from compiler-compilers[3] to being an extension
language to a version of emacs. [yes, really. this was done around 84 or so]
there are versions exist from IBM CMS and MVS to VMS, and all UNIX platforms
are supported. it is entirely public domain. it comes with an interpreter
and an optimizing compiler. yes, [in case you were wondering] it has an
object-oriented extension known as IDOL that provides classes and
multiple inheritence.
i do not know if "all" the documentation you looked at includes the refs
listed below, but if you would like to know more, contact the icon project
at the university of arizona: icon-p...@cs.arizona.edu. even if they
cannot impress you, they may be able to answer your questions.
oz
----
[1] Ralph E. Griswold and Madge T. Griswold.
The Icon programming language
Prentice Hall, 2nd edition, 1990.
[2] Ralph E. Griswold and Madge T. Griswold.
The implementation of the Icon programming language
Princeton series in computer science,
Princeton University Press, 1986.
[3] Richard L. Goerwitz.
A User's Manual for ipbag2 (Icon-Based Parser Generation System-2)
or How to Use and LR-based Parser Generator
ipbag2 distribution
[4] Ralph E. Griswold, Clinton L. Jeffery, and Gregg M. Townsend.
Version 9.0 of the Icon Programming Language.
University of Arizona Icon Project Document 236, 1993.
ftp:cs.arizona.edu/icon/docs/ipd236.{doc,ps.Z}
[5] Ralph E. Griswold.
An Overview of the Icon Programming Language
Department of Computer Science Technical Report tr90-6d
University of Arizona, 1990. revised 1994.
ftp:cs.arizona.edu/icon/docs/tr90-6.{doc,ps.Z}
Erik Naggum
| Wrong? Deception? What *ARE* you talking about?? It was a COURTESY
| to reply to you directly as well as posting. It assures that you see
| the reply, and that you should see it in a timely manner. As for
| deception, perhaps you merely overlooked the header line that read
| Newsgroups: comp.lang.perl, or whatever. It indicated that I directed
| the message to the listed newsgroups as well.
this is just one of the usages of the Newsgroups header. the other, more
common, usage is to indicate in which newsgroups the article to which the
user replies by mail was posted. that is, the header is useless, so do not
use this header if you wish to be as COURTEOUS as you seem to think you are.
| Please do not accuse people of deception when in fact you were the one
| deceiving yourself.
watch out for those mirrors, Tom.
| If you're using a mailreader that suppresses that header, I suggest you
| do something about it. But it's not my faultand it wasn't deception,
| and no offense was intentionally given.
but offense was certainly intentional this time, Tom.
| "Attribute not to malice that which might be better explained by
| ignorance or sloth." You should append to that "on their part -- or on
| yours".
geez. it isn't enough to explain your actions, but you need to really
browbeat people you don't like, don't you, Tom? why does this make me
think that you know perfectly well that the Newsgroups header has two
conflicting usages?
I'm eagerly awaiting your COURTEOUS response, although it would a miracle
if you ever admitted to not knowing something, when you come on so strongly
against people. surprise me with an informed, pleasant article, Tom.
at least now you know that this header has conflicting usages, and may be
able to understand somebody else's position.
#<Erik>
--
sufficiently advanced political correctness is indistinguishable from sarcasm
Richard A. O'Keefe
>He replied to your reply... what's wrong with that? Replying to you as well
>makes sure *you* get a chance to reply as well.
What's wrong is that he sent me E-mail *and* posted it.
I saw the mail, and replied to that, but by the time I found out that
he had posted, I didn't have my reply any more.
It's a form of deception, that's what's wrong.
>>The gist of my reply to him was, point after point, that Icon provides
>>the same functionality or better, and has for rather longer than Perl.
>If you could give a little bit more than the 'gist' -- people would be a little
>bit more willing to listen to you.. and people could also come up with
>more intelligent replies.
You are being rude here. Icon books are for sale. There is a comp.lang.icon
newsgroup with people who are happy to answer questions about code. Anyone
who _really_ wants to know what Icon is capable of can ask there.
I am unable to give code examples for a very simple reason: I am defending
a language that I have no proprietary interest in and do not currently have
installed. (No hypocrisy here: I don't have much need for Perl either.)
>You forget that 99% of the time, simple patterns is all you need! Hence,
>no need to reinvent the wheel, as it seems you need to do in ICON.
>I looked at all the documentation, and what was available for icon.
>I was not really impressed. No code examples, and very little user support.
What do you mean "reinvent the wheel"? You are trying to rewrite history.
SNOBOL has been around for a very long time.
Icon is a descendant of SNOBOL.
Icon has been around longer than Perl.
It is _Perl_ that is reinventing wheels.
If you think there are no Icon code examples, you obviously didn't look in
the right place. (It takes most people a couple of days to read through
the Icon documentation.)
What 'user support' do you want?
If you want support _of_ users, by people who know what they're doing,
Icon has it.
If you want support _by_ users, ask in comp.lang.icon. The sources
are freely available, just like the Perl sources.
>As for the complex expressions, in practical terms I have never, ever come
>across any regexp problem that was too hard for perl.
This actually tells us very little. The reason is that if it is too hard
for Perl, it is automatically classified as 'not a regexp problem'.
I wrote
>>Note that if you have an array of strings, you _cannot_ use regular
>>expressions in Perl to match the array (character:string :: string:array).
>I guess I don't understand what you are trying to do here..
>Match a string *in* an array?
> $result = grep(/^$string$/, @array);
Absolutely not. This is a typical response of people who have been so
overwhelmed by ed(1)-style regular expressions (which are admittedly
an extremely useful tool) that they forget that the notion of a regular
expression (and of pattern matching in general) applies to _any_ alphabet,
even infinite ones, that the elements to be matched need not be characters,
and the sequences need not be strings.
When I said an array OF strings, I meant what I wrote.
What I mean is this kind of thing. My pattern is
<create>
( <setread> <read> *
| <setwrite> <write> *
) *
<destroy>
and a typical sequence to match against this pattern is
["create", "setwrite", "write", "write", "setread", "read", "destroy"]
In a realistic example, the array elements are actually complex data structures.
The Prolog equivalent of a pattern like this is
example --> create, operations, destroy.
operations --> [].
operations --> setread, read, operations.
operations --> setwrite, write, operations.
where create, destroy, setread, setwrite, read, write could be arbitrarily
complex predicates on data structures.
>Match an array of strings in *a* string in array increasing order ?
> $xx = 0;
> while ($string =~ /($array[$xx])/g) {
> print "Matched array element $array[$xx]\n";
> $xx++;
> last if $xx > $#array;
> }
>
Again, not what I said. This matches *strings*. I am asking about
something that will match *arrays*. Perl has taught you that pattern
matching is about strings. Not always!
>Match an array of strings in a string without *care* to the order?
> foreach $element (@array) {
> if ($string =~ /$element/) {
> print "Could not find element $element.";
> last;
> }
> }
Again, not even close. Perl has taught you that pattern matching is
exclusively a relationship between strings and patterns. This is not
true in general.
>I guess there are two possibilities -- 1) I didn't correctly understand
>what you mean about 'you _cannot_ use regular expressions in Perl to
>match strings to an array'.
This is the one.
>2) *you* have to rethink your concepts of the language.
I have a Perl 4 manual. I know perfectly well what are the concepts in
Perl 4. (I am aware that I _don't_ know what's in Perl 5.)
>You see, what you see as 'syntactical kludges', *I* see (and I am sure a lot of
>others see) as great power -- because they let you get a lot of simple things
>very quickly, and free from error, and yet are extendible (so you can do a
>lot of complicated things very quickly and free of error.)
I am not saying the mildest gentlest single solitary word against pattern
matching. I think well of SNOBOL, Icon, Prolog, and a rather obscure language
called 'Alef' which all provide syntax to support the expression of patterns.
The point is YOU CAN GET THE POWER WITHOUT THE KLUGES. Perl's baroque
syntax probably saves about 30% of the keystrokes you would need in a less
baroque language. Ok, I can sympathise with that. But don't make the
mistake of thinking that syntactic obscurity is necessary.
Tom Christiansen
:One of the main limitations I see in Perl is the apparent lack of
:recursive patterns.
Actually, perl's main problem is that compiled regexps aren't first-class
citizens.
Regular expressions, by definition, are not recursive. Still, a recursive
pattern match is certainly a useful thing. Being able to do minimal
matching in perl rather than only greedy matching makes this at least
feasible to roll up, but it's not built-in. LArry has often expressed the desire to
do more interesting pattern specification. Being able to read in a C-style
brace-block or a lisp S-expr would be convenient. Of course, you can do it now
using a function, but it's not expressible in one sole regexp due to the
recursion issue.
By minimal matching, I mean the problem of accessing the string which
occurs between foo and bar, as in
$string = 'the food on the bar in the barn.';
$string =~ /foo(.*)bar/;
$1 would normally be 'd on the bar in the '. If you want it to
be 'd on the ', then you could write your pattern as
$string =~ /foo(.*?)bar/;
it's somehwat hard to express using other regexp syntaxes.
: Another is the inability to do expressions inside
:a pattern.
What do you mean?
/$pat/
works, and you can just put the expression you want in the variable.
if you mean to say
/^stuff\s*@{[$x = $y]}\s*$/
then you can get the expression happening in the pattern, but it's
certainly not the most efficient thing in the world.
:The g option mitigates this to some extent, but I don't
:know how well it works with complex cases.
Well, certainly you can do
while ( /pat/g ) {
# stuff
}
and figure out what to do with the part-way executed thing. In v5.000 and
higher, there's also a pos() lvauable accessor function and an embeddible
\G position-assertion that can help.
There's also the /e modifier on a substitution:
s/(pat1)\s*(pat2)/funcall($2 * 30, $1 + 17) || "bad string"/ge;
which is, I believe, more what you're looking for.
:It seems like the ease of
:normal regexps is missing.
Not sure what you mean there: perl's regexps are essentially an egrep
superset. The ease of normal regexps certainly is there. But maybe you
aren't using the standard definition of regexp.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
"If you think Emacs is such a great editor, just look what it did for
Richard Stallman's typing skills!"
Allen S. Rout
> [Tom Christiansen]
> | [ ... ]
> this is just one of the usages of the Newsgroups header. the other, more
> common, usage is to indicate in which newsgroups the article to which the
> user replies by mail was posted. that is, the header is useless, so do not
> use this header if you wish to be as COURTEOUS as you seem to think you are.
If this is "common usage" it is still wrong. References: is intended for just
that purpose. Let's take it to Email, eh? personal descriptions belong
between persons.
-Allen S. Rout
-He Wears Many Hats
--
<a...@cis.ufl.edu> <a href=http://www.cis.ufl.edu/~asr>My Home Page</a>
<strong> Chameleon Computer Resources: <i> Fits your needs. </i> </strong>
"My marriage is on the rocks, but only because we can't find a blanket."
--==** Rebut me in public; Flame me in Email. Save us both trouble. **==--
Michael I Bushnell
> [Tom Christiansen]
> | [ ... ]
> this is just one of the usages of the Newsgroups header. the
> other, more common, usage is to indicate in which newsgroups the
> article to which the user replies by mail was posted. that is,
> the header is useless, so do not use this header if you wish to
> be as COURTEOUS as you seem to think you are.
If this is "common usage" it is still wrong. References: is
intended for just that purpose. Let's take it to Email, eh?
personal descriptions belong between persons.
Interestingly, it is in fact the usage that Larry Wall chose to
implement in rn.
Hmm.
Michael
Erik Naggum
| > this is just one of the usages of the Newsgroups header. the other,
| > more common, usage is to indicate in which newsgroups the article to
| > which the user replies by mail was posted. that is, the header is
| > useless, so do not use this header if you wish to be as COURTEOUS as
| > you seem to think you are.
|
| If this is "common usage" it is still wrong. References: is intended
| for just that purpose.
"References" is for message-ids. try again.
Scott Schwartz
| Perl is not trying to solve the problems solved by tools like yacc and
| other parsers.
That wasn't what the given example was about. It was a regular
expression over an alphabet of strings. No recursion, no stack, no
parsing, no backtracking.
A more familiar example of what Richard is talking about is seen in
sendmail or zmailer, where the pattern matching operators in the
configuration language are over RFC822 tokens, not over ASCII
characters.
Mark R Kaehny
>
>That wasn't what the given example was about. It was a regular
>expression over an alphabet of strings. No recursion, no stack, no
>parsing, no backtracking.
I actually love Icon, but I don't get this ... If the strings are
made of bytes then perl RE's will work on them also. just use parens.
>
>A more familiar example of what Richard is talking about is seen in
>sendmail or zmailer, where the pattern matching operators in the
>configuration language are over RFC822 tokens, not over ASCII
>characters.
>
If a RE (i.e. a Finite Automata) can recognize these patterns than no,
problem, one can write perl RE's to do so also.
I'm thinking that you using "pattern" to mean "Regular Expression" --
they are not the same. A pattern can be parsable by a context
sensitive grammar, for example, and a RE in ANY language most
certainly cannot. Icon has wonderful iterative "eat up the string"
kind of operators and such and regular expressions but they are not
the same.
Just a note ...
Mark Kaehny
John Burdick
>Actually, perl's main problem is that compiled regexps aren't first-class
>citizens.
Understood. I've been nibbling around the edge of that. In SNOBOL,
patterns are first-class. Since most of the language is about
patterns, they better be. BTW, arrays can only contain scalars, right?
>Regular expressions, by definition, are not recursive. Still, a recursive
>pattern match is certainly a useful thing. Being able to do minimal
>matching in perl rather than only greedy matching makes this at least
>feasible to roll up, but it's not built-in. LArry has often expressed the desire to
>do more interesting pattern specification. Being able to read in a C-style
>brace-block or a lisp S-expr would be convenient. Of course, you can do it now
>using a function, but it's not expressible in one sole regexp due to the
>recursion issue.
Good. I think we agree that perl, as it exists now, runs out of
convenient features at a point that might or might not affect the
sensible use of the language. Other languages have different strengths
and weaknesses. They can all do equivalent work, but with varying
effort.
>By minimal matching, I mean the problem of accessing the string which
>occurs between foo and bar, as in
I know minimal matching from SNOBOL and Icon.
>What do you mean?
> /$pat/
>works, and you can just put the expression you want in the variable.
>if you mean to say
> /^stuff\s*@{[$x = $y]}\s*$/
>then you can get the expression happening in the pattern, but it's
>certainly not the most efficient thing in the world.
I should have said delayed expressions. As I understand it, variables
are evaluated in the external context when the regexp is compiled
before matching starts. Can you use substrings in expressions later in
the same operation so that the value of the expression changes
depending on the incomplete match?
The most interesting examples involve recursion or self modifying
patterns, which really are seperate issues. By self modifying pattern,
I mean like in SNOBOL. You can have an unevaluated function call in a
pattern that returns a pattern. When it is used in a match it's return
value, which is a full pattern, is used for the match attempt. It is
called each time it's needed for an attempt.
>and figure out what to do with the part-way executed thing. In v5.000 and
>higher, there's also a pos() lvauable accessor function and an embeddible
>\G position-assertion that can help.
This sounds like something I wanted to ask about. I don't know how to
test if the pattern is at a particular position, or skip to a
particular postition. Is that because I'm looking at perl 4?
>Not sure what you mean there: perl's regexps are essentially an egrep
>superset. The ease of normal regexps certainly is there. But maybe you
>aren't using the standard definition of regexp.
I mean that using functions to do recursion or working with part way
matches is no longer easy. If you are working on the margin of a tools
ability, it's much harder to use. A more complicated approach might be
easier when perl stops being easy. Icon uses matching procedures,
which are certainly more complicated than regexp symbols, but all the
features of the language support the approach.
John
Matthias Neeracher
> pesc0002@seasnake (Ed Peschko) writes:
>> He replied to your reply... what's wrong with that? Replying to you as well
>> makes sure *you* get a chance to reply as well.
> What's wrong is that he sent me E-mail *and* posted it.
> I saw the mail, and replied to that, but by the time I found out that
> he had posted, I didn't have my reply any more.
> It's a form of deception, that's what's wrong.
It's a form of courtesy which is practised by other people than Tom
Christiansen, too. To ascribe this to malicious intent is not only
rude, but also somewhat uninformed.
>>> The gist of my reply to him was, point after point, that Icon provides
>>> the same functionality or better, and has for rather longer than Perl.
>> If you could give a little bit more than the 'gist'
> You are being rude here. Icon books are for sale. There is a comp.lang.icon
> newsgroup with people who are happy to answer questions about code. Anyone
> who _really_ wants to know what Icon is capable of can ask there.
You were the one making assertions, so it could be expected of you that you
back them up.
> I am unable to give code examples for a very simple reason: I am defending
> a language that I have no proprietary interest in and do not currently have
> installed.
I don't have much experience with Icon either, but as far as I can remember, it
is quite powerful and elegant in the area of pattern matching. It is not as
powerful as Perl in other areas (system calls, output formatting), as far as I
know. In summary, it does the things it does very well, but it doesn't do
everything Perl does.
>> As for the complex expressions, in practical terms I have never, ever come
>> across any regexp problem that was too hard for perl.
> This actually tells us very little. The reason is that if it is too hard
> for Perl, it is automatically classified as 'not a regexp problem'.
> [...]
> What I mean is this kind of thing. My pattern is
> <create>
> ( <setread> <read> *
> | <setwrite> <write> *
> ) *
> <destroy>
> and a typical sequence to match against this pattern is
> ["create", "setwrite", "write", "write", "setread", "read", "destroy"]
The Perl way of dealing with such a problem is to treat it as a context free
grammar instead of a regular expression and apply tools such as pyacc. Given
that such problems are quite likely to *require* a CFG anyway, this doesn't
seem to be such a bad solution.
Matthias
-----
Matthias Neeracher <ne...@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
"And that's why I am going to turn this world upside down, and make
of it a fire so *bright* that someone real will notice"
-- Vernor Vinge, _Tatja Grimm's World_
Ed Peschko
Tom Christiansen <tch...@mox.perl.com> writes:
>:What I mean is this kind of thing. My pattern is
>:
>: <create>
>: ( <setread> <read> *
>: | <setwrite> <write> *
>: ) *
>: <destroy>
>:
>:and a typical sequence to match against this pattern is
>: ["create", "setwrite", "write", "write", "setread", "read", "destroy"]
>:In a realistic example, the array elements are actually complex data structures.
>As I said, perl doesn't attempt to address through its primitives the
>recursive sorts of operations necessary for recursive descent parsing.
>Having written such algorithm in C, pascal, yacc, perl, lisp, scheme, and
>search techniques solve. In raw C, pascal, or perl, it's not a lot of
>fun. You don't have any form of recursive search, blind or otherwise,
But then again, it is quite easy to write a recursive parser in perl. I am
working right now on generalizing the example in the Camel book to
take a yacc-like syntaxed string, a lex-like set of regexps, eval them into
code, and then execute that code, all inside a perl script...
If anybody has already done this -- I am looking for something dynamic, and
portable inside scripts themselves, not static like byacc -- save me some
trouble and post it please!
>That being said, Larry would *like* to have a search engine in perl so you
>could for example, read in an S-expression or a C-style {brace block} wiht
>one simple expression, but I suspect that these days this would be done
>via a library module rather than an addition to the fundamental primitives
>of the language. I certainly wouldn't expect it to be overloaded in the
>regular expression mechanism.
I would like to do this too -- but would like to get some direction on *how* to
do this in a library module:
Basically -- what I would like to do is compile the lex, yacc code that goes
along with say 'gcc' --into an interpreter that lists out a syntax tree, along
with pointers to the beginnings and endings of 'productions' in the syntax tree.
These then could be accessed via their yacc tags.
ie:
xx == 0
would have VARIABLE equal to "xx",
CONDITIONAL equal to "==",
VALUE equal to 0.
and
$VARIABLE[0] eq "xx";
while (/(?$=VARIABLE[0])/g) {
print $1;
}
would print out all occurences of 'xx'.
$VARIABLE[0] eq 'xx';
$VARIABLE[1] eq 'yy';
s/(?$=VARIABLE[0])(.*?)(?$=VARIABLE[1])/$1$2/g;
would substitute all occurrences of xx for yy, with yy directly following xx.
(The use for this escapes me at the moment..)
If anybody is working on this at the moment, I would love to help....
Otherwise, I would really like some pointers on how to start.
Ed
Scott Schwartz
| I actually love Icon, but I don't get this ... If the strings are
| made of bytes then perl RE's will work on them also. just use parens.
As I understand it, the point is that the input doesn't have to be
strings of bytes, and even if it was, perl is only prepared to match
against one string of bytes, so it's not a question of the power of
the re accepting automaton, but rather the generality of the operators
that the language provides.
Anyway, I use and like perl; I'm not arguing for or against, and
probably shouldn't have gotten involved. :-)
Tony J. Kanawati
You can implement tagged records using arrays in Perl, the rest should
follow easily. Of course, you're left with the problem of converting input
into tagged records, and depending on your problem domain, this may be
quite difficult or trivial.
--
"We're sorry, but reality is not in service at this time."
-- stolen tagline
--
--
Antoun (Tony) Kanawati
to...@world.std.com
Tom Christiansen
:Understood. I've been nibbling around the edge of that. In SNOBOL,
:patterns are first-class. Since most of the language is about
:patterns, they better be. BTW, arrays can only contain scalars, right?
Yes, arrays (either linear arrays, like $a[3], or associtative arrays, like
$a{"fred"}, can contain only scalars. But a scalar is a number or a string *or a
reference*. References can point to scalars, list-arrays, table-arrays,
functions, globs, or other references.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
Interestingly enough, since subroutine declarations can come anywhere,
you wouldn't have to put BEGIN {} at the beginning, nor END {} at the
end. Interesting, no? I wonder if Henry would like it. :-) --lwall
Richard A. O'Keefe
> I looked at all the documentation, and what was available for icon.
> I was not really impressed. No code examples, and very little user support.
I should mention that there is a company called Catspaw, Inc.
(P.O.Box 1123 Salida, Colorado 81201, USA)
that provides a range of SNOBOL and Icon-related products, including
a Macintosh Icon. Catspaw : Icon :: perl.com : Perl, I guess.
It is not precisely clear to me what kind of "support" people want.
I told one correspondent that Arizona were actively developing and
maintaining Icon and answer questions well, and was promptly squelched
"oh no, _that_ won't do, that's _centralised_ support, I want _user_ support."
In fact a couple of people wrong things like that to me.
I guess it's a bit like Lisp; Icon programmers just have fun using the
language and don't keep beating their heads against language quirks so
they have very little to say.
Clipper programmers seem mostly to ask "where can I find library Foo"
than "how do I work around this bizarre syntax". Power != obscurity.
Randal L. Schwartz
ozan> i am not sure what it takes to impress anyone these days, but several
ozan> things are worthy of note: ICON has a substantial user population, one
ozan> very good book on the language itself[1], one good book on its internals[2].
ozan> it has been around since early eighties [my copy of the book is dated 1983]
ozan> has been used to anywhere from compiler-compilers[3] to being an extension
ozan> language to a version of emacs. [yes, really. this was done around 84 or so]
ozan> there are versions exist from IBM CMS and MVS to VMS, and all UNIX platforms
ozan> are supported. it is entirely public domain. it comes with an interpreter
ozan> and an optimizing compiler. yes, [in case you were wondering] it has an
ozan> object-oriented extension known as IDOL that provides classes and
ozan> multiple inheritence.
Not only that, but it even has a contribution from *me* in the
standard library. That *must* make it legit. :-)
That's one item each for Perl, Icon, and GNU Emacs. Three big
standards.
Just another multilingual hacker,
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Russell Schulz
tch...@mox.perl.com (Tom Christiansen) writes:
> Wrong? Deception? What *ARE* you talking about?? It was a COURTESY to
> reply to you directly as well as posting. It assures that you see the
> reply, and that you should see it in a timely manner.
this is a nice thing. it can be annoying sometimes (it certainly annoys
me when someone posts drivel and mails a copy to me) but when I ask a
question and I get the answer in mail as well as news, it's wonderful.
> As for deception, perhaps you merely overlooked the header line that
> read Newsgroups: comp.lang.perl, or whatever.
this header has no meaning in mail (simply because it is not listed in
RFC 822). its presence or absence indicates nothing. software which
gives meaning to it (e.g., pine) is in error.
> It indicated that I directed the message to the listed newsgroups as
> well.
as above, no it doesn't. many newsreaders (including rn, if memory
serves) generate a Newsgroups: header on private mail replies which
_never_ get sent to a newsgroup.
news.software.reader comments:
just recently, I forced this newsreader to add a line of the form
Comments: this message originated as a public newsgroup posting
to any mail which was sent to a newsgroup (this includes posting to
moderated groups and using the `CC:' header). it won't help people
using noncompliant packages like pine, but it _will_ help people like
the person Tom mailed from accusing him of deception.
--
Russell Schulz rus...@alpha3.ersys.edmonton.ab.ca ersys!rschulz Shad 86c
Russell Schulz
o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> What's wrong is that he sent me E-mail *and* posted it.
> I saw the mail, and replied to that, but by the time I found out that
> he had posted, I didn't have my reply any more.
isn't this the fault of your mail agent?
mine automatically keeps all mail sent out (stored in a one-level
hierarchical structure, named after the site name, e.g. goanna for
mail sent to Richard at that address). it's very handy. don't
most packages do this now, or is this a rare thing?
br...@liverpool.ac.uk
> Tom Christiansen <tch...@mox.perl.com> wrote:
>> Actually, perl's main problem is that compiled regexps aren't
>> first-class citizens.
> Understood. I've been nibbling around the edge of that. In SNOBOL,
> patterns are first-class. Since most of the language is about
> patterns, they better be. BTW, arrays can only contain scalars,
> right?
Perl is a pragmatic language; it contains features that Larry thought
would be handy, and seems to work well for that. I don't use it
myself, simply because I've never got around to learning it: Perl
scripts look quite incomprehensible to me.
I find it strange that there doesn't seem to be a widely available
language with proper recursive regexps. The Plan 9 editor sam has
them, and there's even a paper discussing a possible awk-like language
using such "structural regular expressions", which looks potentially
invaluable.
This tool (if it even exists?) wouldn't be like icon, for example,
because there's no indication that its expressions would be first
class objects. But I still think such a tool is potentially a killer
app, just like awk is, for those irritating 5-30 line jobs.
--
Bruce Institute of Advanced Scientific Computation
br...@liverpool.ac.uk University of Liverpool
Hans Mulder
>Tom Christiansen <tch...@mox.perl.com> wrote:
>>Actually, perl's main problem is that compiled regexps aren't first-class
>>citizens.
I have more problems with the fact that file handles aren't first-class
citizens.
>Understood. I've been nibbling around the edge of that. In SNOBOL,
>patterns are first-class. Since most of the language is about
>patterns, they better be. BTW, arrays can only contain scalars, right?
Right. But in perl5, references to arrays are considered scalars, and
arrays containing references to other arrays is good enough for me.
>> /^stuff\s*@{[$x = $y]}\s*$/
>I should have said delayed expressions. As I understand it, variables
>are evaluated in the external context when the regexp is compiled
>before matching starts.
Correct.
>Can you use substrings in expressions later in
>the same operation so that the value of the expression changes
>depending on the incomplete match?
Yes, but substrings is wher it stops; in
/foo(.*)bar\1/
the \1 bit is matches the string matched by the first () in the pattern.
If you want anything more complicated \1 with perhaps a repetition
operator, you can't do it in Perl.
>The most interesting examples involve recursion or self modifying
>patterns, which really are seperate issues. By self modifying pattern,
>I mean like in SNOBOL. You can have an unevaluated function call in a
>pattern that returns a pattern. When it is used in a match it's return
>value, which is a full pattern, is used for the match attempt. It is
>called each time it's needed for an attempt.
You can't do that in Perl. That's to say, you can't get Perl's regexp
engine to do all the work for you (like calling your function when needed
and using the pattern it returns). Of course, you can spell out the
algorithm in Perl, but I guess that doesn't count.
>>and figure out what to do with the part-way executed thing. In v5.000 and
>>higher, there's also a pos() lvauable accessor function and an embeddible
>>\G position-assertion that can help.
>This sounds like something I wanted to ask about. I don't know how to
>test if the pattern is at a particular position, or skip to a
>particular position. Is that because I'm looking at perl 4?
Yes, \G is a new feature in perl5. You might be able to use length($`) to
figure out where the match starts, but I seem to remember that inperl4 that
doesn't work well with the /g modifier due to a bug. In perl5 that bug has
been solved, but now that we now have pos() and \G, and we no longer care.
>>Not sure what you mean there: perl's regexps are essentially an egrep
>>superset. The ease of normal regexps certainly is there. But maybe you
>>aren't using the standard definition of regexp.
>I mean that using functions to do recursion or working with part way
>matches is no longer easy.
The definition of "regular" in my book doesn't allow recursion. If you
have recursion, it's a context-free language (at best). Matching against
a context-free language is an interesting question (and yacc is not the
answer), but I'm pretty sure Larry wouldn't want to extend Perl's regexps
that far. Okay, he's a bit beyond strictly regular, e.g. the set of
strings matching
/a(b*)c\1d\1e/
is not regular (in the technical sense of the word), but Perl hasn't gone
very far beyond strictly regular. Yet.
>If you are working on the margin of a tools ability, it's much harder to
>use. A more complicated approach might be easier when perl stops being easy.
>Icon uses matching procedures, which are certainly more complicated than
>regexp symbols, but all the features of the language support the approach.
If Icon does what you as fast as you want it to happen, then by all means
use Icon. Perl is good at some things and less good at other thigns. If
you want to do those other things, you're better off with another language.
--
Hope this helps,
HansM ha...@win.tue.nl
A screwdriver is better than a hammer: I tried to take the cover off
of my coffee machine with a hammer instead of a screwdriver, and now
my coffee machine has a big hole in it. Also a screwdriver hurts less
when you drop it on your foot.
Larry Wall
Michael I Bushnell <m...@duality.gnu.ai.mit.edu> wrote:
: In article <ASR.95Ma...@rock.cis.ufl.edu> a...@rock.cis.ufl.edu (Allen S. Rout) writes:
:
: > [Tom Christiansen]
: > | [ ... ]
: > this is just one of the usages of the Newsgroups header. the
: > other, more common, usage is to indicate in which newsgroups the
: > article to which the user replies by mail was posted. that is,
: > the header is useless, so do not use this header if you wish to
: > be as COURTEOUS as you seem to think you are.
:
: If this is "common usage" it is still wrong. References: is
: personal descriptions belong between persons.
:
: Interestingly, it is in fact the usage that Larry Wall chose to
: implement in rn.
Yes, I did. Though the statute of limitations may have run out by now...
Larry
Larry Wall
Matthias Neeracher <ne...@iis.ee.ethz.ch> wrote:
: In article <3ocvj8$j...@goanna.cs.rmit.edu.au> o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
: > pesc0002@seasnake (Ed Peschko) writes:
: >> He replied to your reply... what's wrong with that? Replying to you as well
: >> makes sure *you* get a chance to reply as well.
:
: > What's wrong is that he sent me E-mail *and* posted it.
: > I saw the mail, and replied to that, but by the time I found out that
: > he had posted, I didn't have my reply any more.
: > It's a form of deception, that's what's wrong.
: It's a form of courtesy which is practised by other people than Tom
: Christiansen, too. To ascribe this to malicious intent is not only
: rude, but also somewhat uninformed.
Nonetheless, I've also been irqued by the same unintentional deception.
I usually try to put "[also posted]" before the attribution line when I
do that. A technological solution would be welcome though. Anyone wanna
rewrite Pnews?
Larry
Ed Peschko
>>Ed Peschko [amongst other things, writes about ICON]:
>> I looked at all the documentation, and what was available for icon.
>> I was not really impressed. No code examples, and very little user support.
>It is not precisely clear to me what kind of "support" people want.
>I told one correspondent that Arizona were actively developing and
>maintaining Icon and answer questions well, and was promptly squelched
>"oh no, _that_ won't do, that's _centralised_ support, I want _user_ support."
>In fact a couple of people wrong things like that to me.
If it is *all* centralized, then there is a frightening possibility for
prospective users: an institution is beating a 'dead horse'. They are
creating the language, and pushing it on the market simply because they
have the resources to do so.
This says nothing about the user community behind it. It could say that the
'University of Arizona has lots of RA money that it is willing to give
undergraduates in time of need.' I *know* that they do this all the time in the
case of my alma mater.
>I guess it's a bit like Lisp; Icon programmers just have fun using the
>language and don't keep beating their heads against language quirks so
>they have very little to say.
Well -- then they should be shouting HIGH and PROUD about what they are doing!
ICON programmers should be actively promoting the language they love: making
code reservoirs, cool ways of doing things,etc.. I see none of that.
Or they should have an active newsgroup, interactive newsletters, etc to tell
the world their accomplishments.
This of course, assumes that there is a large enough population of ICON
programmers to do all of this..
Remember -- a LIVE language does not have to stay that way. It can easily be
killed.
Ed
(PS: I am not sure whether this is the case with ICON or not. My first hunch
might indeed have been wrong about ICON, but I would like to get a list of
script/program repositories before looking into the matter further.)
Paul Smith
%% lw...@netlabs.com (Larry Wall) writes:
lw> In article <NEERI.95M...@yggdrasil.ethz.ch>,
lw> Matthias Neeracher <ne...@iis.ee.ethz.ch> wrote:
lw> : It's a form of courtesy which is practised by other people than Tom
lw> : Christiansen, too. To ascribe this to malicious intent is not only
lw> : rude, but also somewhat uninformed.
lw> Nonetheless, I've also been irqued by the same unintentional
lw> deception. I usually try to put "[also posted]" before the
lw> attribution line when I do that. A technological solution would
lw> be welcome though. Anyone wanna rewrite Pnews?
No need. The new rewrite of GNUS for Emacs [(ding) GNUS] does this
automatically, and invisibly (that is, it adds a notation to the email
but not the post).
As I'm sure Larry can attest to when he receives this via email :)
What? You're not using Emacs to read USENET? Well, I have no response
to that! :)
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Carl Brewer
Paul Smith <psm...@wellfleet.com> wrote:
[chop]
>What? You're not using Emacs to read USENET? Well, I have no response
>to that! :)
No, I thought I'd use UNIX instead ... :)
--
ca...@oversteer.library.uwa.edu.au
#include <generic_disclaimer.h>
finger cbr...@uniwa.uwa.edu.au for my pgp public key
Peter da Silva
Larry Wall <lw...@netlabs.com> wrote:
> Nonetheless, I've also been irqued by the same unintentional deception.
> I usually try to put "[also posted]" before the attribution line when I
> do that. A technological solution would be welcome though. Anyone wanna
> rewrite Pnews?
Well, I've already hacked Rnmail to default to using "X-Newsgroups" instead
of "Newsgroups" so it should be trivial to add a comment to the complementary
string in Pnews.
Kudos, by the way. These little interpreted strings make it easy to work
around things like the Pine Newsgroups-line-in-mail braindamage.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Har du kramat din varg idag?"
David Disser
Larry> In article <NEERI.95M...@yggdrasil.ethz.ch>,
Larry> Matthias Neeracher <ne...@iis.ee.ethz.ch> wrote:
>> It's a form of courtesy which is practised by other people than Tom
>> Christiansen, too. To ascribe this to malicious intent is not only
>> rude, but also somewhat uninformed.
Larry> Nonetheless, I've also been irqued by the same unintentional
Larry> deception. I usually try to put "[also posted]" before the
Larry> attribution line when I do that. A technological solution
Larry> would be welcome though. Anyone wanna rewrite Pnews?
Larry> Larry
You just need a better newsreader, Larry. (ding) Gnus handles the
courtesy copy quite elegantly.
--Dave
Tom Christiansen
In comp.lang.perl,
dis...@engin.umich.edu (David Disser) writes:
Don't be ludicrous: If Larry wanted to run the emacs operating system
instead of Unix, I'm sure he would. Likewise, if he wanted to program in
the emacs programming language instead of perl, I'm sure he would do that
too. And of course, if he wanted to run the emacs newsreader rather than
(t)rn, I'm fairly certain that he would know how to go about doing that.
So far, however, none of these would seem to be the case. And it's not
clear that his reasno for not doing so is as closely tied to his having
written a couple of those programs as you might think. :-)
Anyway, it's not the newsreader that's at fault here. If anything, it's
merely the Pnews program, which should long ago have been rewritten.
Every time I start the onerous procedure of translation, I shudder and
back away.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
PL/1, "the fatal disease", belongs more to the problem set than to the
solution set.
--E. W. Dijkstra
Roy M. Silvernail
ca...@oversteer.library.uwa.edu.au (Carl Brewer) writes:
> In article <p5n3gus...@lemming.wellfleet.com>,
> Paul Smith <psm...@wellfleet.com> wrote:
>
> [chop]
>
>>What? You're not using Emacs to read USENET? Well, I have no response
>>to that! :)
>
> No, I thought I'd use UNIX instead ... :)
That's OK... I hear UNIX will run under Emacs.
Oh.
;-)
- --
Roy M. Silvernail [ ] r...@cybrspc.mn.org
"You want it in one line? Does it have to fit in 80 columns? :-)"
--Larry Wall in <73...@jpl-devvax.JPL.NASA.GOV>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBL7LysRvikii9febJAQHE4wP/fCJenrWseatMAmSvKfEMTAzKS+Uxx5cJ
9Ch2LKRPEyfz2H0tVO49J1jXIPqwJcDeyfeQUgZIu9wIHmGXIqpPDWdSpV9uEIkW
imejxJs39MUHdDh1WL3ACWDfTRUF2sxuyM/t+4MCWpv9QJNOeclwg5U2WpaXLX9k
5j6qdQrvL80=
=z/Rf
-----END PGP SIGNATURE-----
Craig Burley
ca...@oversteer.library.uwa.edu.au (Carl Brewer) writes:
> In article <p5n3gus...@lemming.wellfleet.com>,
> Paul Smith <psm...@wellfleet.com> wrote:
>
>>What? You're not using Emacs to read USENET? Well, I have no response
>>to that! :)
>
> No, I thought I'd use UNIX instead ... :)
That's OK... I hear UNIX will run under Emacs.
Not very well. The "# " shell prompt frequently gets temporarily
overwritten with "Garbage collecting...", which is really annoying
while typing a command to the shell.
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
David N Gray
> I find it strange that there doesn't seem to be a widely available
> language with proper recursive regexps.
You might want to take a look at "gema" in:
http://www.ugcs.caltech.edu/gema/
It's not a programming language, but it is a pattern-matching text
processor that does support recursive patterns.
Richard L. Goerwitz
>
>Professor Ralph Griswold have created Icon and "pushed it on the market"
>in precisely the same way and sense that Larry Wall has created and
>pushed Perl....
Actually, Larry and Ralph have philosophies that are about as different
as night and day. And they have radically different goals in mind when
they distribute their software.
--
Richard L. Goerwitz *** go...@midway.uchicago.edu
Marc Espie
Richard L. Goerwitz <go...@midway.uchicago.edu> wrote:
>Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> wrote:
>>
>>Professor Ralph Griswold have created Icon and "pushed it on the market"
>>in precisely the same way and sense that Larry Wall has created and
>>pushed Perl....
>
>Actually, Larry and Ralph have philosophies that are about as different
>as night and day. And they have radically different goals in mind when
>they distribute their software.
>
>--
Would you mind being more explicit ?
Except that I use perl5 and icon regularly, and love them both (well, icon
a bit more than perl5 except for details like name spaces and modules
actually), I don't know enough about these great guys to see the difference
clearly. It seems to me it would be interesting to know, since both approachs
to programming languages have produced such lively interesting languages
(not gratuitous praise, but the way I think).
--
[nosave]<http://acacia.ens.fr:8080/home/espie/index.html>
`Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai)
`鮎川 のことー好きだよ。' (あの日に帰りたい)
Marc Espie (Marc....@ens.fr)
Cliff Hathaway
>: I looked at all the documentation, and what was available for icon.
At ftp.cs.arizona.edu, in the /icon/library directory,
there is a substantial body of Icon source code, some developed
locally, much of it contributed by the Icon community.
Here's an excerpt from the READ.ME file from that directory:
==========================================================================
This directory contains Version 9.0 of the Icon program library. The
library is the same for all platforms, just the packaging is different.
The 9.0 library comes in three parts:
info documentation and installation information
bipl basic programs and procedures
gipl graphics programs and procedures
===============================================================================
The info.tar file is 139 KB, bipl.tar is 2.73 MB, and gipl.tar is 2.53 MB.
User support is available from icon-p...@cs.arizona.edu, and from the
Icon community through the comp.lang.icon newsgroup, and the icon-group
mailinglist (icon-...@cs.arizona.edu).
Source code, executables, and the Icon program library are also available
on magnetic media for small fees to cover duplicating costs, shipping, and
handling.
Richard L. Goerwitz
>>
>>Professor Ralph Griswold have created Icon and "pushed it on the market"
>>in precisely the same way and sense that Larry Wall has created and
>>pushed Perl....
>
>Actually, Larry and Ralph have philosophies that are about as different
>as night and day. And they have radically different goals in mind when
>they distribute their software.
I was asked by several people to elaborate on this. I've known Ralph for
a decade now, more or less, and I've found Icon to be one of the cleanest
languages around. I've written tons of real-world Icon apps. These typ-
ically take about a fifth of the time that an equivalent C job would take,
and are less buggy to boot. And because Icon handles memory, and works on
such a high level, I find I can write hundreds - even thousands - of lines
of Icon code, and have stuff work pretty much the way I intended on the
first compile.
Still, I would not call Icon an everyman's language. Ralph is interested
in language design and, lately, in visualization and interfaces. It was
never designed to be an all-purpose system administration tool - a kind
of super awk-sh-sed-C like Perl, and in fact Ralph would probably have
shrunk in horror from Larry's attempt at mingling the syntax of these
languages. I mean, I doubt he would ever have considered designing Icon
this way because his goals had a lot to do with language design - not
with helping Unix systems analysts get work done.
Now that Perl has finally gotten away from purely flat data structures,
though, and has streamlined its syntax, it looks to be an ideal super C.
The kind of thing you can do serious system administration tasks with,
and yet remain on a high level. It has interfaces with many windowing
systems and toolkits, as well as database systems, and, well, just about
anything you'll really need on a Unix system. Perl is obviously a great
tool.
But it's nothing like Icon. Completely different beasts.
Piercarlo Grandi
Richard> Let's see: Fortran is still alive,
I remember the old statement "I don't know what language many/most
programmers will be using in year 2000, but I know it will be called
Fortran".
Richard> COBOL is still alive, Basic is still alive, MUMPS is still
Richard> alive, APL is still alive, Lisp is still alive, people are
Richard> _still_ (much to my astonishment) using Jovial,
Well, Jovial astonishes me too. But in fact it is actually a pretty good
language, uner many respects; as a little nuggest, it is the only
language I have ever seen (and I have seen _lots_ -- how many Neliac :->
programmers are still out there?) that has the concept of parallel
vs. serial layout of arrays of records, which is rather important (the
only other place I have seen it mentioned is in Hoare's "On data types",
in "Structured Programming", one of the least read books in computer
history).
Moreover, I might be terribly wrong, but Jovial is still installed by
default on Bull mainframes (just like algol 60).
Richard> I've got a SNOBOL system so SNOBOL is still alive, Intercal is
Richard> still alive, PL/I is still alive (IBM are pushing it hard on
Richard> OS/2; it has a lot of new stuff in it), Pascal is still alive,
Richard> I picked up a free Simula compiler not so long ago so Simula 67
Richard> is still alive, Prolog is still alive, ... You know, it is
Richard> remarkably hard to kill a language.
Easier to kill a spoken language than a computer language... Perhaps
they are far stronger "meme"s.
Larry Wall
: >
: >Professor Ralph Griswold have created Icon and "pushed it on the market"
: >in precisely the same way and sense that Larry Wall has created and
: >pushed Perl....
:
: Actually, Larry and Ralph have philosophies that are about as different
: as night and day. And they have radically different goals in mind when
: they distribute their software.
By and large, I'd have to concur (though I think we're both interested
in helping people). Icon is a cat language, and Perl is a dog language.
Larry Wall
lw...@netlabs.com
Arthur Chance
(Larry Wall) writes:
> Icon is a cat language, and Perl is a dog language.
I think I know what you mean, but would you care to give definitions
or examples to clarify? Or is there to much risk of a metalevel flame
war about which languages are cat/dog like? :-) * 0.5
--
"People can and will do things that no one could possibly believe anyone
would do. For examples look at most of human history or the alt.sex.*
hierarchy." -- Ken Boucher on human stupidity in sci.nanotech
Larry Wall
Arthur Chance <art...@Smallworld.co.uk> wrote:
: In article <1995May17.1...@netlabs.com> lw...@netlabs.com
: (Larry Wall) writes:
: > Icon is a cat language, and Perl is a dog language.
:
: I think I know what you mean, but would you care to give definitions
: or examples to clarify? Or is there to much risk of a metalevel flame
: war about which languages are cat/dog like? :-) * 0.5
I think it's best left as a right-brain thingie.
Larry
Luis Fernandes
> Moreover, I might be terribly wrong, but Jovial is still
> installed by default on Bull mainframes (just like algol 60).
... and Jovial programs are also running on some part of the
flight-systems of the C-17 (the future replacement for the C-130
cargo transport) which is currently in "beta".
br...@liverpool.ac.uk
So it does! I wonder why it's not more widely known about? (archie
can't find any other sites for it, for example.) Looking at the
example scripts, they look utterly yucky, but presumably that's just
my unfamiliarity with the tool.
The closest I've seen to the tool I want is somebody rambling about
a Scheme-based equivalent to awk. Possibly part of scsh, I don't
remember exactly. Probably I'll be able to use guile, once it's
settled down a bit.