Beginnings - History of Declarative Languages

[Daniel Jomphe]

I really enjoyed reading the first chapter of the FPQi book -
Beginnings. The way it's presented felt really great to me, and it
triggered in me the interest to try to untangle a bit more my
historical understanding. Thus the following tables. The dates don't
match those of the book, because I've taken them out of Wikipedia as
they were shown there.

By Year

1958 US Lisp (IPL)

1966 UK ISWIM

1972 France Prolog

1972 UK SASL (ISWIM)

1973 UK ML (ISWIM)

197s US Scheme (Lisp)

1984 US Common Lisp (Lisp, Scheme)
1994

1985 France Caml (ML, Lisp)

1987 Sweden Erlang (Prolog)

1990 UK Standard ML (ML)

1990 UK & US Haskell (Miranda, ML, Lazy ML, SISAL,
ISWIM, SASL)

1991 Germany Oz (Prolog)
1996 += Sweden Oz/Mozart
1999 += Belgium

1992 UK SEQUEL (?) (?)

1996 France Ocaml (SML, Caml)

2000 Germany Alice (ML, Oz/Mozart)

2003 Switzerland Scala (Haskell, SML, OCaml,
SmallTalk)

2004? UK Epigram (?)

2005 UK Qi (SEQUEL, SML?, Haskell?)

2005 US F# (OCaml, C#, Haskell)

2007 US Clojure (Common Lisp, SML, Haskell,
Erlang)

2008 UK Qi II (Qi)

2009 Canada JazzScheme (Scheme)

By Region of the World

The American Experience

1958 US Lisp (IPL)

197s US Scheme (Lisp)

1984 US Common Lisp (Lisp, Scheme)
1994

1990 UK & US Haskell (Miranda, ML, Lazy ML, SISAL,
ISWIM, SASL)

2005 US F# (OCaml, C#, Haskell)

2007 US Clojure (Common Lisp, SML, Haskell,
Erlang)

The British Experience

1966 UK ISWIM

1972 UK SASL (ISWIM)

1973 UK ML (ISWIM)

1990 UK Standard ML (ML)

1990 UK & US Haskell (Miranda, ML, Lazy ML, SISAL,
ISWIM, SASL)

1992 UK SEQUEL (?) (?)

2004? UK Epigram (?)

2005 UK Qi (SEQUEL, Common Lisp, Prolog,
SML, Haskell)

2008 UK Qi II (Qi)

The French Experience

1972 France Prolog

1985 France Caml (ML, Lisp)

1996 France Ocaml (SML, Caml)

The European Experience (that is, the rest)

1987 Sweden Erlang (Prolog)

1991 Germany Oz (Prolog)
1996 += Sweden Oz/Mozart
1999 += Belgium

2000 Germany Alice (ML, Oz/Mozart)

2003 Switzerland Scala (Haskell, SML, OCaml,
SmallTalk)

The Canadian Experience :)

2009 Canada JazzScheme (Scheme)

Of note:

