My first exposure to a seriously higher level language than C
was Icon. (Thank you Ralph Griswold, et al.) Finally, I got around
to learning lisp, where I wish I had started, and found that much
of what I liked about Icon (automatic storage, everything is an
expression, lists, tables, success->value/failure->nil) was there
in Common Lisp with a (shall we say) different syntax (and a whole
lot more, of course).
Has anyone implemented any other of our favorite iconish things
in Common Lisp or Scheme? Like goal-directed evaluation,
string scanning, ... ?
--dave yost
In article <······················@adobe.com> ····@adobe.COM (David Yost) writes:
Has anyone implemented any other of our favorite iconish things
in Common Lisp or Scheme? Like goal-directed evaluation,
string scanning, ... ?
I've implemented equivalents of (all?) the Icon string scanning
operations in Scheme. They are part of a collection of string
scanning functions I put together which draw on the facilities of
many different languages. Because of this, the names aren't the same
as in Icon, but that is simple to solve. The following are a few
of examples :-
; Icon `trim(s, c)' like operations :-
>(string:trim-right "Betelgeuse " char-set:whitespace)
"Betelgeuse"
> (string:trim-left-and-right "XXsomestuffXX" (char-set:from-string "X"))
"somestuff"
;Icon `bal(c1, c2, c3, s, i, j)'
;
> (let ((str "((2*x)+3)+(5*y)"))
> (string:general-find-balanced-chars
> str
> (char-set:from-string "+")
> (char-set:from-string "(")
> (char-set:from-string ")")
> 0
> (string-length str)
> (lambda (position continuation result) position)
> (lambda (result) #f)
> 'dummy-argument))
9
;Icon `map(s1, s2, s3)'.
> (string:map "hxmysz" "hx:my:sz" "03:56:42")
"035642"
>(string:map "123321" "123" "-*|")
"-*||*-"
; This is a special case of the Icon functions `find(s1, s2, i, j)'
; and `upto(c, s, i, j)', where `char' is considered
; as a string containing one character for `find' or a character set
; containing one character for `upto'
; The following is meant to show how the _second_ `i' in the string
; can be found
>(string:general-find-char
> "this is a dummy"
> #\i
> 0
> 15
> (lambda (pos k r) (if (= r 1) pos (k (+ 1 r))))
> (lambda (r) "could not find the character at all")
> 0)
5
The syntax is more verbose than Icon and also relies on some
understanding of CPS programming. Personally I don't find the syntax
a problem, as I always hide it behind another function whose name fits
with the application being written and which supplies any necessary
default arguments e.g. the start/end point in
`string:general-find-char' above. CPS on the other hand might put a
lot of people off. IMHO if you understand Icon's generators and
co-expressions, you should have no problems with continuations (at
least not with the way they are being used in the above code)
If anybody is interested in the code, it is freely available via a
mailserver attached to my account. Just send the following message,
and you should get all the information you need :-
To: ·····@cs.man.ac.uk
Subject: b-server-request
send help
send index
send scheme/index
Note if you have a UUCP or Swiss mail addresses, you can try the
above, but experience shows that they don't often work :-<
Stephen J. Bevan ·····@cs.man.ac.uk
In article <······················@adobe.com> ····@adobe.COM writes:
>My first exposure to a seriously higher level language than C
>was Icon. (Thank you Ralph Griswold, et al.) Finally, I got around
>to learning lisp, where I wish I had started, and found that much
>of what I liked about Icon (automatic storage, everything is an
>expression, lists, tables, success->value/failure->nil) was there
>in Common Lisp with a (shall we say) different syntax (and a whole
>lot more, of course).
>
>Has anyone implemented any other of our favorite iconish things
>in Common Lisp or Scheme? Like goal-directed evaluation,
>string scanning, ... ?
Personally, I feel good about Common LISP. It's even more bloated than
Icon, though, and people who are really into clean LISP dialects seem
to prefer Scheme. LISP, of course, isn't object-oriented (yes, another
level of indirection that seems to be the rage these days). LISP
people are always quick to point out that you can do object-oriented pro-
gramming in LISP, but this is also true of C, Pascal, or even assembler.
The bottom line, I guess, is that we have to be bi- or better yet tri-
lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps a func-
tional or object-oriented language, and PERL, sed, awk, etc.). You'll
never get into AI (or Emacs :-)) without LISP, and you'll never run any
thing in real time without C. You won't get elegant string scanning
outside of Icon. You won't get your system adminstration work done un-
less you can do shell and awk/sed programming (or PERL).
My gut feeling is that you'll be better off using Icon and LISP, Dave,
when either is appropriate.
--
-Richard L. Goerwitz ··········@uchicago.bitnet
····@ellis.uchicago.edu rutgers!oddjob!ellis!goer
From: Clinton Jeffery
Subject: Re: features from Icon Language in lisp
Date:
Message-ID: <15341@optima.cs.arizona.edu>
From article <·····················@midway.uchicago.edu>, by ····@ellis.uchicago.edu (Richard L. Goerwitz):
> In article <······················@adobe.com> ····@adobe.COM writes:
>>Has anyone implemented any other of our favorite iconish things
>>in Common Lisp or Scheme? Like goal-directed evaluation,
>>string scanning, ... ?
[Since he hasn't posted a response yet, I'll tattle.]
David Gudeman developed an approach to doing generators and goal-directed
evaluation in Scheme using a continuation model. I don't think the work
went past the proof-of-concept stage. The Lisp world is big and old and
someone may well have done more along these lines, but you should ask *them*.
> Personally, I feel good about Common LISP.
Common Lisp is the Ada of the Lisp community. Icon isn't the Ada of anything.
> LISP, of course, isn't object-oriented
There are serious and well-done object-oriented variants of Lisp, including
Flavors and CLOS.
> LISP
> people are always quick to point out that you can do object-oriented pro-
> gramming in LISP, but this is also true of C, Pascal, or even assembler.
CLOS and Flavors provide real OO support, just as C++ does for C and Simula
does for Algol. The point is that being based on a pre-existing language
does not preclude support for objects. The same is true of Icon.
> The bottom line, I guess, is that we have to be bi- or better yet tri-
> lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps...
I disagree. "One language to rule them all, One language to find them,
One language to bring them all, And in the darkness Bind them." But
seriously, no language has a monopoly on any of its intellectual
contributions: someone else can come along and do string scanning better
than Icon, and the same can be said for most of the other "domains" for
which you claimed I'd need one of these specialty languages. Given that
claim, I reason that its possible to come along with a new language that
generalizes and subsumes more than one domain as "the best language".
> My gut feeling is that you'll be better off using Icon and LISP, Dave,
> when either is appropriate.
This part I agree with for pragmatic reasons, I just think Dave should
go ahead and add "suspend" to his Lisp if he needs it, and not have to
switch to Icon to get the feature. I sure as heck intend to add
features to (my personal version of) Icon when they are truly needed...
In article <·····················@midway.uchicago.edu> ····@midway.uchicago.edu writes:
>LISP, of course, isn't object-oriented
Heavens! I guess you haven't hear of Common Lisp Object System, which is
IMHO considerably more advanced than the usual other suspects. Anyone
interested in OO programming in any language should read Object Oriented
Programmin in Lisp by Sonya Keene. CLOS is a standard part of Common Lisp
now.
--dave yost
In article <·····················@adobe.com> ····@adobe.com (David Yost) writes:
>>LISP, of course, isn't object-oriented
>
>Heavens! I guess you haven't hear of Common Lisp Object System, which is
>IMHO considerably more advanced than the usual other suspects. Anyone
>interested in OO programming in any language should read Object Oriented
>Programmin in Lisp by Sonya Keene. CLOS is a standard part of Common Lisp
>now.
Guess I haven't, Dave. But then my familiarity with LISP stopped with kcl
and akcl :-). I just don't do things that require LISP, and so I've largely
left it off. That and Prolog (for similar reasons).
Incidentally, what is this about CLOS? An extended version of Common LISP?
Pretty amusing. Is this really elegant, fast, etc.? Or are we all talking
about the kind of bloat that probably, in part, inspired Scheme? Just curi-
ous.
--
-Richard L. Goerwitz ··········@uchicago.bitnet
····@ellis.uchicago.edu rutgers!oddjob!ellis!goer
Date: Wed, 15 Apr 1992 12:43 EDT
From: "Richard L. Goerwitz" <····@ellis.uchicago.edu>
LISP, of course, isn't object-oriented (yes, another
level of indirection that seems to be the rage these days). LISP
people are always quick to point out that you can do object-oriented pro-
gramming in LISP, but this is also true of C, Pascal, or even assembler.
This will come as a real surprise to the people who have been using CLOS
(Common Lisp Object System, a part of the X3J13 Common Lisp standard,
and supported by all major Lisp vendors) for the past several years, and
Flavors, New Flavor, Loops, etc., some of which have been around since
about 1980.
Date: Wed, 15 Apr 1992 12:43 EDT
From: "Richard L. Goerwitz" <····@ellis.uchicago.edu>
LISP, of course, isn't object-oriented (yes, another
level of indirection that seems to be the rage these days). LISP
people are always quick to point out that you can do object-oriented pro-
gramming in LISP, but this is also true of C, Pascal, or even assembler.
This will come as a real surprise to the people who have been using CLOS
(Common Lisp Object System, a part of the X3J13 Common Lisp standard,
and supported by all major Lisp vendors) for the past several years, and
Flavors, New Flavor, Loops, etc., some of which have been around since
about 1980.
From: Jeff Dalton
Subject: Re: features from Icon Language in lisp
Date:
Message-ID: <6620@skye.ed.ac.uk>
In article <····················@CRAWLER.SCRC.Symbolics.COM> ···@sapsucker.scrc.symbolics.com (Scott McKay) writes:
>
> Date: Wed, 15 Apr 1992 12:43 EDT
> From: "Richard L. Goerwitz" <····@ellis.uchicago.edu>
>
> LISP, of course, isn't object-oriented (yes, another
> level of indirection that seems to be the rage these days). LISP
> people are always quick to point out that you can do object-oriented pro-
> gramming in LISP, but this is also true of C, Pascal, or even assembler.
>
>This will come as a real surprise to the people who have been using CLOS
>(Common Lisp Object System, a part of the X3J13 Common Lisp standard,
>and supported by all major Lisp vendors) for the past several years, and
>Flavors, New Flavor, Loops, etc., some of which have been around since
>about 1980.
Moreover, the way you "can do" OOP in Lisp is rather nicer than
the way you "can do" it in C, Pascal, or even assembler.
Remember that C++ wasn't just some definitions written in C.
On the other hand, such capabilities can be added to Lisp just
by writing some Lisp.
In article <······················@adobe.com> ····@adobe.COM (David Yost) writes:
Has anyone implemented any other of our favorite iconish things
in Common Lisp or Scheme? Like goal-directed evaluation,
string scanning, ... ?
Warning: I really have only a reading knowledge of Icon. All the
programs I wrote in Icon were very small.
One Icon feature I particularly like is the smooth, automatic handling
of generators. In Icon, a generator is an operation such as FIND that
is capable of producing a series of results instead of just one. In
particular, if an iterator such as EVERY is waiting (directly or
indirectly) for the generator's result, it will sequentially get all
of them; if a goal-seeker such as > (comparison) is waiting for the
generator's result, it sequentially gets each of them unless/until the
goal is satisfied. All of this happens without any need for
compile-time declarations.
Dick Waters' SERIES package has some of the same capabilities, but it
needs to know at compile time (via declarations, explicit mapping
functions, inlining, etc.) which values are series and which are not.
Here's an interesting research topic: What degree of substrate support
would suffice to efficiently support a more dynamic use of series, a
la Icon?
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.