This is not about what common lisp is not about.
So it shouldn't be construed as a flame bait. I am
just curious what programming languages appeal
to the lisp mindset.
During my fit of procrastination, I took time away from lisp
and surfed the net looking at different languages, here are
some that capture my imagination.
Oz - A multi-paradigm language that includes logic,
functional (both lazy and eager), imperative,
object-oriented, constraint, distributed, and concurrent
programming.
I find its use of logical variables in thread scheduling
very interesting. When a variable is yet unbound, the thread
blocks, and when the variable is bound, thus fulfilling the
constraint, the thread is allowed to run.
Qi - A dialect of lisp embedded in Clisp. Qi has optional
static type checking. It boasts a "Turing-complete" type
extension system. It has pattern matching, currying, and
partial-application. Qi can be freely mixed with
common-lisp.
I don't know enough about typing to know what
"Turing-completeness" implies. But it is interesting to see
how two radically different languages might co-exist.
See: http://www.lambdassociates.org/
Pliant - It's a "multilayered" language. Pliant programs can
modify the parser, compiler, code generator, and the code
optimizer.
Again, I don't know what are the implications of opening up
the compiler, code generator, and code optimizer for
end-users to play with. But it captures my imagination and
gets my blood boiling.
See: http://fullpliant.org/pliant/language/
For some examples of meta-programming in pliant,
See:
http://fullpliant.org/pliant/language/compiler/tutorial/samples.html
What are some languages that capture your imagination?
Something along the line of, "Hey, that's really cool! But I
don't know how you can pull it off."
Now I need to get back to my lisp project...
Howard
On 12 Aug 2006 23:27:18 -0700, <······@gmail.com> wrote:
>
> What are some languages that capture your imagination?
What captures my imagination is not my second favorite language.
My second favorite language is perl, due to libwww.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
"hayeah" <······@gmail.com> writes:
> What are some languages that capture your imagination?
Although it may not be as innovative as it was back then, I am still
fascinated by the Smalltalk environment, language and development
style.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
> What are some languages that capture your imagination?
Haskell. I think it's beautiful and I write much better Lisp after
learning it.
The reason I think lisp is better than Haskell is because of the
bottom-up-ness of it (eg the simplicity, macros, parens, prefix
notation, etc.)
I've always wanted to try Erlang...
> Qi - A dialect of lisp embedded in Clisp. Qi has optional
> static type checking. It boasts a "Turing-complete" type
> extension system. It has pattern matching, currying, and
> partial-application. Qi can be freely mixed with
> common-lisp.
why would anyone want a less extendible version of clisp?
I love the examples from "QI for the Lisp programmer":
<quote>
"Another example; we have a function g that returns b given a and c
given b. We write this as
(DEFUN g (X)
(COND ((EQ X 'a) 'b)
((EQ X 'b) 'c)
(T (ERROR "Input to g is not a or b.~%"))))
This becomes
(define g
a -> b
b -> c)"
</quote>
uh...
(defun g (x)
(ecase x
(a b)
(b c)))
<quote>
"The following Lisp function takes a list of two numbers and returns
the biggest or raises an error if there is no largest.
(DEFUN find_bigger (X)
(COND ((AND (LISTP X) (= (LENGTH X) 2))
(IF (> (CAR X) (CADR X)) (CAR X)
(IF (> (CADR X) (CAR X)) (CADR X)
(ERROR "find_bigger has failed.~%"))))
(T (ERROR "find_bigger has failed.~%"))))
In Qi, the function can be coded with guards.
(define find_bigger
[X Y] -> X where (> X Y)
[X Y] -> Y where (> Y X))"
</quote>
hrm...
(defun my-find-bigger (x y)
(destructuring-bind (x y) list
(econd ((> x y) x
((< x y) y))))
but why not just
(defun find_bigger (x y)
(if (= x y)
(error "whatever")
(max x y))))
(apply #'find_bigger list)
;nick
········@gmail.com wrote:
> > What are some languages that capture your imagination?
>
> I've always wanted to try Erlang...
>
I don't see what's so hot about Erlang. It basically just
says, "let's ignore everything, and stick with message
passing." That's a very sensible thing to do though.
But Oz to me sounds a lot more interesting, if you want
high-level concurrent and distributed programming.
Here's a definition for concurrent map in Oz:
fun {Map Xs F}
case Xs
of nil then nil
[] X|Xr then thread {F X} end |{Map Xr F}
end
end
I think it's way cool. If only Oz has macro, I'd jump to Oz
from CL...
> why would anyone want a less extendible version of clisp?
>
Actually, it's as extensible as lisp. At least, defmacro
works. Qi's inclusion of a yacc-like facility is
interesting too.
> I love the examples from "QI for the Lisp programmer":
>
> <quote>
> "Another example; we have a function g that returns b given a and c
> given b. We write this as
>
> (DEFUN g (X)
> (COND ((EQ X 'a) 'b)
> ((EQ X 'b) 'c)
> (T (ERROR "Input to g is not a or b.~%"))))
>
> This becomes
>
> (define g
> a -> b
> b -> c)"
> </quote>
>
> uh...
>
> (defun g (x)
> (ecase x
> (a b)
> (b c)))
>
This, I suppose, is just a matter of taste. If you like
pattern-matching, you'd like what Qi has to offer. So
instead of having destructuring-bind, cond, case, typecase, Qi
lets you use pattern matching and guards.
You said you like Haskell. I am suprised of all the
possible nit-pickings, you chose pattern matching.
> I don't see what's so hot about Erlang. It basically just
> says, "let's ignore everything, and stick with message
> passing." That's a very sensible thing to do though.
>
> But Oz to me sounds a lot more interesting, if you want
> high-level concurrent and distributed programming.
fair enough...
> I think it's way cool. If only Oz has macro, I'd jump to Oz
> from CL...
have you tried out CL-MULPROC or any of the other concurrency libraries
for cl? what's wrong with concurrent programming in cl? why exactly is
it that you're using lisp now?
> Actually, it's as extensible as lisp. At least, defmacro
> works. Qi's inclusion of a yacc-like facility is
> interesting too.
yes, there is DEFMACRO, but the code is still not in a form that I
would want to perform any complex macroology on...
> This, I suppose, is just a matter of taste. If you like
> pattern-matching, you'd like what Qi has to offer. So
> instead of having destructuring-bind, cond, case, typecase, Qi
> lets you use pattern matching and guards.
>
> You said you like Haskell. I am suprised of all the
> possible nit-pickings, you chose pattern matching.
my point was the quality of the lisp code supplied in their examples:
they were clumsy and dishonestly ellegant. yes, symbols print in caps,
but everyone types in lowercase! also good code in any language is
usually properly INDENTED.
go ahead and use qi or Oz or whatever you like ;-)
Nick
········@gmail.com wrote:
> > I think it's way cool. If only Oz has macro, I'd jump to Oz
> > from CL...
>
> have you tried out CL-MULPROC or any of the other concurrency libraries
> for cl? what's wrong with concurrent programming in cl?
I haven't tried any concurrent programming in CL.
>why exactly is it that you're using lisp now?
S-expression rocks. 'Nuff said.
Mmm... this is really the only reason.
> my point was the quality of the lisp code supplied in their examples:
> they were clumsy and dishonestly ellegant. yes, symbols print in caps,
> but everyone types in lowercase! also good code in any language is
> usually properly INDENTED.
Just for additional information, Qi uses case sensitive reader. So
in order to access common-lisp stuff, you use uppercase. You can
of course rebind them to use lowercase.
Anyway, it's too bad you are turned off by relatively unimportant
issues.
hayeah wrote:
> Pliant - It's a "multilayered" language.
I see it's under GPL. *Sigh*
"Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted" is good
enough for Python; why not Pliant?
Mark Carter <··@privacy.net> writes:
>
>> Pliant - It's a "multilayered" language.
>
> I see it's under GPL. *Sigh*
>
> "Permission to use, copy, modify, and distribute this software and its
> documentation for any purpose and without fee is hereby granted" is
> good enough for Python; why not Pliant?
Because the authors want their code to be free, perhaps?
--
Robert Uhl <http://public.xdi.org/=ruhl>
When the water of a place is bad it is safest to drink none that has not
been filtered through either the berry of a grape, or else a tub of malt.
These are the most reliable filters yet invented. --Samuel Butler
Robert Uhl wrote:
> Mark Carter <··@privacy.net> writes:
>
>>>Pliant - It's a "multilayered" language.
>>
>>I see it's under GPL. *Sigh*
>>
>>"Permission to use, copy, modify, and distribute this software and its
>>documentation for any purpose and without fee is hereby granted" is
>>good enough for Python; why not Pliant?
>
>
> Because the authors want their code to be free, perhaps?
No, their code remains free no matter what anyone else does with it.
They want /everyone's/ code to be free. Didn't work. And they did not
have to be that way. Most people do not even use the GPL, they use the
LGPPL at worst, often BSD/MIT. And open source does fine.
Of course there may be some parallel universe in which the GPL does not
have to compete with LGPL and...
:)
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> No, their code remains free no matter what anyone else does with it.
> They want /everyone's/ code to be free. Didn't work. And they did not
> have to be that way. Most people do not even use the GPL, they use the
> LGPPL at worst, often BSD/MIT.
Finally!
Yes - the point is, when people are toolin' around to see if there's
other interesting stuff out there, they will probably be thinking if
they can use it in their work. Seeing "GPL", I immediately loose
interest. I also think that LGPL is too much of an encumbrance - our
clients aren't likely to be able to link stuff together, anyway.
To write a programming language or significant library (like a windowing
system) and put it under GPL is just daft, IMO.
On Mon, 14 Aug 2006 15:14:02 +0200, Mark Carter <··@privacy.net> wrote:
> Ken Tilton wrote:
>
>> No, their code remains free no matter what anyone else does with it.
>> They want /everyone's/ code to be free. Didn't work. And they did not
>> have to be that way. Most people do not even use the GPL, they use the
>> LGPPL at worst, often BSD/MIT.
>
>
> Finally!
>
> Yes - the point is, when people are toolin' around to see if there's
> other interesting stuff out there, they will probably be thinking if
> they can use it in their work. Seeing "GPL", I immediately loose
> interest. I also think that LGPL is too much of an encumbrance - our
> clients aren't likely to be able to link stuff together, anyway.
>
> To write a programming language or significant library (like a windowing
> system) and put it under GPL is just daft, IMO.
Contact the author.
Many have deals for commercial use as well.
But you will probably have to pay.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Mark Carter wrote:
...
> To write a programming language or significant library (like a windowing
> system) and put it under GPL is just daft, IMO.
Why is that daft? For example gcc is released under the GPL, not LGPL,
but that doesn't mean you have to release code that you compile with
gcc. The GPL has no restrictions (IIRC) on _executing_ software. Only if
you extend/modify gcc itself _and_ release the result would you be bound
to also release the source.
Saying this, I have heard GPL criticized for being too 'C'-centric. I'm
not sure what the situtation would be if you were to release a lisp core
of your own code built with a GPL'ed lisp.
On 2006-08-14 11:22:02 -0400, Alex McGuire
<·······@ignorethis-gmail-andthis.com> said:
> Why is that daft? For example gcc is released under the GPL, not LGPL,
> but that doesn't mean you have to release code that you compile with
> gcc. The GPL has no restrictions (IIRC) on _executing_ software. Only
> if you extend/modify gcc itself _and_ release the result would you be
> bound to also release the source.
Because certain software, such as libraries, are used by linking them
with one's own work and distributing the two as a single unit. If you
link a gpl (not lglpl, but gpl) library with your own work and
redistribute it, your own work now becomes gpl:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it."
This is why libraries are often distributed under the lgpl ( the 'l' of
which originally stood for "library" and now stands for "lesser"). It
is also why there exists the llgpl which is an [attempted]*
modification of the lgpl with an explicit exemption for loading a lisp
library into one's own work and redistributing it.
* There may be some legal ambiguity with changing the terms of a
license in a preamble - the llgpl is a preamble to the lgpl.
Raffael Cavallaro wrote:
> On 2006-08-14 11:22:02 -0400, Alex McGuire
> <·······@ignorethis-gmail-andthis.com> said:
>
>> Why is that daft? For example gcc is released under the GPL, not LGPL,
>> but that doesn't mean you have to release code that you compile with
>> gcc. The GPL has no restrictions (IIRC) on _executing_ software. Only
>> if you extend/modify gcc itself _and_ release the result would you be
>> bound to also release the source.
>
>
> Because certain software, such as libraries, are used by linking them
> with one's own work and distributing the two as a single unit. If you
> link a gpl (not lglpl, but gpl) library with your own work and
> redistribute it, your own work now becomes gpl:
>
> "These requirements apply to the modified work as a whole. If
> identifiable sections of that work are not derived from the Program, and
> can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to those
> sections when you distribute them as separate works. But when you
> distribute the same sections as part of a whole which is a work based on
> the Program, the distribution of the whole must be on the terms of this
> License, whose permissions for other licensees extend to the entire
> whole, and thus to each and every part regardless of who wrote it."
>
> This is why libraries are often distributed under the lgpl ( the 'l' of
> which originally stood for "library" and now stands for "lesser"). It is
> also why there exists the llgpl which is an [attempted]* modification of
> the lgpl with an explicit exemption for loading a lisp library into
> one's own work and redistributing it.
>
>
> * There may be some legal ambiguity with changing the terms of a license
> in a preamble - the llgpl is a preamble to the lgpl.
>
I wasn't referring to libraries. My fault for not being clearer. I was
wondering why the parent thought distributing a programming language
under the gpl was a bad thing. An earlier post had said that he couldn't
use pliant for this reason. I assume by a programming language we are
talking about a compiler/interpreter, which was why I used gcc as an
example. I thought the posters may have had the mistaken belief that
code compiled with a gpl compiler becomes gpl.
Gcc is probably a bad example, as obviously you couldn't actually build
anything of much use without the standard c/c++ libraries, which as you
point out, need to be lgpl (or gpl with the runtime exception) to avoid
all executables becoming gpl, but gcc itself is gpl.
I don't think that the pliant language/environment being gpl would
prevent anyone from using it to build a non-gpl application.
On 2006-08-14 23:07:15 -0400, Alex McGuire
<·······@ignorethis-gmail-andthis.com> said:
> Gcc is probably a bad example, as obviously you couldn't actually build
> anything of much use without the standard c/c++ libraries, which as you
> point out, need to be lgpl (or gpl with the runtime exception) to avoid
> all executables becoming gpl, but gcc itself is gpl.
>
> I don't think that the pliant language/environment being gpl would
> prevent anyone from using it to build a non-gpl application.
Are there any pliant components at runtime in a delivered pliant
executable? - none of the pliant source files contains a runtime
exception that I can find.
Le Sun, 13 Aug 2006 15:12:16 +0100, Mark Carter a écrit :
>> Pliant - It's a "multilayered" language.
> I see it's under GPL. *Sigh*
>
> "Permission to use, copy, modify, and distribute this software and its
> documentation for any purpose and without fee is hereby granted" is
> good enough for Python; why not Pliant?
Because it's authors could not bear that someone distribute their work
or a modified version of it without giving the source?
Giving your work as free software is not like giving it away. I can
understand that an author does not wish to see someone use it's work in
a proprietary software...
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
lispolos wrote:
> hayeah wrote:
>
>>I am just curious what programming languages
>>appeal to the lisp mindset.
>
>
> My second favourite language is Lisp.
>
> Paul
>
>
> P.S. Oh, for the curious: my first favourite language is Hebrew; it
> serves me to program my mind...
>
I can see thinking in Hebrew, but programming your mind in it? Why
program your mind in any language (natural or computer), its code seems
to come built-in? </humor>
To go back on topic, my second favorite language remains Object Pascal.
I just like being able to write a LibGreenspun (a library form of an
ad-hoc, informally specified, bug-ridden, slow implementation of half of
Common Lisp) that will run on bare metal.
--
The science of economics is the cleverest proof of free will yet
constructed.
hayeah wrote:
> This is not about what common lisp is not about.
> So it shouldn't be construed as a flame bait. I am
> just curious what programming languages appeal
> to the lisp mindset.
Assembly code on any straightforward RISC CPU. It's simple, elegant,
does what it's supposed to do, and is amenable to my optimization.
And, um, I have a Scheme mindset, although I'm not religious about it.
If SBCL actually did anything on Windows I'd use it, but so far it
doesn't. I already committed myself 9 months ago to kicking Chicken
Scheme into shape on Windows, and having nearly done that, I'm not
interested in doing that kind of effort again for something else.
Gotta actually get some benefit from the investment. If others manage
to push the SBCL ball forward farther than I'll be pushing the Chicken
Scheme ball foward, then I'll switch. Or if there was money in SBL,
I'd switch. Otherwise, I have no incentive.
Cheers,
Brandon Van Every
hayeah wrote:
> This is not about what common lisp is not about.
> So it shouldn't be construed as a flame bait. I am
> just curious what programming languages appeal
> to the lisp mindset.
My second favorite language is probably still Oberon (and I mean
Oberon-1, not Oberon-2). It's probably about as minimal an Algol-style
language as it gets. I also loved the Oberon System. Actually, I think
an Oberon-System-style development environment for Lisp would be really
great. I only learned much later that the Oberon System was actually
just a rip-off of Smalltalk, but for some reason, I find the Oberon
System somewhat more attractive. Don't know why, though.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> hayeah wrote:
>> This is not about what common lisp is not about.
>> So it shouldn't be construed as a flame bait. I am
>> just curious what programming languages appeal
>> to the lisp mindset.
>
> My second favorite language is probably still Oberon (and I mean
> Oberon-1, not Oberon-2). It's probably about as minimal an Algol-style
> language as it gets. I also loved the Oberon System. Actually, I think
> an Oberon-System-style development environment for Lisp would be
> really great. I only learned much later that the Oberon System was
> actually just a rip-off of Smalltalk, but for some reason, I find the
> Oberon System somewhat more attractive. Don't know why, though.
Because it's text based. The Oberon user interface is one of the
best. (Perhaps I should say programmer-interface, I don't know if lay
users would like it).
Actually, it seems that CLIM can do something similar, and even emacs,
(if only we could make text buttons easily in emacs!)
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.