- I'm not sure if JazzScheme academically deserves a place in these
tables, as I don't know much about it yet. At the very least, let's
say it has the huge credits of practicalizing Scheme (or a dialect
of).
- I'm yet to know how Haskell's and Scala's type theories work, and
how they relate to that of the MLs and of Qi.
- I'm highly puzzled by Dependence Type Theories like that of
Dependent ML / Epigram. A quick glance at their pages made me feel
like it's too heavy for me to be able to understand them. Like the
previous point, too, I would especially like to understand how this
kind of theory relates to that of Qi.
- I'd like to know which of these languages have been influenced by
the Combinatorial Calculus. This is also highly abstract to me.
- We're left with a few great declarative languages/platforms that are
really trying to close the gap to mainstream; chronologically: Mozart,
Qi, Clojure, F#, JazzScheme. I don't include Scala because of its
reported complexity. Of these, Clojure and F# are probably the ones
with the biggest library support and easiest deployment path for
native applications. I intend to work with one of these (excepting
F#) to help it succeed.
- Qi can probably (with a lot of work) be implemented on top of
Clojure; if it does and is able to interact very well with Clojure and
Java (which I doubt), this could be something really meaningful, both
to Clojure and to Qi.
- Of course, I have overlooked some aspects that might feel important
to the reader. Feel free to mention them.

On a side note, although my theoretical curriculum is greatly lacking
on the mathematical side (I can't remember nor, consequently,
understand most of my high-school math. notions, so forget about what
few notions I've learned afterwards), I'm progressing well through the
book (chap. 11 now), without too much head-scratching. Even in front
of mathematical formalisms, I'm able to make my way through their
meaning or understand them thanks to the explanations that follow each
one of them. I'm happy that I can effectively learn the language.

Cheers!

[Jon Harrop]

On Friday 12 December 2008 02:12:01 Daniel Jomphe wrote:
> 2005 US F# (OCaml, C#, Haskell)

Actually F# was developed here in the UK, specifically by Don Syme at
Microsoft Research Cambridge. To confuse matters more, Don is Australian.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

[Daniel Jomphe]

Jon Harrop wrote:
> Actually F# was developed here in the UK, specifically by Don Syme at
> Microsoft Research Cambridge. To confuse matters more, Don is Australian.

Thanks Jon! I wasn't sure which M$ Research it was. :) So this
highlights even more how much the MLs (including Haskell, if we can)
are part of the British Experience.

[Cyril Slobin]

On Fri, Dec 12, 2008 at 5:12 AM, Daniel Jomphe <daniel...@gmail.com> wrote:

> The European Experience (that is, the rest)

The Soviet Experience

1966 USSR Refal

Or you can call it anti-soviet experience: the inventor of Refal,
Valentin Turchin, was a political dissident and emigrated to US from
USSR in 1977. The language itself features pattern-based tree
rewriting rules (think of XSLT of 60's). Refal was used as a base in
metacompilation research (on which a partial evaluation is probably
the simplest example). The language is barely known in modern
declarative languages lore, but worth to look at nevertheless.

--
http://slobin.pp.ru/ `When I use a word,' Humpty Dumpty said,
<cy...@slobin.pp.ru> `it means just what I choose it to mean'

[Mark Tarver]

> - Qi can probably (with a lot of work) be implemented on top of
> Clojure; if it does and is able to interact very well with Clojure and
> Java (which I doubt), this could be something really meaningful, both
> to Clojure and to Qi.

I'd guess the smart move would be to port Qi to ABCL - a version of
Common Lisp that runs on the JVM. This would be much easier than a
port to Clojure.

http://common-lisp.net/project/armedbear/

On 12 Dec, 02:12, Daniel Jomphe <danieljom...@gmail.com> wrote:
> I really enjoyed reading the first chapter of the FPQi book -
> Beginnings.  The way it's presented felt really great to me, and it
> triggered in me the interest to try to untangle a bit more my
> historical understanding.  Thus the following tables.  The dates don't
> match those of the book, because I've taken them out of Wikipedia as
> they were shown there.

I think the SML date is wrong because Wikstrom's intro to SML came out
in 1987. SML is mid-eighties. But :)

Mark

[Daniel Jomphe]

> I'd guess the smart move would be to port Qi to ABCL - a version of
> Common Lisp that runs on the JVM.  This would be much easier than a
> port to Clojure.

My feeling was that it would mean a lot more to port Qi to Clojure
since Clojure fits really well in Java-as-a-Platform; if Qi was to
inherit more interop capabilities thanks to a port to Clojure instead
of ABCL, it would help it spread much more, especially since CL is
mainstream-dead while Clojure is mainstream-interesting. Therefore,
if it's possible, such a port would be worth the supplemental efforts.

Now, I can't yet compare ABCL's and Clojure's interop with Java.

I don't know if whatever missing interop features could be added
straight from Qi, independently of the quality of the lisp
implementation on top of which it's ported.

I don't know either how much programming in Qi encourages us to ignore
the underlying platform or not. I assumed that we are encouraged to
interact a lot with the underlying platform(s), and therefore thought
it would be really interesting and empowering to be able to interact
with a lisp that is itself well integrated into Java-as-a-Platform,
and that also brings very elegant unified data structures to the
table. But if a port of Qi to Clojure means we don't care anymore
about Clojure as long as it provides Java-interop access to Qi, then I
suppose a port to ABCL would make much more sense, and then again, why
not go straight to the most minimal possible lispy implementation so
that we don't have a whole unused CL platform between Qi and that of
Java.

Finally, I'm not even sure if it would be really useful to bring Qi to
the Java Platform; this hope of mine is based solely on the assumption
that if ABCL, SISC, KAWA and Clojure are doing it, it must be for more
than "just" using the JVM for platform portability.

All this having been said, my concern is that we invest our energies
in the Most Meaningful Solution. And if this MMS implies porting to
something different than a CL, then I believe we must be willing to
spend the efforts now, rather than regretting later we didn't do it
now, and then dividing the community by starting anew on top of
something else.

Now, who am I to devise such plans for the future of Qi? I think I
should get back to my books and, eventually, to a REPL or two. Before
I do that, though, I wanted to ask you something. I don't know why I
didn't before, but it's only today that I read for the first time John
Backus' 1978 paper. I had never read a more convincing rebuttal of
imperative programming (I'm yet to read Turner 1982). And on page
624, we can read:

"One advantage of this algebra over other proof techniques is that the
programmer can use his programming language as the language for
deriving proofs, rather than having to state proofs in a separate
logical system that merely talks about his programs."

Although Qi, in my understanding, doesn't make use of Backus' FP
System's algebra, am I going too far when I believe that Qi achieves
the feat of reconciling the programming language with proofs of the
same language in a unifying way?

Also, on the same page:

"Our goal is to develop a foundation for the algebra of programs that
disposes of the theoretical issues, so that a programmer can use
simple algebraic laws and one or two theorems from the foundations to
solve problems and create proofs in the same mechanical style we use
to solve high-school algebra problems, and so that he can do so
without knowing anything about least fixed points or predicate
transformers."

Again, am I going too far in believing that Qi marks another big point
here, although it doesn't seem to make use of the said algebra?

In any case, this paper has been highly enlightening to me and I feel
it's bad how I can't seem to find how Backus's Function-Level thinking
got incorporated in modern Functional Languages. Was Backus the only
proponent and consumer of his ideas? It looks like the latter all
preferred to continue building their core on top of Church or Curry
foundations (of which I'm no critique). Concurrently, in my current
understanding, the US went along Church with their Lisps and Schemes,
while the UK went along Curry with their MLs.

[Mark Tarver]

On 13 Dec, 04:39, Daniel Jomphe <danieljom...@gmail.com> wrote:
> > I'd guess the smart move would be to port Qi to ABCL - a version of
> > Common Lisp that runs on the JVM.  This would be much easier than a
> > port to Clojure.
>
> My feeling was that it would mean a lot more to port Qi to Clojure
> since Clojure fits really well in Java-as-a-Platform; if Qi was to
> inherit more interop capabilities thanks to a port to Clojure instead
> of ABCL, it would help it spread much more, especially since CL is
> mainstream-dead while Clojure is mainstream-interesting.  Therefore,
> if it's possible, such a port would be worth the supplemental efforts.
>
> Now, I can't yet compare ABCL's and Clojure's interop with Java.
>

ABCL seems very documentation lite (vide my remarks on 'Lisp for C21'
about CL library documentation) and I'm not a Java programmer.
Can anybody find any doc on ABCL? Its still very live. I'll send the
creators an email.

> I don't know if whatever missing interop features could be added
> straight from Qi, independently of the quality of the lisp
> implementation on top of which it's ported.
>
> I don't know either how much programming in Qi encourages us to ignore
> the underlying platform or not.  I assumed that we are encouraged to
> interact a lot with the underlying platform(s), and therefore thought
> it would be really interesting and empowering to be able to interact
> with a lisp that is itself well integrated into Java-as-a-Platform,
> and that also brings very elegant unified data structures to the
> table.  But if a port of Qi to Clojure means we don't care anymore
> about Clojure as long as it provides Java-interop access to Qi, then I
> suppose a port to ABCL would make much more sense, and then again, why
> not go straight to the most minimal possible lispy implementation so
> that we don't have a whole unused CL platform between Qi and that of
> Java.

Qi does use only a fraction of CL, so a port to a a smaller Lisp-like
language is possible. My feeling about CL is, its very powerful but
it is too big. Some of it should have been hived into libraries. Qi
uses probably 15% of CL. From memory this is what happened to ML; it
started in Lisp and became stand alone.

Qi can be learnt and understood without learning CL and the book is
written w.o. any supposition that the reader knows CL (or any
programming language). CL can be useful if you want to import
features into the language.

Read the thread on CL where people are upset because Clojure does not
support complex numbers, whereas CL does.

http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/61c085f495053ec4/ce7bbb0f2eea9010?hl=en&lnk=gst&q=clojure#ce7bbb0f2eea9010

QUOTE
Yeah, no complex number support! Very disappointing when I found out.
I even had an exchange with Rich Hickey on the issue. He says he's got
nothing against complex numbers obviously, but he hasn't got the time
to implement them, and for performance reasons it looks like it has to
be done in Java. I wanted to give it a try, but I am definitely no
Java programmer, so I've happily come back to good old Common Lisp.
I'm a mathematician and complex numbers are VERY important, and I
think CL (with few other languages) has got the best support in this
respect.
UNQUOTE

Moving to a stand alone implementation means spending a lot of time
doing stuff like this; reimplementing GCs etc. CL people would
probably like Qi to remain attached to CL.

> Finally, I'm not even sure if it would be really useful to bring Qi to
> the Java Platform; this hope of mine is based solely on the assumption
> that if ABCL, SISC, KAWA and Clojure are doing it, it must be for more
> than "just" using the JVM for platform portability.
>
> All this having been said, my concern is that we invest our energies
> in the Most Meaningful Solution.  And if this MMS implies porting to
> something different than a CL, then I believe we must be willing to
> spend the efforts now, rather than regretting later we didn't do it
> now, and then dividing the community by starting anew on top of
> something else.

An idea is to make the book viewable online in the same way that
Wolfram's 'A New Kind of Science' can be viewed - as a series of
images. Hence users can browse the book and use a searchable index.

Basically, as long as an implementation preserves the functionality of
the language spec in FPQi 2nd ed, then its fine. * I'd encourage
experimentation in changing platforms as long as the spec is
maintained.*

>
> Now, who am I to devise such plans for the future of Qi?  I think I

The terms of the license give you the freedom to that.

> should get back to my books and, eventually, to a REPL or two.  Before
> I do that, though, I wanted to ask you something.  I don't know why I
> didn't before, but it's only today that I read for the first time John
> Backus' 1978 paper.  I had never read a more convincing rebuttal of
> imperative programming (I'm yet to read Turner 1982).  And on page
> 624, we can read:
>
> "One advantage of this algebra over other proof techniques is that the
> programmer can use his programming language as the language for
> deriving proofs, rather than having to state proofs in a separate
> logical system that merely talks about his programs."
>
> Although Qi, in my understanding, doesn't make use of Backus' FP
> System's algebra, am I going too far when I believe that Qi achieves
> the feat of reconciling the programming language with proofs of the
> same language in a unifying way?
>
> Also, on the same page:
>
> "Our goal is to develop a foundation for the algebra of programs that
> disposes of the theoretical issues, so that a programmer can use
> simple algebraic laws and one or two theorems from the foundations to
> solve problems and create proofs in the same mechanical style we use
> to solve high-school algebra problems, and so that he can do so
> without knowing anything about least fixed points or predicate
> transformers."
>
> Again, am I going too far in believing that Qi marks another big point
> here, although it doesn't seem to make use of the said algebra?

To a degree yes; in order to realise Backus ideal in Qi what you need
is a program that would take a Qi program and output a set of
algebraic equations that represents the input program. A Qi program
is not exactly an algebra, because the Qi rules are order-sensitive.
However it is possible to do this provided you are willing to work
with conditional equations. The inverse transformation is really
quite easy. A set of conditional equations is trivially transformable
into Qi. This would enable the 'programmer [to] use simple algebraic

laws and one or two theorems from the foundations to solve problems
and create proofs in the same mechanical style we use to solve high-

school algebra problems'.

> In any case, this paper has been highly enlightening to me and I feel
> it's bad how I can't seem to find how Backus's Function-Level thinking
> got incorporated in modern Functional Languages.  Was Backus the only
> proponent and consumer of his ideas?  It looks like the latter all
> preferred to continue building their core on top of Church or Curry
> foundations (of which I'm no critique).  Concurrently, in my current
> understanding, the US went along Church with their Lisps and Schemes,
> while the UK went along Curry with their MLs.

Look under 'Equational Programming'.

Mark

[Daniel Jomphe]

Mark Tarver wrote:

> Qi does use only a fraction of CL, so a port to a a smaller Lisp-like
> language is possible.  My feeling about CL is, its very powerful but
> it is too big.  Some of it should have been hived into libraries.  Qi
> uses probably 15% of CL.  From memory this is what happened to ML; it
> started in Lisp and became stand alone.
>

> [...]

>
> CL can be useful if you want to import features into the language.
>

> Moving to a stand alone implementation means spending a lot of time
> doing stuff like this; reimplementing GCs etc. CL people would
> probably like Qi to remain attached to CL.

So if we want Qi to be highly desirable both to the Mainstream and
Scientific crowds, we must not tolerate any compromise in our
ambitions for Qi. Let's try to define the prioritized goals of such a
project:

1- In Qi's interest: 100% compliant with regard to the Qi standard
defined as of FPQi 2ed.;
2- Mainstream: first-class access to a wide range of contemporary
libraries;
3- Mainstream-Corporate: integrates easily with existing technology
investments;
4- Mainstream: first-class native deployment capabilities;
5- Scientific: first-class Number Tower support (and probably more).

Thinking of it, the Scientific crowd is already pleased with the
current Qi implementations on top of various CLs, aren't it? And if
ever this crowd would one day like to have #5 in Mainstream-Qi, I
suppose Qi would prove to be a really enjoyable language to implement
this hard-to-implement set of features. So let's ditch #5. We're
left with:

1- In Qi's interest: 100% compliant with regard to the Qi standard
defined as of FPQi 2ed.;
2- Mainstream: first-class access to a wide range of contemporary
libraries;
3- Mainstream-Corporate: integrates easily with existing technology
investments;
4- Mainstream: first-class native deployment capabilities.

Thus, we should target a highly corporate-used, mature and portable
VM; Sun's Java Platform is the best match, no doubt.

A- #1: Porting to ABCL would be the easiest. And would please #5 if
it was still important to us.
B- #2,3,4: Porting to a smaller lisp or to Clojure would probably be
better.

So choosing ABCL is the easy way, and Clojure is the best way (if it's
possible). Also, whatever choice we make, we help bring exposure both
to Qi and some lisp. All of this having been said, we're back to
square one : ABCL vs Clojure-or-SISC-or-etc.

Since it should be relatively easy to port Qi to ABCL, I guess the way
to go would be to start with this project. It will help us gain
knowledge of how Qi interacts with the Java platform. Then, we might
want to ditch this away as a fallback prototype and go for the hard
way if we still find it's valuable to do so. Concluding this way
gives me peace about whichever choice is made first. I probably saw
too big of a problem out of starting on the "wrong" java-lisp first.

> An idea is to make the book viewable online in the same way that
> Wolfram's 'A New Kind of Science' can be viewed - as a series of
> images.  Hence users can browse the book and use a searchable index.

Perhaps an easy way to achieve this would be to get either
books.google.com or amazon.com to do it. (Regarding amazon, the .com
is important because .uk probably doesn't propose this feature, based
on my usage of .ca.) They both scan books, present pages as images,
and allow people to search through them. They also try in some
reasonable ways to make sure people don't use them to read the
entirety of the book. Whatever way you find to get this online, I
think it's a really great and important idea, considering the book is
the standard.

> To a degree yes; in order to realise Backus ideal in Qi what you need
> is a program that would take a Qi program and output a set of
> algebraic equations that represents the input program.  A Qi program
> is not exactly an algebra, because the Qi rules are order-sensitive.
> However it is possible to do this provided you are willing to work
> with conditional equations.   The inverse transformation is really
> quite easy.  A set of conditional equations is trivially transformable
> into Qi.   This would enable the 'programmer [to] use simple algebraic
> laws and one or two theorems from the foundations to solve problems
> and create proofs in the same mechanical style we use to solve high-
> school algebra problems'.

Good; thanks for the explanation.

> Look under 'Equational Programming'.

I'll sure do. By the way, I overlooked your correction re: SML 1990 -
> SML 1987. Thank you, I'll use it.

[Mark Tarver]

> 5- Scientific: first-class Number Tower support (and probably more).
>
> Thinking of it, the Scientific crowd is already pleased with the
> current Qi implementations on top of various CLs, aren't it?  And if
> ever this crowd would one day like to have #5 in Mainstream-Qi, I
> suppose Qi would prove to be a really enjoyable language to implement
> this hard-to-implement set of features.  So let's ditch #5.

Yes; CL is pretty good with numerical stuff. Also there's a large
math'l library with CL. See http://www.cliki.net/Mathematics.

> Thus, we should target a highly corporate-used, mature and portable
> VM; Sun's Java Platform is the best match, no doubt.

I agree Java would be good.

> Since it should be relatively easy to port Qi to ABCL, I guess the way
> to go would be to start with this project.  

I think thats right. Its an obvious course and poses the least
apparent pain.

> It will help us gain
> knowledge of how Qi interacts with the Java platform.  Then, we might
> want to ditch this away as a fallback prototype and go for the hard
> way if we still find it's valuable to do so.  

That seems sensible.

> > An idea is to make the book viewable online in the same way that
> > Wolfram's 'A New Kind of Science' can be viewed - as a series of
> > images.  Hence users can browse the book and use a searchable index.
>
> Perhaps an easy way to achieve this would be to get either
> books.google.com or amazon.com to do it.  

I've got the technology on my machine and the job is well in hand.

> Whatever way you find to get this online, I
> think it's a really great and important idea, considering the book is
> the standard.

Thanks; credit to Wolfram though for showing the way.

Mark

[Daniel Jomphe]

I had a few free hours today so I setup my computer for a first, quick
try at building Qi on ABCL.

Following your instructions for porting Qi, I went to configure
features_load_1.lsp and things went pretty smoothly until I reached
(DEFUN save () ...). I didn't find ABCL's way to save a lisp image.
Anyways, it felt good to say that it *could* be as easy as just
configuring this file and letting it go afterwards. Let's hope ABCL's
core is up to the task, and that it does actually work with lisp
images.

We should soon know; I'm waiting for an answer on the mailing list.
http://sourceforge.net/mailarchive/forum.php?thread_name=42bd03f50812132100t45127a5fn343f27f02eb1b868%40mail.gmail.com&forum_name=armedbear-j-devel

I'm not much familiar with this concept of images, but it looks as
easy as saying that this thing is meant to load/use/save the state
between each lisp session (most probably on demand). In preparation
for your release of Qi, I read two books on CL in the last few months
(ANSI Common Lisp - PG, Practical CL - PS), but they didn't mention
this aspect (I'm not 100% done with P.CL), and I'm yet to start
programming something in CL. Anyways, my priority is not learning CL -
it's learning the pure functional way. I just wanted as much CL
background as I could get before I dive into any serious lisp-related
language. My intention is to learn with Qi at home and with Clojure at
work whenever possible, unless it comes to make more sense to use Qi-
on-top-of-java at work.

Cheers

[Mark Tarver]

On 14 Dec, 05:21, Daniel Jomphe <danieljom...@gmail.com> wrote:
> I had a few free hours today so I setup my computer for a first, quick
> try at building Qi on ABCL.
>
> Following your instructions for porting Qi, I went to configure
> features_load_1.lsp and things went pretty smoothly until I reached
> (DEFUN save () ...). I didn't find ABCL's way to save a lisp image.
> Anyways, it felt good to say that it *could* be as easy as just
> configuring this file and letting it go afterwards. Let's hope ABCL's
> core is up to the task, and that it does actually work with lisp
> images.
>

> We should soon know; I'm waiting for an answer on the mailing list.http://sourceforge.net/mailarchive/forum.php?thread_name=42bd03f50812...

>
> I'm not much familiar with this concept of images, but it looks as
> easy as saying that this thing is meant to load/use/save the state
> between each lisp session (most probably on demand). In preparation
> for your release of Qi, I read two books on CL in the last few months
> (ANSI Common Lisp - PG, Practical CL - PS), but they didn't mention
> this aspect (I'm not 100% done with P.CL), and I'm yet to start
> programming something in CL. Anyways, my priority is not learning CL -
> it's learning the pure functional way. I just wanted as much CL
> background as I could get before I dive into any serious lisp-related
> language. My intention is to learn with Qi at home and with Clojure at
> work whenever possible, unless it comes to make more sense to use Qi-
> on-top-of-java at work.
>
> Cheers

The standard for CL never fixed on a command for save. In fact saving
an image can be tricky with commercial Lisps. If you have problems,
then I suggest you follow the workaround I used in run_allegro.lsp,
which loads the compiled .lsp files for Qi and starts the Qi top
level. Its pretty quick - takes about 5 seconds.

Mark

[Daniel Jomphe]

> The standard for CL never fixed on a command for save. In fact saving
> an image can be tricky with commercial Lisps. If you have problems,
> then I suggest you follow the workaround I used in run_allegro.lsp,
> which loads the compiled .lsp files for Qi and starts the Qi top
> level. Its pretty quick - takes about 5 seconds.

I skipped the saving part for now, to follow your workaround. Now, if
it's ever that we'll find out I'm a CL beginner, it's now. Compiling
features_load_1 goes fine. But not YACC, for (probably) an obvious
reason:

=====
; Compiling /Users/Reniel/dev/tools/QiII1.01-ABCL/Lisp/
YACC_load_2.lsp ...
[...]
Error loading /Users/Reniel/dev/tools/QiII1.01-ABCL/Lisp/install.lsp
at line 32 (offset 1331)
Debugger invoked on condition of type ERROR:
Unrecognized character name: "Escape"
=====

So ABCL does support #\Space for example, but not #\Escape. I thought
#\Escape was added by Qi since it's not part of CL's standard, but
unless I'm wrong, Qi really relies on this non-standard convenience.

I looked at ABCL's source code to confirm it doesn't support #
\Escape. Now, were I to be an experienced CLer, I would probably have
thought of an easy workaround. At least, I'm a seasoned Java-er so it
would be really easy for me to add support for #\Escape to ABCL. But
before I do this, let's see if you don't come up with such a CL-
experienced-easy-workaround.

I hope to have some time tonight to hack a bit more on Qi-ABCL. It's
a great prospect, so motivation isn't lacking.

If ever this porting is going to become a bit arduous, I'll definitely
put it under public source-control so experimented people can
contribute easily.

[Mark Tarver]

On 14 Dec, 15:33, Daniel Jomphe <danieljom...@gmail.com> wrote:
> > The standard for CL never fixed on a command for save.  In fact saving
> > an image can be tricky with commercial Lisps.  If you have problems,
> > then I suggest you follow the workaround I used in run_allegro.lsp,
> > which loads the compiled .lsp files for Qi and starts the Qi top
> > level.  Its pretty quick - takes about 5 seconds.
>
> I skipped the saving part for now, to follow your workaround.  Now, if
> it's ever that we'll find out I'm a CL beginner, it's now.  Compiling
> features_load_1 goes fine. But not YACC, for (probably) an obvious
> reason:
>
> =====
> ; Compiling /Users/Reniel/dev/tools/QiII1.01-ABCL/Lisp/
> YACC_load_2.lsp ...
> [...]
> Error loading /Users/Reniel/dev/tools/QiII1.01-ABCL/Lisp/install.lsp
> at line 32 (offset 1331)
> Debugger invoked on condition of type ERROR:
>   Unrecognized character name: "Escape"
> =====
>
> So ABCL does support #\Space for example, but not #\Escape.  I thought
> #\Escape was added by Qi since it's not part of CL's standard, but
> unless I'm wrong, Qi really relies on this non-standard convenience.

Its in every Lisp I've used so far. Try

(CODE-CHAR 27)

and see what is printed.

Mark

[Mark Tarver]

It may be that ABCL has not implemented the extended character set
common to most CLs.

Mark

> Mark- Hide quoted text -
>
> - Show quoted text -

[Daniel Pezely]

> It may be that ABCL has not implemented the extended character set
> common to most CLs.

Officially, only 96 characters are defined by the ANSI CL spec, and
these are NOT guaranteed to be ASCII values even though most current
implementations have elected to preserve that mapping.

Per the question of this thread, #\Escape is outside those 96 standard
characters.

Further reading:

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#standard_character

http://www.lispworks.com/documentation/HyperSpec/Body/02_ac.htm

-Daniel
--
first name at last name dot com

[Mark Tarver]

Yes; I found that out this afternoon. CL is officially sub-ASCII! It
seems that the standard was never officially revised and so ABCL is
technically compliant.

On 14 Dec, 22:53, Daniel Pezely <dpez...@gmail.com> wrote:
> > It may be that ABCL has not implemented the extended character set
> > common to most CLs.
>
> Officially, only 96 characters are defined by the ANSI CL spec, and  
> these are NOT guaranteed to be ASCII values even though most current  
> implementations have elected to preserve that mapping.
>
> Per the question of this thread, #\Escape is outside those 96 standard  
> characters.
>
> Further reading:
>

> http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#st...

[Mark Tarver]

Practical suggestion.

1. Globally substitute a standard char for #\Escape in the .lsp files
eg. #\f and recompile.
2. Ask ABCL if and when they will provide the extended character set.

Mark

On 14 Dec, 15:33, Daniel Jomphe <danieljom...@gmail.com> wrote:

[Daniel Jomphe]

> Practical suggestion.
>
> 1.  Globally substitute a standard char for #\Escape in the .lsp files
> eg. #\f and recompile.
> 2.  Ask ABCL if and when they will provide the extended character set.

Thanks for your help. I lost my time having problems with my
internet connection. There's some problems with my Mac's networking
drivers since the latest Apple update came in ~2 months ago. They've
really screwed up my enjoyment of the platform for that long.

Anyways, ABCL's 12th release went out today; I'll try to download it
tomorrow, as I have no luck doing so right now. If the download
doesn't work, I'll continue with 11 with your suggestion.

If ever there's someone thrilled by the possibility of having Qi
working on ABCL really soon, and would like to make it work faster
than I am making it, don't fear hurting my feelings, go ahead. Unless
my intuition is wrong, it looks like it's gonna be really easy.

[Daniel Jomphe]

> 2.  Ask ABCL if and when they will provide the extended character set.

I suppose if it's not already done, it means they wanted to keep the
implementation as minimalistic as possible and won't really be open to
add them. But there's no wrong in asking.

Also: good news, my downloading ABCL 12 finally worked.

We'll see tomorrow.

[Anton Tayanovskyy]

Hi,

I'm a LISP beginner as well. Just a couple of weeks ago I got QiII
sort of running on ABCL. Here's a way to teach ABCL about #\Escape
(may put it in install.lsp):

; Modify the ABCL reader to know about #\Escape
#+ ABCL
(SET-DISPATCH-MACRO-CHARACTER
(CODE-CHAR 35) ; #\#
(CODE-CHAR 92) ; #\\
#'(LAMBDA (stream subchar arg)
(LET ((c (READ-CHAR stream)))
(UNREAD-CHAR c stream)
(IF (OR (EQL c (CODE-CHAR 69)) ; #\E
(EQL c (CODE-CHAR 101))) ; #\e
(PROGN
(DOTIMES (i 6)
(READ-CHAR stream))
(CODE-CHAR 27)) ; #\Escape
(APPLY
#'SYSTEM::SHARP-BACKSLASH
(LIST stream subchar arg))))))

With this the system seems to work, but it does not pass all of the
tests, often resulting in stack overflow.

I think the reason is that ABCL does not systematically implement tail
call optimization, and QiII relies on this. Clojure doesn't either. Of
all lispish languages I know on the JVM, I think just the schemes
(Kawa and SISC) do TCO, and they do pay a large performance price for
this.
So the hard part would be to have Qi not rely on TCO.

--A

[Raoul Duke]

> With this the system seems to work.

woah, cool!

> (Kawa and SISC) do TCO, and they do pay a large performance price for
> this.

http://lambda-the-ultimate.org/node/3106#comment-45302

apparently various different approaches to 'faking' TCO, none of which
are fast on the JVM. supposedly years in the future some JVM (e.g. Da
Vinci) will have TCO built-in. yeah, right, some day.

[Mark Tarver]

Nice work.

Having no TCO is not so bad if you can program the size of the call
stack. In the standard CL spec you cannot. If ABCL can be tweaked to
allow this, it may be fine.

Where does the system fail on the tests?

Mark

On 15 Dec, 07:53, "Anton Tayanovskyy" <anton.tayanovs...@gmail.com>
wrote:

> > We'll see tomorrow.- Hide quoted text -