An Acceptable Lisp

Vsevolod <vseloved@gmail.com> writes:

> On Aug 26, 11:24 am, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Mon, 25 Aug 2008 12:27:26 -0700, Vsevolod wrote:
>> >http://lisp-univ-etc.blogspot.com/20...le-lisp.html(a
>> > somewhat emotional article with strong subjective opinions on other
>> > programming languages)
>>
>> Next time it is enough to post the link.
>>
>> > Recently I've been thinking about programming languages in general and
>> > how they relate to Common Lisp, spurred by such questions (and
>> > discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a
>> > better type system?, What do you LISPers think of Haskell?, Paul
>> > Graham's Arc is released today... what is the long term impact? etc.
>>
>> > [...]
>>
>> > Maybe it's time to start advancing from Common Lisp to Universal Lisp?..
>>
>> Gee, I just love it when people start big philosophical discussions on
>> Where Programming Languages Should Go. Especially if they seem to be at
>> the level of a homework assignment for a freshman philosophy course.
>>
>> Your single-paragraph summaries of programming languages enlightened many
>> of us. I was not aware that one can evaluate programming languages by
>> checking a grocery list of features. Does language X have feature A?
>> Language Y is just a B with a little of C.
>>
>> And clearly, the objective of language design is not creating a valuable
>> practical tool, but satisfying every group we can think of. Especially
>> the "static typing folks".
>>
>> Remember that actual programming is detrimental to the development of a
>> proper perspective. It is best to take a cursory glance at programming
>> languages (reading more than the first paragraph of Wikipedia articles is
>> too much), then meditate on The Universal Lisp.
>>
>> Good luck,
>>
>> Tamas
>
> Don't take my words to seriously, I'm just trying to reason on the
> topics, that interest me, and this is the place, where you can easily
> get opinions, different from yours. And if you have no opinion, that
> doesn't mean, that nobody else isn't allowed to

This is also a place where you can easily be killfile'd or
otherwise ignored if you post long and poorly thought out or
researched articles.

På Tue, 26 Aug 2008 15:45:21 +0200, skrev Vsevolod <vseloved@gmail.com>:

>
> Could you, please, elaborate a little on this questions:
> Why is Mathematica's "look" superior to Common Lisp's?
> In which aspects do you think Eiffel's object system is superior to
> CLOS?
> Do you think, that Hindley-Milner type system (and it's implementation
> in Haskell) is the final word in type systems in practical application
> and why?
>
> Vsevolod

Here is a example Matematica 'program' to print the first 9 rows of
Pascal's triangle

TableForm[Table[Binomial[n, k], {n, 0, 8}, {k, 0, n}]]

I find the function name capitalized and followed by [] to be more
readable.
Similarly the special forms are just attributes that are given to such a
form.
The functions are well though out and powerful.
The pattern matching is awesome.

What regards inheritance I find that classes should inherit behaviour as
well as name. This is a fundamental weakness of all object systems.
Only in Eiffel can you inherit behaviour as well. For instance the
function 'next' should specify that there is a scheme of well orderedness.
Similarly multiple inheritance is handled in a way which is less
confusing. You explicitly say what is included and what is called through
a lattice rather than rely on a ad hock pre determined scheme.

I should note that I like the seperation of classes and methods and the
natural way that allows you to define multi-methods in CLOS.

I find that types should be optional and that the way it is handed in CL
is too cumbersome.
Ideally I would like to just specify the type of the input parameters and
the return type and have the compiler infer the rest.
Simulary class and type should be the same concept.

--------------
John Thingstad

Vsevolod wrote:
> As far as I understand, what people mean, when they talk about
> acceptable Lisp, is not Lisp per se, but a universal high-level
> programming language.

I think the phrase "acceptable Lisp" means something far more specific than
you imply. For example, OCaml is almost certainly not regarded as an
acceptable Lisp because it has a static type system and a macro system
designed to handle syntax.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

> What they are missing is that CL is a great language because it is
> extremely well-engineered, and the existing features fit together very
> nicely.
I completely agree with you.

Dick Gabriel said: "I think there will be a next Lisp". (http://
www.dreamsongs.com/WIB.html. 3.6 The Next Lisp)
And actually I'm willing to put effort in the direction of "the
Ultimate Lisp" and plan to do that, when I'm ready. But, surely, my
efforts won't be enough, and, moreover, as I've mentioned above, one-
man efforts can't lead to something as finely thought-out and
engineered, as well as acceptable, as, for example, Common Lisp

Vsevolod

On Aug 25, 2:27*pm, Vsevolod <vselo...@gmail.com> wrote:
> ...So, first I've analyzed the languages, which are wide-spread now,
> weather they can deliver universality, so to say.
>

Do we really need or want a 'universal language'? What's the benefit?
I think there is a lot to be gained from having multiple programming
language communities:

New interesting ideas can be played around with in new languages, and
for particular problems these new languages can then become quite
useful. Eventually these ideas might be incorporated into other more
general purpose languages. This sort of cross-fertilization is good I
think.

I think a more interesting unification of languages would be a common
interface and semantics for calling methods and accessing data from
another language's binaries: this used to be true (e.g. c to fortran,
or vice versa), and what little I know about Microsoft's CLR looks
interesting in this respect... but none of these are really universal,
yet. Having such a universal cross-language semantics would let people
write subsystems in whatever language they are familiar with and/or is
most suitable for the particular task.

