Just recently it dawned on me the existence of yet another language in
the already overcrowded area of scripting languages. It comes, on the
wave of other cool inventions like Tamagotchi and Karaoke, from Japan.
Its name is Ruby. The hint to a better Perl is somehow implicit in
the name. If the interpretation is not correct at least is not too
far from reality.
Ruby embodies loads of fresh new features, like garbage collection,
exceptions, closures, an object system and regular expressions
facilities. Features you might not have see before all in the same
language.
It forgets about the awful semicolon at end of statement and
introduces something I would call "syntax scoping" (the scope of a
variable is implicit in the name). A big improvement over Python's
indentation sensitivity and Perl's prefix characters!
Now a lambda expression doesn't need to be a feast of brackets like:
(lambda (x y) (+ x y))
but can be simply typed as:
{|x,y| x + y}
In an interview the author (Yukihiro Matsumoto) gives a short but very
effective description of his child: "Ruby is a relatively simple
language, but not too simple like Lisp and Smalltalk".
As you may expect from such a successful language there is already a
book (O'Really), several libraries and annual conferences, let alone
thousands of fanatics all around the world ready to produce tons of
code in this Esperanto of the Internet Age.
:-)
--
walter pelissero
http://www.pelissero.org
> In an interview the author (Yukihiro Matsumoto) gives a short but very
> effective description of his child: "Ruby is a relatively simple
> language, but not too simple like Lisp and Smalltalk".
>
Wow! I think that this is the first time I have EVER heard Lisp accused
of being "too simple". I've heard "too complex", and "just right", but
this is unique in my limited experience. Given sufficient features (and
certainly Lisp has tremendous riches), is simple bad?
Nels
Nels Tomlinson <········@purdue.edu> writes:
> > In an interview the author (Yukihiro Matsumoto) gives a short but very
> > effective description of his child: "Ruby is a relatively simple
> > language, but not too simple like Lisp and Smalltalk".
> >
>
> Wow! I think that this is the first time I have EVER heard Lisp
> accused of being "too simple". I've heard "too complex", and "just
> right", but this is unique in my limited experience. Given sufficient
> features (and certainly Lisp has tremendous riches), is simple bad?
>
> Nels
My guess is that in the above quote Lisp = ELisp and/or
Scheme. Someone should introduce this guy to Common Lisp. It does
everything Ruby does, AND it's compiled!!
Thom
--
Thom Goodsell ···@cra.com
Scientist (617) 491-3474 x574
Charles River Analytics http://www.cra.com/
On 2001-08-02 17:02:43Z, Thom Goodsell <···@cra.com> wrote:
> Scheme. Someone should introduce this guy to Common Lisp. It does
> everything Ruby does, AND it's compiled!!
Well, still searching for native code compilers for Linux.
Without paying more than 500 EUR. With libraries for GTK+, ...
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-02 17:02:43Z, Thom Goodsell <···@cra.com> wrote:
> > Scheme. Someone should introduce this guy to Common Lisp. It does
> > everything Ruby does, AND it's compiled!!
>
> Well, still searching for native code compilers for Linux.
> Without paying more than 500 EUR. With libraries for GTK+, ...
CMUCL compiles to native code, as does SBCL (a cmucl fork). It comes
with CL/X and CLM, and you can find a list of some other graphics
libraries (most of which should work in CMUCL) here:
<http://ww.telent.net/cliki/Graphics%20Toolkit>, including 3 different
ways to bind to GTK+. And, costing 0 EUR, it's within your price
range :)
On 2001-08-03 08:25:42Z, Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> ······@no-spoon.de (Stefan Scholl) writes:
>
> > On 2001-08-02 17:02:43Z, Thom Goodsell <···@cra.com> wrote:
> > > Scheme. Someone should introduce this guy to Common Lisp. It does
> > > everything Ruby does, AND it's compiled!!
> >
> > Well, still searching for native code compilers for Linux.
> > Without paying more than 500 EUR. With libraries for GTK+, ...
>
> CMUCL compiles to native code, as does SBCL (a cmucl fork). It comes
No! It's surely an important feature to compile to native code.
Why isn't it mentioned in the documentation?
Show me how to compile CLOS code on Linux with CMUCL. All I get
is a silly FASL file.
> with CL/X and CLM, and you can find a list of some other graphics
CLX is very low level.
> libraries (most of which should work in CMUCL) here:
> <http://ww.telent.net/cliki/Graphics%20Toolkit>, including 3 different
> ways to bind to GTK+. And, costing 0 EUR, it's within your price
> range :)
There's no link to download CLIM. CL/gtk is dead.
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-03 08:25:42Z, Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> > ······@no-spoon.de (Stefan Scholl) writes:
> >
> > > On 2001-08-02 17:02:43Z, Thom Goodsell <···@cra.com> wrote:
> > > > Scheme. Someone should introduce this guy to Common Lisp. It does
> > > > everything Ruby does, AND it's compiled!!
> > >
> > > Well, still searching for native code compilers for Linux.
> > > Without paying more than 500 EUR. With libraries for GTK+, ...
> >
> > CMUCL compiles to native code, as does SBCL (a cmucl fork). It comes
>
> No! It's surely an important feature to compile to native code.
> Why isn't it mentioned in the documentation?
>
> Show me how to compile CLOS code on Linux with CMUCL. All I get
> is a silly FASL file.
Those x86f files that it generates are native code. Try compiling a
function then disassembling it. If what you're asking for is the
ability to deliver applications in a single file, executable from the
command line without any command-line options, that's a different
beast. But you can certainly deliver apps with CMUCL : compile your
lisp files (to native code), load them into a fresh image, dump a core
containing your application, and ship cmucl, your core, and a little
program that runs cmucl with your core and starts your app. If you
want everything to be all compiled code everywhere, make that last
little program written in C -- it doesn't *have* to be a shell script,
even if that's generally easier.
> > with CL/X and CLM, and you can find a list of some other graphics
>
> CLX is very low level.
Yes, and CLM is not.
> > libraries (most of which should work in CMUCL) here:
> > <http://ww.telent.net/cliki/Graphics%20Toolkit>, including 3 different
> > ways to bind to GTK+. And, costing 0 EUR, it's within your price
> > range :)
>
> There's no link to download CLIM. CL/gtk is dead.
Who was talking about CLIM? FWIW, there *is* a link to McCLIM,
though. You're right that cl-gtk looks abandoned, but clg just had
another release in April.
In article <·····················@parsec.no-spoon.de>,
Stefan Scholl <······@no-spoon.de> wrote:
>Show me how to compile CLOS code on Linux with CMUCL. All I get
>is a silly FASL file.
Doesn't the FASL file contain functions compiled to native code?
I suspect what you're really asking about is how to create an executable
file, rather than a file that must be loaded into the Lisp interpreter. In
most Lisp systems this is done by loading the file into the Lisp
interpreter and then saving the environment to disk in a new file; this
will be an executable file. The disk-save operation typically takes
options to let you specify what should happen when you restart it
(e.g. invoking a function instead of the REPL). Check the CMUCL
documentation for the details.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-03 08:25:42Z, Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> > ······@no-spoon.de (Stefan Scholl) writes:
> >
> > > On 2001-08-02 17:02:43Z, Thom Goodsell <···@cra.com> wrote:
> > > > Scheme. Someone should introduce this guy to Common Lisp. It does
> > > > everything Ruby does, AND it's compiled!!
> > >
> > > Well, still searching for native code compilers for Linux.
> > > Without paying more than 500 EUR. With libraries for GTK+, ...
> >
> > CMUCL compiles to native code, as does SBCL (a cmucl fork). It comes
>
> No! It's surely an important feature to compile to native code.
> Why isn't it mentioned in the documentation?
>
> Show me how to compile CLOS code on Linux with CMUCL. All I get
> is a silly FASL file.
OK, that's native code, probably.
What you probably mean is "I want a standalone executable". There are
many reasons why this isn't what you get from a lisp compiler
(usually), because you still need the runtime support from the general
lisp system.
However, you can distribute your fasl along with cmucl and then do
some binfmt_misc hackery to allow
$ ./hello.x86f
Hello, world!
$ ls -l ./hello.x86f
-rwxr-xr-x 1 csr21 users 2 Jul 30 17:42 hello.x86f
[ actual size may be larger than that ]
This is not different from C programmes requiring the C runtime, gtk+
programmes requiring libgtk, and so on. It's at times like this that I
sympathize greatly with Dan Barlow's (cute) idea of packaging up sbcl
with the runtime in a package called libsbcl and the executable in a
package of its own.
Basically, you're confused. Be clearer about your needs, and explain.
Cheers,
Christophe
PS: Perhaps this is a good time to mention here an irregularly
maintained updated FAQ, the html version of which I'm keeping at
<URL:http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html>; feel free
to feed me answers and questions... I note wryly that I don't have the
answer to the above FAQ in there yet. Oh well.
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> What you probably mean is "I want a standalone executable". There are
> many reasons why this isn't what you get from a lisp compiler
> (usually), because you still need the runtime support from the general
> lisp system.
That is what shared libraries are for.
If you build Kawa using GCJ (the GCC-based Java implementation), Kawa
gets compiled and installed as a shared library libkawa.so plus a
small executable. You can compile your Scheme application (or in
theory a Common Lisp application though not enough CL is implemented
to be useful) using Kawa+GCJ to a modest ELF executable that
dynamically loads libkawa.so just like libc.so is loaded. (You also
have the option of using static linking instead of shared libraries.)
--
--Per Bothner
···@bothner.com http://www.bothner.com/per/
Per Bothner wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> What you probably mean is "I want a standalone executable". There are
>> many reasons why this isn't what you get from a lisp compiler
>> (usually), because you still need the runtime support from the general
>> lisp system.
>
> That is what shared libraries are for.
>
> If you build Kawa using GCJ (the GCC-based Java implementation), Kawa
> gets compiled and installed as a shared library libkawa.so plus a
> small executable. You can compile your Scheme application (or in
> theory a Common Lisp application though not enough CL is implemented
> to be useful) using Kawa+GCJ to a modest ELF executable that
> dynamically loads libkawa.so just like libc.so is loaded. (You also
> have the option of using static linking instead of shared libraries.)
How is the speed of GCJ compiled Scheme compared to other native
Scheme-Compilers?
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> How is the speed of GCJ compiled Scheme [using Kawa] compared to
> other native Scheme-Compilers?
I don't know - I haven't done any benchmarks. I tend not to get complaints
about Kawa's speed (with or without GCJ) - not that *I* am satisfied!
I assume it will be slower than Stalin, but then Stalin does some
fairly serious optimizations at the whole-program level, and my
impression it is less featureful.
--
--Per Bothner
···@bothner.com http://www.bothner.com/per/
On 2001-08-07 03:43:11Z, Per Bothner <···@bothner.com> wrote:
> I assume it will be slower than Stalin, but then Stalin does some
> fairly serious optimizations at the whole-program level, and my
> impression it is less featureful.
Yeah, Stalin has killed more people. :-(
Who on earth calls a program Stalin? Is there a profiler called
Hitler?
Sick programmers. :-(
Stefan Scholl wrote:
>
> On 2001-08-07 03:43:11Z, Per Bothner <···@bothner.com> wrote:
> > I assume it will be slower than Stalin, but then Stalin does some
> > fairly serious optimizations at the whole-program level, and my
> > impression it is less featureful.
>
> Yeah, Stalin has killed more people. :-(
>
> Who on earth calls a program Stalin? Is there a profiler called
> Hitler?
No, that's Molotov. And the debugger is Beria. ;-)
> Sick programmers. :-(
Yeah.
Larry
······@no-spoon.de (Stefan Scholl) wrote in message news:<·····················@parsec.no-spoon.de>...
> Well, still searching for native code compilers for Linux.
> Without paying more than 500 EUR. With libraries for GTK+, ...
Will CMUCL suffice?
It's GTK+ bindings aren't yet perfect, but hey, it's free!
--
Eugene.
On 2001-08-03 09:06:01Z, Eugene Zaikonnikov <······@funcall.org> wrote:
> ······@no-spoon.de (Stefan Scholl) wrote in message news:<·····················@parsec.no-spoon.de>...
>
> > Well, still searching for native code compilers for Linux.
> > Without paying more than 500 EUR. With libraries for GTK+, ...
>
>
> Will CMUCL suffice?
FASL? No way.
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-03 09:06:01Z, Eugene Zaikonnikov <······@funcall.org> wrote:
> > ······@no-spoon.de (Stefan Scholl) wrote in message news:<·····················@parsec.no-spoon.de>...
> >
> > > Well, still searching for native code compilers for Linux.
> > > Without paying more than 500 EUR. With libraries for GTK+, ...
> >
> >
> > Will CMUCL suffice?
>
> FASL? No way.
Somehow, I get the impression that you are missing something.....
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-03 09:06:01Z, Eugene Zaikonnikov <······@funcall.org> wrote:
> > ······@no-spoon.de (Stefan Scholl) wrote in message news:<·····················@parsec.no-spoon.de>...
> > > Well, still searching for native code compilers for Linux.
> > > Without paying more than 500 EUR. With libraries for GTK+, ...
> >
> >
> > Will CMUCL suffice?
>
> FASL? No way.
FASL is a binary object format, much as a.out is a binary object
format, much as ELF and DWARF and COFF are binary object formats.
If you had ELF in mind, you presumably would have said so; otherwise,
I suggest that you may not know what FASL is.
If you want ELF binaries instead of FASL binaries, you might want to
look into the Eclipse CL implementation, which generates C, or into
GCL, which similarly generates C, both of which could then generate
ELF binaries.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hyperusa.com/~cbbrowne/sap.html
Rules of the Evil Overlord #84. "I will not have captives of one sex
guarded by members of the opposite sex."
<http://www.eviloverlord.com/>
Nels Tomlinson <········@purdue.edu> writes:
> > In an interview the author (Yukihiro Matsumoto) gives a short but very
> > effective description of his child: "Ruby is a relatively simple
> > language, but not too simple like Lisp and Smalltalk".
> >
>
> Wow! I think that this is the first time I have EVER heard Lisp accused
> of being "too simple". I've heard "too complex", and "just right", but
> this is unique in my limited experience. Given sufficient features (and
> certainly Lisp has tremendous riches), is simple bad?
He probably meant "... like Smalltalk and Lisp, Ruby is simple but not
*too* simple".
In article <··············@hyde.lpds.sublink.org>, Walter C. Pelissero wrote:
>Now a lambda expression doesn't need to be a feast of brackets like:
>
> (lambda (x y) (+ x y))
But that feast of parentheses is also a piece of data if you
want it to be.
>but can be simply typed as:
>
> {|x,y| x + y}
So it's a feast of braces, commas, bars and infix. It's basically just
syntactic sugar that creates a representational gap between code and data.
In article <··············@hyde.lpds.sublink.org>, Walter C. Pelissero wrote:
>Its name is Ruby. The hint to a better Perl is somehow implicit in
>the name. If the interpretation is not correct at least is not too
>far from reality.
Note that ``better perl'' is a ridiculously modest goal.
>Ruby embodies loads of fresh new features, like garbage collection,
>exceptions, closures, an object system and regular expressions
>facilities.
What is so fresh about these decades-old ideas?
>Features you might not have see before all in the same
>language.
Common Lisp has them all, except regular expressions, for which
libraries can be found.
>It forgets about the awful semicolon at end of statement and
>introduces something I would call "syntax scoping" (the scope of a
>variable is implicit in the name). A big improvement over Python's
>indentation sensitivity and Perl's prefix characters!
Python's indentation sensitivity, albeit somewhat controversial, is
a deliberate feature, not an accident. The people who invented the
language that way would probably disagree that the lack of it is an
``improvement'', and they make a number of good arguments which justify
it.
>Now a lambda expression doesn't need to be a feast of brackets like:
>
> (lambda (x y) (+ x y))
>
>but can be simply typed as:
>
> {|x,y| x + y}
A feast of parentheses is replaced by a mishmash of braces, bars, commas
and infix notation. Can this form be treated as data in Ruby?
Can it be constructed by the program?
The idea in Lisp is to have a uniform surface syntax for everything,
so that you can get past the syntax and into manipulating the structure.
Why is there a comma separating x and y in |x,y|? That is just
as awful as a semicolon for terminating statements. Why not just |x y|?
For that matter, why use a another character, wouldn't {{x y} x + y}
serve just as well? Or perhaps that would create some ambiguity due to
other quirks in the syntax.
>As you may expect from such a successful language there is already a
>book (O'Really), several libraries and annual conferences, let alone
>thousands of fanatics all around the world ready to produce tons of
>code in this Esperanto of the Internet Age.
That could be a good analogy. The world needs another programming
language about as much as it needs Esperanto.
On 2001-08-02 15:36:36Z, Kaz Kylheku <···@ashi.footprints.net> wrote:
> The idea in Lisp is to have a uniform surface syntax for everything,
> so that you can get past the syntax and into manipulating the structure.
Uniform?
( ) , ' ` ,@ . # ;
······@no-spoon.de (Stefan Scholl) writes:
> On 2001-08-02 15:36:36Z, Kaz Kylheku <···@ashi.footprints.net> wrote:
> > The idea in Lisp is to have a uniform surface syntax for everything,
> > so that you can get past the syntax and into manipulating the structure.
>
> Uniform?
>
> ( ) , ' ` ,@ . # ;
Contrary to what the bogus tllotbafir document that compares Python
(argh! I said the word) with Lisp. The CL syntax *is* uniform.
The only thing you must really remember are
(<op> <arg1> <arg2> ... <argN>)
the rules for ' and : and the fact that '#' introduces special
markers. End of the story. The '#' character is particularly
important because it establishes another very regular part of CL
syntax.
*Then* (i.e. after you got acquainted with the previous stuff) you can
to delve into backquote mysteries and format directives.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
······@pelissero.org (Walter C. Pelissero) writes:
> Its name is Ruby. The hint to a better Perl is somehow
> implicit in the name.
You really should post this to comp.lang.misc, and not on
comp.lang.lisp. I'd crosspost and set a Followup-To, but i don't
have access to that newsgroup here.
Since I have some opinion about Ruby, I'm going to talk about it
and compare it to Perl where necessary. I'm not going to compare
Ruby to Common Lisp. You're in comp.lang.lisp, it shouldn't
surprise you that people around here prefer Lisp over other
languages. ;)
When I took a look at Ruby some time ago, I enjoyed one thing a
lot. With ensure, it supports a contract model, which is very
nice. Otherwise, though, the language didn't impress me too
much. "Better then Perl" isn't that difficult, so it's not
surprising that Ruby achieves that. Sadly, it carries on the
Perl idea that "short syntax is good syntax", but most of the
time, short syntax is just confusing syntax. Also, the natural
language isn't a good model to use for a programming language.
Postfix "if" etc. are a pain to understand. Another wart would
be that Ruby requires prefix characters to specify the type of a
variable ($ is global, @ is an instance variable, and if it
starts with a capital letter, it's a constant). Especially $ and
@ are just as a good idea as Hungarian Notation. But what really
makes the language bad in my opinion is that it continues the
perl idocity of using global variables all the time, e.g. Ruby
still has $_ and friends. Luckily, the semantics are not as
broken as in the older versions of Perl.
Greetings,
-- Jorgen
--
((email . ·······@mindless.com") (www . "http://forcix.cx/")
(irc . ·······@#StarWars (IRCnet)") (gpg . "1024D/028AF63C"))
Oops, I belive the smiley at the end of the article wasn't sufficient
to make clear it was a deliberate provocation.
Beside the fact that I didn't get a particularly good impression of
the few things I've seen of the language, the reason behind my article
was that sentence in Matsumoto's interview. Even if you read it as
"like Lisp and Smalltalk, Ruby is a simple language", is funny enough.
--
walter pelissero
http://www.pelissero.org
Jorgen 'forcer' Schaefer wrote:
>
> ······@pelissero.org (Walter C. Pelissero) writes:
>
> > Its name is Ruby. The hint to a better Perl is somehow
> > implicit in the name.
> When I took a look at Ruby some time ago, I enjoyed one thing a
> lot. With ensure, it supports a contract model, which is very
> nice. Otherwise, though, the language didn't impress me too
> much. "Better then Perl" isn't that difficult, so it's not
> surprising that Ruby achieves that.
I learned Perl 4, and always held off from Perl 5, possibly because of
the grafted-in OO, perhaps because of the blizzard of new punctuation
syntax...
When I found (and worked with) Ruby, I was up to speed quite quickly,
found OO to be integrated from the jump, and found the syntax much
simpler than Perl.
> Postfix "if" etc. are a pain to understand.
I find them quite natural. Perhaps it's Perl quirks, or English quirks,
but.... they're not bad if you're used to Perl. See a "postfix if" in
that sentence?
> Another wart would
> be that Ruby requires prefix characters to specify the type of a
> variable ($ is global, @ is an instance variable, and if it
> starts with a capital letter, it's a constant).
That makes it quite plain which is which; saves you from seeing a local
variable obscure a global one, since they're now separate variables
entirely.
> But what really
> makes the language bad in my opinion is that it continues the
> perl idocity of using global variables all the time, e.g. Ruby
> still has $_ and friends.
I'm not sure what you mean by this. Ruby uses local variables for
everything; global variables are to be avoided. $_ is a system
variable, not a global variable exactly. Ruby is also designed not just
as a better Perl, but as a Perl replacement: it should be easier for a
Perl user to learn. So it is; and so some things in Perl have been
propogated.
David Douthitt <·····@mailbag.com> writes:
> [snip]
It was a mistake to post in this thread. I didn't want to start
a flame war about anyones favorite language, and comp.lang.lisp
is surely not the place to argue wether perl or ruby is better.
Everyone has a right to chose their own favorite language.
Followup-To: poster
Greetings,
-- Jorgen
--
((email . ·······@mindless.com") (www . "http://forcix.cx/")
(irc . ·······@#StarWars (IRCnet)") (gpg . "1024D/028AF63C"))
In article <··············@hyde.lpds.sublink.org>, Walter C. Pelissero wrote:
>Now a lambda expression doesn't need to be a feast of brackets like:
>
> (lambda (x y) (+ x y))
>
>but can be simply typed as:
>
> {|x,y| x + y}
It occurred to me, and I though it would be worth mentioning, that in
Lisp, if you hack around with your read table to dispatch an entirely
trivial custom reader macro, you can also come up with a terse, ugly
notation for entering closures. ;)
Try, for instance, this:
(defun alternate-lambda-reader (stream char arg)
(declare (ignore char arg))
(let*
((lambda-list (read stream t))
(items (read-delimited-list #\} stream t)))
`(lambda ,lambda-list ,items)))
(set-dispatch-macro-character #\# #\{ #'alternate-lambda-reader)
(set-macro-character #\} (get-macro-character #\) nil))
Now you can write
#{(x y) + x y} ; 10 non-whitespace characters, like the Ruby code
instead of
(lambda (x y) (+ x y))
Happy? Or does arbitrary serial line noise have to parse to satisfy
your evident craving for obfuscation? ;)
Now show an example of how Ruby can adapt its superficial syntax to
at least loosely imitate something else.
Kaz Kylheku wrote:
> Now show an example of how Ruby can adapt its superficial syntax to
> at least loosely imitate something else.
I'm not sure how this all got started, but Ruby and LISP are two totally
different animals. There's places that LISP would be used instead of
Ruby, and vice versa.
LISP is faster, uses lots of memory, and isn't necessarily OO. Ruby is
OO, interpreted, and is designed for "scripting" (not for programs), and
is slower.
Of course, Ruby will run on a 486 with 16M of memory and no hard disk;
can LISP do that? :-)
David Douthitt <·····@mailbag.com> writes:
> Kaz Kylheku wrote:
>
> > Now show an example of how Ruby can adapt its superficial syntax to
> > at least loosely imitate something else.
>
> I'm not sure how this all got started, but Ruby and LISP are two totally
> different animals. There's places that LISP would be used instead of
> Ruby, and vice versa.
>
> LISP is faster, uses lots of memory, and isn't necessarily OO. Ruby is
> OO, interpreted, and is designed for "scripting" (not for programs), and
> is slower.
Uh, all Lisps are OO. The name OO is sometimes co-opted by non-Lisps for
purposes other than the original meaning of OO. The true meaning of OO
was "identity-oriented programming"; that is, data are first-class objects
whose objects identities are not gratuitously copied in argument-passing.
Sometime later, historically, someone came up with this notion
of OO as relating to encapsulation, which is a style of programming
orthogonal to the question of whether a system is OO; it is a data
abstraction violation even to ask how something is programmed. True OO-ness
should be detectable just by watching the nature of the flow of data
(is it based on pointers to objects? is dynamic type checking available on
such objects at any time? are only whole objects passed?), without knowing
the implementation of the functions...
See http://world.std.com/~pitman/PS/Name.html for more on this topic
of co-opted names.
So within YOUR choice of terms, our comparative description may be right,
but please use other terms here in this forum. The Lisp community has
had the term OO locked down for a long time and has a right to its own
usage.
It's fine if you want to say "Lisp isn't necessary what people
these days seem to be calling OO (i.e., doesn't have true encapsulation)."
Then again, by using such terminology here, that makes your meaning more
clear, you'll perhaps find that some people here dispute that clarified
meaning and quibble with you about whether Lisp has encapsulation. Some
might say it does, but that it's only partially implemented by the object
system and the rest is implemented by the package system. That's a
subtle discussion in its own right. So I'll leave it for another post,
if not another thread.
> Of course, Ruby will run on a 486 with 16M of memory and no hard disk;
> can LISP do that? :-)
David Douthitt <·····@mailbag.com> writes:
> Kaz Kylheku wrote:
>
> > Now show an example of how Ruby can adapt its superficial syntax to
> > at least loosely imitate something else.
>
> I'm not sure how this all got started, but Ruby and LISP are two totally
> different animals. There's places that LISP would be used instead of
> Ruby, and vice versa.
Though nowadays we tend to call it "Lisp".
> LISP is faster,
Now this is a myth. Granted, it's a better myth than the converse, at
least from a PR point of view, but our intellectual honesty makes us
point out that Lisp as a language isn't fast; it's the implementations
that are of such high quality.
> uses lots of memory,
clisp seems to take 2Mb of RAM over here. That may or may not be
"lots", depending on context. Again, this is an implementation
property.
> and isn't necessarily OO.
Aha! We can agree on one of these points.
> Ruby is [...]
> Of course, Ruby will run on a 486 with 16M of memory and no hard disk;
> can LISP do that? :-)
Yes.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
David Douthitt wrote:
>
> Kaz Kylheku wrote:
>
> Of course, Ruby will run on a 486 with 16M of memory and no hard disk;
> can LISP do that? :-)
(Sorry if this was already posted (my newsreaders are out of sync)):
Try to following:
http://education.ti.com/product/software/derive/features/derivemulisp.html
I think it sells for $99 on-line.
Have fun...
Eric
--
US Supreme Court hearing 00-836
GEORGE W. BUSH, Petitioner, v. PALM BEACH COUNTY CANVASSING BOARD
Justice (Scalia?) to Mr. Klock (representing Katherine Harris):
20 and therefore, I guess, whether we win, whether your side,
21 the side you're supporting wins or loses, it doesn't
22 change that, and I guess that's moot, but my question is,
On 02 Aug 2001 15:25:45 +0100, ······@pelissero.org (Walter C. Pelissero)
wrote:
> Just recently it dawned on me the existence of yet another language in
> the already overcrowded area of scripting languages. It comes, on the
> wave of other cool inventions like Tamagotchi and Karaoke, from Japan.
Keith Playford (once of the Harlequin Dylan team) had a pithy piece of wit
concerning Perl, Python, and Ruby. I'm afraid that I can't remember the exact
wording but it was something like:
Larry Wall never understood Lisp
Guido Van Rostum once read a book on Lisp
Yukihiro Matsumoto once read a book on Lisp and understood some of it
Apologies in advance to Keith for any misquoting, and for publishing this if
he felt it was too naughty.
Ruby has at least one interesting feature as far as Lispers are concerned
which is an automatic kind of WITH- macro but without macros.
In Lisp (or Dylan) we create WITH- style macros to set up and tear down
context around a body of code. They may even be the most common kind of macro
written (except for maybe domain-specific definer macros -- a discussion for
another thread perhaps :-j).
A common idiom when building WITH- style macros is to create a closure around
the body of code and pass it to and INVOKE- function that setups up the
context, runs the closure, and then tears down the context.
Ruby has a slightly convenient syntax for making closures out of bodies of
code and passing them to INVOKErs by being able to put a body of code after a
function call. Eg-ish
foo( x, y ) { some stuff }
Then foo will get called with an implicit extra argument which is a closure
over the body of code that followed the call. The closure is called by putting
"yield" (yuck :-j) where ever you want in the invoker function.
A Lisper would have written a macro/function pair roughly like so:
(with-foo ( x y ) some stuff )
macroexpanding into stuff like:
(foo x y #'(lambda () some stuff ))
'scuse any syntax mistakes. You get the idea.
The Ruby programmer in theory only has to write the invoker function and gets
a WITH- style wrapper for free.
I thought it was interesting anyway. I've not tried using it. Doubtless there
are some argument passing issues.
Perhaps one could usefully standardize a generic WITH macro in CL? Perhaps
there is one in an archive somewhere? Kent?
__Jason
On Thu, 9 Aug 2001, Jason Trenouth wrote:
> A Lisper would have written a macro/function pair roughly like so:
>
> (with-foo ( x y ) some stuff )
>
> macroexpanding into stuff like:
>
> (foo x y #'(lambda () some stuff ))
>
> 'scuse any syntax mistakes. You get the idea.
>
> The Ruby programmer in theory only has to write the invoker function and gets
> a WITH- style wrapper for free.
>
> I thought it was interesting anyway. I've not tried using it. Doubtless there
> are some argument passing issues.
>
> Perhaps one could usefully standardize a generic WITH macro in CL? Perhaps
> there is one in an archive somewhere? Kent?
Something like this (hacked up on the spot)?
(defmacro define-with (with-name invoke-fn vars form-vars)
"defines a macro WITH-NAME that takes (VARS* FORMS*) BODY. The BODY
is enclosed in a LAMBDA with VARS* as arguments and passed as the
first argument to INVOKE-FN; the FORMS are evaluated and passed as the
remaining arguments to INVOKE-FN."
(let ((body-var (gensym "BODY")))
`(defmacro ,with-name ((,@vars ,@form-vars) &body ,body-var)
`(,',invoke-fn #'(lambda (,,@vars) ,@,body-var) ,,@form-vars))))
Tim
On 9 Aug 2001 16:01:27 GMT, Tim Moore <·····@herschel.bricoworks.com> wrote:
> > Perhaps one could usefully standardize a generic WITH macro in CL? Perhaps
> > there is one in an archive somewhere? Kent?
>
> Something like this (hacked up on the spot)?
>
> (defmacro define-with (with-name invoke-fn vars form-vars)
> "defines a macro WITH-NAME that takes (VARS* FORMS*) BODY. The BODY
> is enclosed in a LAMBDA with VARS* as arguments and passed as the
> first argument to INVOKE-FN; the FORMS are evaluated and passed as the
> remaining arguments to INVOKE-FN."
> (let ((body-var (gensym "BODY")))
> `(defmacro ,with-name ((,@vars ,@form-vars) &body ,body-var)
> `(,',invoke-fn #'(lambda (,,@vars) ,@,body-var) ,,@form-vars))))
Actually I was thinking that there could be a single WITH macro, but its
probably just some back-to-front anaphoric FLET variation.
Eg (with (open-file file) ((s) (read s)))
Nevermind.
__Jason