Has anyone tried to write a language (or a set of extensions to Lisp)
that has the basic functionality of Perl (easy pipes, pattern
matching, and string processing) with straightforward Lisp-like syntax
and flexible data structures? I'm currently using Perl and Common
Lisp, and I wish I could combine their strengths. Please send mail (I
don't have the time anymore to read netnews thoroughly!) if you have
or know of any system similar to what I'm getting at, or know of Lisp
tools I could use to build it.
Thanks! You may save me many hours of weekend labor...
Wheeler
--
Wheeler Ruml, Aiken 220, ····@eecs.harvard.edu, (617) 496-1066 (fax)
http://www.das.harvard.edu/users/students/Wheeler_Ruml/Wheeler_Ruml.html
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl,
····@isla.eecs.harvard.edu (Wheeler Ruml) writes:
:Has anyone tried to write a language (or a set of extensions to Lisp)
:that has the basic functionality of Perl (easy pipes, pattern
:matching, and string processing) with straightforward Lisp-like syntax
:and flexible data structures? I'm currently using Perl and Common
:Lisp, and I wish I could combine their strengths. Please send mail (I
:don't have the time anymore to read netnews thoroughly!) if you have
:or know of any system similar to what I'm getting at, or know of Lisp
:tools I could use to build it.
It's been too long for me to recall all that lisp offers -- what kinds of
data structures are you looking for? Perl has a pretty rich set of
first-class data and code thingies, including strings and numbers (even
bignums), arrays (lists) and associative arrays (alists), objects and
references and closures, plus some o-o tricks for transparently
intercepting variable access to transparently trigger user-defined fetch
and store (etc) methods. I have a document at http://perl.com/perl/pdsc/
that starts to talk about some of these in more detail that other perl
documentation does.
What other stuff would you be looking for?
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker ·······@mox.perl.com
A formal parsing algorithm should not always be used.
--D. Gries
Tom Christiansen <·······@mox.perl.com> writes:
> [courtesy cc of this posting sent to cited author via email]
>In comp.lang.perl,
> ····@isla.eecs.harvard.edu (Wheeler Ruml) writes:
>:Has anyone tried to write a language (or a set of extensions to Lisp)
>:that has the basic functionality of Perl (easy pipes, pattern
>:matching, and string processing) with straightforward Lisp-like syntax
>:and flexible data structures? I'm currently using Perl and Common
>:Lisp, and I wish I could combine their strengths. Please send mail (I
>:don't have the time anymore to read netnews thoroughly!) if you have
>:or know of any system similar to what I'm getting at, or know of Lisp
>:tools I could use to build it.
hm... I'd consider Emacs Lisp, which I have played with some:
1. Built in string manipulation (strings up to 24MB in length).
2. You can use it to edit binary files.
3. regular expressions, pattern matching, etc.
4. piping is possible, at least (I believe it's possible to use
emacs as a shell, among other things).
5. looks like lisp (well, to me, at least--I'd only used Scheme
otherwise).
additional benefits:
1. GPL.
2. Built in editor :)
3. interpreted *and* compiled.
4. Can be run, and programmed, interactively (like other lisps).
5. Manuals on the web (so you can get started now).
Anyway, it's something to consider. As for its power, remember that a
very goodly portion of Emacs is written directly in Emacs Lisp.
>It's been too long for me to recall all that lisp offers -- what kinds of
>data structures are you looking for? Perl has a pretty rich set of
>first-class data and code thingies, including strings and numbers (even
>bignums), arrays (lists) and associative arrays (alists), objects and
>references and closures, plus some o-o tricks for transparently
>intercepting variable access to transparently trigger user-defined fetch
>and store (etc) methods. I have a document at http://perl.com/perl/pdsc/
>that starts to talk about some of these in more detail that other perl
>documentation does.
>What other stuff would you be looking for?
>--tom
>--
>Tom Christiansen Perl Consultant, Gamer, Hiker ·······@mox.perl.com
> A formal parsing algorithm should not always be used.
> --D. Gries
--
NEW ADDRESS! Bryan K. Ogawa <·······@netvoyage.net> II Infinitum <><
In article <··········@csnews.cs.colorado.edu>, Tom Christiansen
<·······@mox.perl.com> writes:
|> What other stuff would you be looking for?
parentheses ... :-) I mean a clear, regular syntax :-)
:Has anyone tried to write a language (or a set of extensions to Lisp)
:that has the basic functionality of Perl
Well, plenty. I am a bit ashamed of the current state of my FAQ in this
domain (see ftp://koala.inria.fr/pub/EmbeddedInterpretersCatalog.txt), but
I would cite: xlisp ELI ELK J Oscheme and many schemes (SCM,
scheme-48....) see: http://www.cs.indiana.edu/scheme-repository/home.html
with a special mention to mine, "Klone" at ftp://koala.inria.fr/pub/Klone,
and to THE gnu one, "guile" (based on the SCM scheme) that promises to
compete with the "big three" (tcl/perl/python). Klone is a descendant from
Wool use in the X window manager GWM, but different enough to warrant a
new name.
I plan also to set up a web forum to discuss what features are important
in a language, so that all major languages should benefit from what we
learn with our galaxy of experimental ones. Take for instance the last one
I came up with: "unquotable strings" ("raw strings" in Klone)
The idea is to use (optionally) a control-character to quote strings and
not allowing this character inside the string. for Klone it is ^^
(control-caret) as it is visually pleasing. This allows very confortable
"mixed programming" where you deal with a lot of strings to pass to other
string-processing programs, such as HTML browsers for CGI scripting, or
sending to a wish (tcl/Tk) subprocess... think of it: no more escaping
quotes! arent you tired of writing:
"set a \"foo bar\""
just use:
^^set a "foo bar"^^
--
Colas Nahaboo, Koala, BULL @ INRIA Sophia, http://www.inria.fr/koala/colas
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
·····@aye.inria.fr (Colas Nahaboo) writes:
:|> What other stuff would you be looking for?
:parentheses ... :-) I mean a clear, regular syntax :-)
A clear regular syntax? Ok....
:The idea is to use (optionally) a control-character to quote strings and
:not allowing this character inside the string. for Klone it is ^^
:(control-caret) as it is visually pleasing. This allows very confortable
: think of it: no more escaping
:quotes! arent you tired of writing:
: "set a \"foo bar\""
:just use:
: ^^set a "foo bar"^^
So, you're asking for a nice syntax in one breath and going and ADDING
CONTROL CHARACTERS to your language in the next???
Does this seem MIGHTY STRANGE to anyone else but me?
It would seem that the obvious solution for legibility is to use paired
delimiters of your choice to avoid having to escape stuff and so it's easy
to match up. Traditional languages and even lisp or scheme have always
used brackets for this, although which flavor of bracket has varied.
Certainly tcl proved how useful it was as a quoting mechanism to have
paired curley brackets for single quoting and leave paired square ones for
execution stuff. This is a fine precedent, don't you think? I wonder why
no one has does this before? We just need to be able to do something like
this for double quotes and we're set.
Hm... I have this *absolutely radical* notion. Let's use a reasonable
functional notation for all our quoting rather than adding more funky
characters. I'll just use qq() for double quote, so
qq(set a "foo bar")
would mean a double-quoted string literal, but the embedded double quotes
wouldn't need escaping. So you could interpolate your variables if you'd
like, as in
qq(set a "foo $something bar")
And you wouldn't have to escape the double quotes. Of course, if you had
another round bracket in the inside, it would be a problem just as it
already is in other round, curley, or square bracket expression.
Hmm... let's say you can use ANY bracket type after the qq() stuff.
It's not precisely a real function anyway. That way you could avoid
qq(set a "foo $something \( bar")
and instead use
qq{set a "foo $something ( bar"}
or
qq[set a "foo $something ( bar"]
Hey, I got another wild idea. Since we already have this nice
variant qq() notation for double quoting, let's use q() for single
quoting:
q(set a "i'm not ready")
q[set a "i'm not ready"]
q{set a "i'm not ready"}
Nifty!
Another thing that I've always appreciated on one hand and disliked
syntactically on the other is ksh's notation of $(cmd args) notation
instead of `cmd args`, which is certainly confusing. It's nice that the
round brackets are paired and nest and all for those execution quotes, but
it's sure not very consistent with the way the other quoting stuff we've
been developing works.
Oh, of course. What *WAS* I thinking!? It's an eXecutution Quote!
qx(cmd args)
qx[cmd args]
qx{cmd args}
Well, look at that. I think that takes care of all these funny
pseudo-literals in a nice, clean, regular fashion. I wonder why
no smart language designer has ever used this before?
I guess they actually have, haven't they? Must have been that crazy Ken
Thompson guy or something. I realize that perhaps you lisp people
probably don't realize it, but all the standard UNIX editors have always
tolerated not just the
s/foo/bar/g
sort of syntax, but also the versatile alternate form of choosing
your own delims to aid in avoiding ugly backslashitis:
s,foo/bar,other,g
Heck, in vi, you could even say neato stuff like
s!\(foo\)/\(bar\)!\u\1/xxx/\u\2!g
Ugly those it is, it's sure useful.
Too bad it wouldn't have been the far more legible
s!(foo)/(bar)!\u\1/xxx/\u\2!g
s(foo/bar)(\u&)g
s((foo)/(bar))(\u\1/xxx/\u\2)g
or even
s[(foo)/(bar)][\u\1/xxx/\u\2]g
s[(foo/bar)][\u\1]g
You know, like the way it works in tr:
tr[a-z][A-Z]
or our fine q(), qq(), and qx() pseudo-literals that we just,
er, invented. :-)
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker ·······@mox.perl.com
You have made an excellent hit on the UNIX.--More--
For the Scheme Shell I borrowed a trick from LaTeX's \verb command and most
shell's "here documents" (the <<EOF redirection mechanism for including
constant data to be presented on a file descriptor).
You can write long string constants with strange constituent characters
in scsh using "here strings." There are two kinds of here string:
character delimited, and line delimited.
A character-delimited here string looks like
#<|"She's forgotten the \verb command, again," said James.|
The syntax is
- sharp, less than,
- a delimiter character of your choice,
- the string,
- the delimiter character.
There is absolutely no interpretation of the chars between your
delimiters. Backslashes, double quotes, single quotes -- whatever. It's all
just taken verbatim. The example above is *exactly* equivalent to writing
"\"She's forgotten the \\verb command, again,\" said James."
in Scheme, and you can write either in scsh, interchangeably.
The one character you may not use as a delimiter in a character-delimited
here string is "<". This is used to introduce line-delimited here strings.
A line-delimited here string looks like this:
#<<Casey at the bat
The outlook wasn't brilliant,
For the Mudville Nine that day,
The score stood two to four,
With but one inning more to play.
Casey at the bat
The syntax is
- sharp, double less than,
- a delimiter line,
- the string,
- the delimiter line.
Again, no interpretation at all of interior characters. (I chose not to get
into the complexities of somehow embedding variable substitution expressions
inside the strings, as shells allow. The Scheme solution is to embed ~a's and
then use the string in a FORMAT expression.)
These syntaxes are covered in a little more detail in the scsh manual.
I added them to the language to make it easier to write long, multi-line
strings, such as chunks of text written in other languages (e.g., Awk,
or sed, or grep, or Perl), inside scsh scripts. Having to apply all
the Scheme string conventions for escaping the right magic characters
would have been obfuscatory and error prone, so I made this alternate
mechanism.
Here strings are new in release 0.4; I have no idea if people will like them.
You can pick up the sources or the manual for the new release at
http://www-swiss.ai.mit.edu/scsh/scsh.html
-Olin
>>> Wheeler Ruml writes:
In article <··················@isla.eecs.harvard.edu> ····@isla.eecs.harvard.edu (Wheeler Ruml) writes:
> Has anyone tried to write a language (or a set of extensions to
> Lisp) that has the basic functionality of Perl (easy pipes,
> pattern matching, and string processing) with straightforward
> Lisp-like syntax and flexible data structures? I'm currently
> using Perl and Common Lisp, and I wish I could combine their
> strengths. Please send mail (I don't have the time anymore to
> read netnews thoroughly!) if you have or know of any system
> similar to what I'm getting at, or know of Lisp tools I could use
> to build it.
The Scheme Shell is what you are looking for!
-bri
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This is a release of scsh, release 0.4.0.
Scsh is a Unix shell that is embedded within R4RS Scheme.
It provides high-level shell notation and full access to
the Unix system calls. The current implementation is built
on top of Scheme 48, version 0.36.
We currently have scsh running on:
AIX,
CXUX,
HP-UX,
IRIX,
Linux,
NetBSD,
NeXTSTEP,
Solaris,
SunOS,
Ultrix
It's not hard to port scsh to new systems.
You can get a copy of scsh via anonymous ftp, from the following:
ftp://clark.lcs.mit.edu/pub/su/scsh/scsh.tar.gz
ftp://swiss-ftp.ai.mit.edu/pub/su/scsh/scsh.tar.gz
These tar files include a detailed manual and a paper describing
the design of the system.
For the lazily curious, we also have the manual separately available as
ftp://clark.lcs.mit.edu/pub/su/scsh/scsh-manual.ps
ftp://swiss-ftp.ai.mit.edu/pub/su/scsh/scsh-manual.ps
Just click 'n view.
The current release is primarily useful for writing shell scripts
and doing general systems programming.
Real interactive use needs a parser for an sh-like syntax, job control,
and the gnu readline library. If you're interested in hacking
on these things, drop us a line at ··················@ai.mit.edu.
We've got designs for most of this stuff; we're just short on time
and bodies.
New in this release:
- The scsh network package, a complete interface for Berkeley-style sockets.
We are going to keep the code for our higher-level protocols (ftp, telnet,
http, and so forth) close to home for one more release.
- The awk loop and field parser package.
These two packages are documented in the reference manual.
Lots of plans for the next release: libraries with network protocol code,
the html parser and the server kit, module switches on the command line,
threads -- we'll do our best.
We thank Brent Benson, Travis V. Broughton, Brian Dennis, Noah Friedman Mike
Gunter, Shriram Krishnamurthi, John P. Lewis, Tom Lord, Scott Schwartz, and
Bill Sommerfeld, Michael Sperber, Axel Wienberg, for bug reports, bug fixes,
and comments that were incorporated into this release.
Brought to you by the Scheme Underground scsh team.
-Olin Shivers, Brian Carlstrom & David Albertz
Cambridge
25 December, 1994
Quoth Tom Christiansen <·······@mox.perl.com>:
> :matching, and string processing) with straightforward Lisp-like syntax
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
> :Lisp, and I wish I could combine their strengths. Please send mail (I
^^^^^^^^^^^^^^^^^^^^^^^
Hmm, reading in and between the lines, I think he is pretty clearly
saying that he wants something close to the syntax and everyday
semantics and library of Common Lisp, but with the regexps and pipes
and similar scripting language conveniences that Perl offers. That is
not an unreasonable desire, IMHO. Many of us want that, too. In any
case, he explicitly mentioned a straightforward Lisp-like syntax.
> It's been too long for me to recall all that lisp offers -- what kinds of
^^^^^^^^^^^^^
> data structures are you looking for? Perl has a pretty rich set of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here I think it's fair to say that you did not answer his question.
Let's say for the sake of the discussion that Perl has all the data
structure flexibility of CLOS and more. Then unless Perl has made
some truly unprecedented changes recently, it is still the case that
its syntax is very different from Lisp.
To me and others, Perl is the most different from Lisp in syntax of
any programming language in widespread use today. Perhaps to you Perl
and Lisp have similar syntax. Speaking as somebody who has looked
closely at Perl (before Perl 5) but rejected it almost solely on the
basis of its syntax, I find that an extraordinary opinion!
Perl has many features, even unusual things Lisp has like
multiple-value-setq. But I would not call its syntax like Lisp.
> What other stuff would you be looking for?
I presume that he wants, as many of us do, a Lisp that does easy pipes
and fast regexps. I would be satisfied with a fast, small CL with
built-in regexps and threads, but know of nothing perfect yet.
In addition to gcl, cmucl, clisp, and commercial Lisps, he might
consider such programs as scsh, guile, various other schemes, emacs
lisp (emacs -batch), and xlisp. Some of these might require foreign
functions. Some (the CL's) can implement partial regexps in Lisp
itself. Some have them built in. They have varying piping
capabilities and varying startup speeds and sizes. I happen to prefer
CL, so the progress in speed and Unixisms by scheme compilers is only
relevant to me inasmuch as they have improving CL libraries as well.
Until I get a suitably CLish, fast, small, regexping Lisp, I'm
sticking with zsh and all those little Unix utilities, not Perl, for
most shell scripts, We're not too far away from what we need, and some
(such as some of the above scheme authors) think we're there already.
If you post a followup to this article, please also send a courtesy
verbatim copy by email to help work around potentially unreliable
feeds.
---
Have you learned something today?
Have you taught something today?
Have you exercised free speech today?
···@ptolemy.arc.nasa.gov. AI, multidisciplinary neuroethology, info filtering.
In article <··········@csnews.cs.colorado.edu> Tom Christiansen <·······@mox.perl.com> writes:
: think of it: no more escaping
:quotes! arent you tired of writing:
: "set a \"foo bar\""
:just use:
: ^^set a "foo bar"^^
It would seem that the obvious solution for legibility is to use paired
delimiters of your choice to avoid having to escape stuff and so it's easy
to match up. Traditional languages and even lisp or scheme have always
used brackets for this, although which flavor of bracket has varied.
Hm... I have this *absolutely radical* notion. Let's use a reasonable
functional notation for all our quoting rather than adding more funky
characters. I'll just use qq() for double quote, so
qq(set a "foo bar")
This is far more offensive (to me) than just using the \ to escape embed "'s.
I am not tired of writing:
"set a \"foo bar\""
but I would be truly nauseous if I had to, instead, type:
qq(set a "foo bar")
or any other intrusive notation that obscures the meaning.
How does this stike you:
"foo bar ``baz snark'' quux"
where the `` and '' get magically re-written into:
"foo bar \"baz snark\" quux"
Far less kludgey than what you proposed but if your hell-bent on eliminating
the \" then this at least is no more characters the \' and it also does not
require use of the SHIFT key to generate parens (on my keyboard).
So what if you want to embed a `` or '' literally within your strings?
Easy...
# #
# # # # # ####
# # # # # # #
# # # ###### # #
# # # # # # #
# # # # # # #
## ## # # ####
##### ### ###
# # ## ##### ###### #### ### ###
# # # # # # # ### ###
# # # # # ##### #### # #
# ###### ##### # #
# # # # # # # # # ### ###
##### # # # # ###### #### ### ###
Love,
ziggy
(chuckle)
--
------------------------------------------------------------------------------
Michael R. Blair --. ·····@ai.mit.edu | MIT Artificial Intelligence Lab
(617) 253-0765 \\ ···@lcs.mit.edu | MIT Labor. for Computer Science
,,Lambda Calculus... /\\_ ...uber alles!'' | 545 Technology Square--Room 439
http://www-swiss.ai.mit.edu/~ziggy/ziggy.html| Cambridge, MA USA 02139-3594
>>>>> "ET" == Ed Tobin <·····@onramp.net> writes:
ET> Scheme. Perl! scheme-perl?
ET> Here's an interesting solution to the original request for a lispish
ET> perl. From the depts of the Perl Archives: sp.pl
Hey, that's some way-cool code. I have only one question: Why? :-)
Michael.