On Aug 26, 9:06*pm, Vsevolod <vselo...@gmail.com> wrote:
> > What they are missing is that CL is a great language because it is
> > extremely well-engineered, and the existing features fit together very
> > nicely.
>
> I completely agree with you.
>
> Dick Gabriel said: "I think there will be a next Lisp". (http://www.dreamsongs.com/WIB.html. 3.6 The Next Lisp)
> And actually I'm willing to put effort in the direction of "the
> Ultimate Lisp" and plan to do that, when I'm ready. But, surely, my
> efforts won't be enough, and, moreover, as I've mentioned above, one-
> man efforts can't lead to something as finely thought-out and
> engineered, as well as acceptable, as, for example, Common Lisp
>
So what is it you want from a Lisp that cannot be implemented by
shadowing (= redefining) symbols in the CL package and surface syntax
via reader macros?

--
Mikael Jansson
http://mikael.janson.be/hacking/limp

On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:

>> What they are missing is that CL is a great language because it is
>> extremely well-engineered, and the existing features fit together very
>> nicely.
> I completely agree with you.
>
> Dick Gabriel said: "I think there will be a next Lisp". (http://
> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
> to put effort in the direction of "the Ultimate Lisp" and plan to do
> that, when I'm ready. But, surely, my efforts won't be enough, and,
> moreover, as I've mentioned above, one- man efforts can't lead to
> something as finely thought-out and engineered, as well as acceptable,
> as, for example, Common Lisp
>
> Vsevolod

He also said:
"There should be a simple, easily implementable kernel to the Lisp. That
kernel should be both more than Scheme -- modules and macros -- and less
than Scheme -- continuations remain an ugly stain on the otherwise clean
manuscript of Scheme.

The kernel should emphasize implementational simplicity, but not at the
expense of interface simplicity. Where one conflicts with the other, the
capability should be left out of the kernel. One reason is so that the
kernel can serve as an extension language for other systems, much as GNU
Emacs uses a version of Lisp for defining Emacs macros."


With the right kernel we could put the rest of Common Lisp in something
Like: http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/, much like what
PCL did for CLOS.

However the most minimal kernel most lispers seem to want these days is:
http://www.lispworks.com/documentation/HyperSpec/Front/

Matt

Matthew D Swank wrote:
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.

What's wrong with continuations?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

In article <xo0tk.11747$_s1.9676@newsfe07.iad>,
Matthew D Swank <akopa.gmane.poster@gmail.com> wrote:

> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>
> >> What they are missing is that CL is a great language because it is
> >> extremely well-engineered, and the existing features fit together very
> >> nicely.
> > I completely agree with you.
> >
> > Dick Gabriel said: "I think there will be a next Lisp". (http://
> > www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
> > to put effort in the direction of "the Ultimate Lisp" and plan to do
> > that, when I'm ready. But, surely, my efforts won't be enough, and,
> > moreover, as I've mentioned above, one- man efforts can't lead to
> > something as finely thought-out and engineered, as well as acceptable,
> > as, for example, Common Lisp
> >
> > Vsevolod
>
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.
>
> The kernel should emphasize implementational simplicity, but not at the
> expense of interface simplicity. Where one conflicts with the other, the
> capability should be left out of the kernel. One reason is so that the
> kernel can serve as an extension language for other systems, much as GNU
> Emacs uses a version of Lisp for defining Emacs macros."

This has been done with EuLisp to some extend. Check out the EuLisp spec.
It has a level-0 language and a level-0 library.
Level-1 then specifies reflective functionality and
some control structures and low-level functionality.

The Germans tried to define a DIN Kernel Lisp
(An approach to the DIN Kernel Lisp definition,
http://www.brics.dk/~hosc/vol04/04-cengarle-al.html ). There
is critique by Baker about that attempt:
http://home.pipeline.com/~hbaker1/CritLisp.html

I guess some of that work then went into ISLisp.

http://www.open-std.org/JTC1/SC22/WG16/

OpenLisp, an implementation of ISLisp, btw., seems
to run on small devices, too:

http://openlisp.free.fr/forum/viewtopic.php?f=2&t=28


>
>
> With the right kernel we could put the rest of Common Lisp in something
> Like: http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/, much like what
> PCL did for CLOS.
>
> However the most minimal kernel most lispers seem to want these days is:
> http://www.lispworks.com/documentation/HyperSpec/Front/
>
> Matt

--
http://lispm.dyndns.org/

On Aug 27, 12:29 am, DeverLite <derby.lit...@gmail.com> wrote:
> Do we really need or want a 'universal language'?

Need -- don't know, but I suppose, not. Want -- perhaps. At least the
people, who speculate on this topic (not only me, as you can see all
over the internet and in this newsgroup in particular), want. (I don't
mean, though, that I'm not content with the current CL).
As well, it's a pity, that people, who can make a lot in the CL world,
move away to other languages -- this means, that CL doesn't fully meet
their demands (I mean someone, like Paul Graham and Peter Norvig --
not the ones, who are constantly searching for something new or just
don't know, what they want, and follow the wave).

Vsevolod