Re: forth vs common lisp

[Hugh Aguilar]

On Apr 18, 12:34 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> In comp.lang.forth, Hugh Aguilar wrote:
>
> > I think that Lisp is a better language for desktop-computer
> > programming than Forth,
>
> ...because?

Because the Lispers have put in the time and effort to provide
beaucoup libraries of useful code. In Forth you have to write
everything from scratch --- nobody has time to dink around all day
implementing low-level code before even starting the application
program --- the work world is all about being productive.

Also, CL has CLOS and Racket has something similar. This can help
speed up script writing. I don't think that it is all that useful for
large programs, but I haven't written enough large programs in my life
to really comment. I don't think that it is appropriate for Forth at
all.

I think that Forth could be used for large programs on the desktop,
but only if somebody were willing to invest the time and effort into
writing a lot of libraries of support code (this implies a big budget
and a relaxed schedule) --- what has been available for decades in the
Lisp community. Both Forth and Lisp are extensible, so these are the
only two languages that I would consider for a large project. Nobody
wants to hire me (or any Forther) to write a large program though, so
we will never know how well Forth would work. The largest Forth
program I've written was the dxf to gcode translator that I did at
Testra, and it was a major PITA primarily because of a complete lack
of libraries of data-structures (it would be a lot easier now with my
novice package available; I was primarily motivated by that experience
when I wrote my novice package) --- my MFX cross-compiler at Testra
was also quite large, but a compiler is so different from an
application program that I wouldn't really consider it to be relevant
to this discussion.

Forth failed, not because Forth is a bad language, but rather because
of a lack of leadership. Nobody was writing libraries of useful code.
Nobody was serious about supporting application programming ---
everybody was dinking around with science-fair projects involving
compiler-writing that had no practical value (there is some "dink-
around disease" in the Lisp world too, but it is an epidemic in the
Forth world). Also, the ANS-Forth standard was horrible --- this was
also the result of a lack of leadership --- it was too wishy-washy in
that it waffled on important aspects of the language, and it also
failed to provide myriad useful functions that are very difficult to
implement in Forth and should certainly be implemented in assembly-
language (but they have to be in the standard for assembly-language to
be used). There was way too much concern about legacy code, and not
enough concern about the future --- and the result was the Forth
didn't have a future at all --- Forth effectively died in 1994.

> Not writing anything in Lisp - but I'm using TCL, which has somewhat
> Lisp-like syntax. And although one doesn't need to use as many
> parentheses, as in case of Lisp - it's still a problem: to keep code
> readable, there is a must to use loads of transitory variables. Only to
> replace something like this:
>
>   set a [doIt1 [doIt2 [doIt3 $a1 $b1 $c1] [doIt4 $x1 $y1 $z1]] [doIt5 [doIt6 $a2 $b2 $c2] [doIt7 $x2 $y2 $z2]]]
>
> with:
>
>   set b [doIt3 $a1 $b1 $c1]
>   set c [doIt4 $x1 $y1 $z1]
>   set d [doIt6 $a2 $b2 $c2]
>   set e [doIt7 $x2 $y2 $z2]
>   set a [doIt1 [doIt2 $a $c] [doIt5 $d $e]]
>
> Using Lisp it can be even worse, it seems. Lisp seems to me (well, I may
> be wrong) a language for people more "purely theoretically" - and less
> technically - oriented. For them indeed it can be "most powerful LitW",
> since it better suits them.

This seems to be the same argument made against Forth, in that bad
Forthers tend to have too much "stack-juggling" --- there are several
ways to avoid this in Forth, and likely in Lisp too. I typically try
to package data into structs, and the structs into lists, as my
primary technique (this is why my novice package has so much support
for lists, and also why I think that I would be a natural for Lisp).

I don't really know enough about Lisp to debate this subject beyond
what I've said here. I've never written any non-trivial program in
Lisp. Note that I cross-posted this to comp.lang.lisp --- maybe
somebody who knows what they are talking about can join the
conversation.

[Pascal J. Bourguignon]

Hugh Aguilar <hughag...@yahoo.com> writes:

> On Apr 18, 12:34 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
> wrote:
>> In comp.lang.forth, Hugh Aguilar wrote:
>>
>> > I think that Lisp is a better language for desktop-computer
>> > programming than Forth,
>>
>> ...because?
>

> I think that Forth could be used for large programs on the desktop,
> but only if somebody were willing to invest the time and effort into
> writing a lot of libraries of support code (this implies a big budget
> and a relaxed schedule) --- what has been available for decades in the
> Lisp community. Both Forth and Lisp are extensible, so these are the
> only two languages that I would consider for a large project.

There was a Forth implementation on MacOS that allowed to write Mac
applications.

There were and are GUI libraries, eg. the Mac OS Toolbox, the Mac OS X
Cocoa framework, Gtk, Qt, etc. The only thing you need from a language,
is some programmer-friendly FFI to be able to call those libraries
easily, and you're all set to write big applications.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Ron Aaron]

On 04/19/2012 05:08 AM, Pascal J. Bourguignon wrote:

> There were and are GUI libraries, eg. the Mac OS Toolbox, the Mac OS X
> Cocoa framework, Gtk, Qt, etc. The only thing you need from a language,
> is some programmer-friendly FFI to be able to call those libraries
> easily, and you're all set to write big applications.

Yes. Reva Forth has an easy-to-use FFI, and supports Windows, Linux and
OS/X. Enough work was put into an "IUP" interface to allow writing GUI
applications (cross-platform) -- though it's a non-ANS Forth.

Win32Forth also has an easy FFI, and so do others.

As far as LISP goes, I've found the multiplicity of parentheses to be
very distracting, but then I never had to write anything beyond a few
macros in it.

[Roelf Toxopeus]

In article <87d374j...@kuiper.lan.informatimago.com>,

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> Hugh Aguilar <hughag...@yahoo.com> writes:
>
> > On Apr 18, 12:34 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
> > wrote:
> >> In comp.lang.forth, Hugh Aguilar wrote:
> >>
> >> > I think that Lisp is a better language for desktop-computer
> >> > programming than Forth,
> >>
> >> ...because?
> >
> > I think that Forth could be used for large programs on the desktop,
> > but only if somebody were willing to invest the time and effort into
> > writing a lot of libraries of support code (this implies a big budget
> > and a relaxed schedule) --- what has been available for decades in the
> > Lisp community. Both Forth and Lisp are extensible, so these are the
> > only two languages that I would consider for a large project.
>
> There was a Forth implementation on MacOS that allowed to write Mac
> applications.

There were _many_ Forth implementations on the Mac which allowed to
write Mac applications. Some legendary: Neon, MacForth, Mach2,
PocketForth. All fully integrated in the MacOS and GUI.

The current crop of Forth systems on the Mac like iMops, MFonVFX,
SwiftForth, iForth and VFX all have facilities to write (big) Mac
applications. And at least two vendors have expertise wrt large projects.

> There were and are GUI libraries, eg. the Mac OS Toolbox, the Mac OS X
> Cocoa framework, Gtk, Qt, etc. The only thing you need from a language,
> is some programmer-friendly FFI to be able to call those libraries
> easily, and you're all set to write big applications.

Indeed, and that's what most if not all of the 'Desktop Forth systems'
on the Mac, Atari, Amiga, Archimedes etc.etc., have build-in since at
least 1985. How do you all think we program these computers (aside of
bare metal and straight on the CRT)???

Having a FFI and _using_ it, is Gefundenes Fressen for a desktop Forth
user...

This should be something for the FAQ (albeit formulated differently ;0)

-roelf

[Hugh Aguilar]

On Apr 18, 8:08 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> Hugh Aguilar <hughaguila...@yahoo.com> writes:
> > On Apr 18, 12:34 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
> > wrote:
> >> In comp.lang.forth, Hugh Aguilar wrote:
>
> >> > I think that Lisp is a better language for desktop-computer
> >> > programming than Forth,
>
> >> ...because?
>
> > I think that Forth could be used for large programs on the desktop,
> > but only if somebody were willing to invest the time and effort into
> > writing a lot of libraries of support code (this implies a big budget
> > and a relaxed schedule) --- what has been available for decades in the
> > Lisp community. Both Forth and Lisp are extensible, so these are the
> > only two languages that I would consider for a large project.
>
> There was a Forth implementation on MacOS that allowed to write Mac
> applications.
>
> There were and are GUI libraries, eg. the Mac OS Toolbox, the Mac OS X
> Cocoa framework, Gtk, Qt, etc.  The only thing you need from a language,
> is some programmer-friendly FFI to be able to call those libraries
> easily, and you're all set to write big applications.

I'm not talking about wrappers around libraries (C/C++ on Windows, or
Objective C on the Mac) for GUI or database or whatever. If that is
what you want, then you could use a scripting language such as Python
or Lua as a front-end for C.

I'm talking about low-level libraries such as my novice package. All
of this stuff has to be written in Forth. Most of this provides data
structures such as lists, arrays and associative arrays. This is the
kind of stuff that you *program* in --- there is a lot of difference
between writing a program that does something and writing a script
that glues together underlying code (usually written in C by somebody
else) that does something. There is a difference between a programmer
and a script-kiddie.

If you look at my novice package, you will see many example programs.
In every case, my program did something (analyze LowDraw poker,
generate slide-rule images in gcode and PostScript, solve the N-Queens
puzzle, etc.) --- none of these are scripts gluing together somebody
else's code.

I'm not saying that wrappers around C libraries aren't useful. If I
need a database, then I would rather use Berkeley-DB than write my own
(especially as I don't know anything about database internals). If I
need a GUI (I hope that I never do!), then I would rather use QT than
write my own. I'm just saying that this is not the interesting part of
*programming* --- and it is not what my novice package provides ---
and it is not what I described as sorely missing from Forth but
largely available in Lisp.

[kodifik]

There is this stack-oriented language called Factor.
It has a quite good development environment.
It has lots of libraries (even openGL).
It is everything Forth should/could have been,
but it is not meeting a great welcome either.

From my ignorance, stack-orientation seems
a too low-level thing to mess with.
I mean: ideally, the compiler should take care of that.

[Andrew Haley]

The stack is just a way of communicating between functions, and it
gives you a simple way of expressing things.

Let's say you have a function X that takes three arguments and returns
two, and a function Y that takes two and returns one. You want to
create another function Z that is the composition of both, In Forth
that's

: z ( n1 n2 n3 - n) x y ;

In Haskell, a language I don't know, I think it's something like

int z
= y . x

In C it's

int z (int n1, int n2, int n3) {
int tmp, tmp1;
tmp = x (n1, n2, m3, &tmp1);
return y (tmp, tmp1);
}

Andrew.

[Tamas Papp]

On Thu, 19 Apr 2012 04:29:16 -0500, Andrew Haley wrote:

> In comp.lang.forth kodifik <kod...@eurogaran.com> wrote:
>> There is this stack-oriented language called Factor. It has a quite
>> good development environment. It has lots of libraries (even openGL).
>> It is everything Forth should/could have been, but it is not meeting a
>> great welcome either.
>>
>> From my ignorance, stack-orientation seems a too low-level thing to
>> mess with.
>> I mean: ideally, the compiler should take care of that.
>
> The stack is just a way of communicating between functions, and it gives
> you a simple way of expressing things.
>
> Let's say you have a function X that takes three arguments and returns
> two, and a function Y that takes two and returns one. You want to
> create another function Z that is the composition of both, In Forth
> that's
>
> : z ( n1 n2 n3 - n) x y ;

In CL, you can just do

(defun z (a b c)
(apply #'y (x a b c)))

provided that X and Y return the (multiple) results as lists.

That said, I would agree that Forth's syntax is more compact. But if
I were doing this a lot, I would just introduce a macro, eg

(defmacro def-composed (name &rest functions)
(let ((rest (gensym)))
(labels ((expand (functions)
(if functions
`(apply ,(car functions)
,(expand (cdr functions)))
rest)))
`(defun ,name (&rest ,rest)
,(expand functions)) )))

and just do

(def-composed z #'x #'y #'w ...)

Best,

Tamas

[Paul Rubin]

Tamas Papp <tkp...@gmail.com> writes:
>> : z ( n1 n2 n3 - n) x y ;
>
> In CL, you can just do
>
> (defun z (a b c)
> (apply #'y (x a b c)))

Yeah I think the comparisons were for pointfree style, i.e. the
combining word shouldn't care about the signatures of the component
words. It's been a while since I've done any CL, but you may want
something like

(defun z (&rest args)
(apply (compose x y) args))

where compose is defined as below.

> (defmacro def-composed (name &rest functions) ...

(defun compose (f g)
(lambda (&args)
(f (apply g args))))

if I'm not mistaken. I think this style is more prevalent in Scheme than CL.
I'm not sure in CL what you'd do about multiple-value returns.

[namekuseijin]

Em quinta-feira, 19 de abril de 2012 06h05min52s UTC-3, kodifik escreveu:
> From my ignorance, stack-orientation seems
> a too low-level thing to mess with.
> I mean: ideally, the compiler should take care of that.

precisely. Stack argument juggling is no more fun than writing boilerplate to java compilers or the doing the manual car/cdr dance in lisp programs...

[namekuseijin]

oh, flamewars are always so lovely...

Em quinta-feira, 19 de abril de 2012 05h03min14s UTC-3, Hugh Aguilar escreveu:
> I'm not talking about wrappers around libraries (C/C++ on Windows, or
> Objective C on the Mac) for GUI or database or whatever. If that is
> what you want, then you could use a scripting language such as Python
> or Lua as a front-end for C.
>
> I'm talking about low-level libraries such as my novice package. All
> of this stuff has to be written in Forth. Most of this provides data
> structures such as lists, arrays and associative arrays. This is the
> kind of stuff that you *program* in --- there is a lot of difference
> between writing a program that does something and writing a script
> that glues together underlying code (usually written in C by somebody
> else) that does something. There is a difference between a programmer
> and a script-kiddie.

That's quite a smug attitude towards tcl, perl, python, php and ruby if you ask me. If you can use lists, arrays and associative arrays, why can't they? Does it matter that in forth they are implemented in forth while in the others in C? You're as much of a user of already written code as they are.

That said, unless you're writing your own GUI toolkit, you're too using other people ready-made code. The fact that you're accessing them via forth-written FFI rather than C-wrappers is irrelevant: from the point-of-view of an application programmer, you're glueing together pieces of code written by someone else.

BTW, I wonder why there's no forth or stack-language at the shootout game:

http://shootout.alioth.debian.org/dont-jump-to-conclusions.php

[Hugh Aguilar]

Your poem doesn't rhyme very well. Here's my own effort:

there is a language called Factor
considered a Joy by every hactor
it uses quotations to juggle the stack
the designer must have been smoking crack
I'd rather be stretched on the ractor

Seriously, I tried Factor for a while, and wrote some small programs
in it. I didn't like it very well. I had expected that my Forth
background would help, but it didn't. Factor has a different flavor
from Forth. It uses quotations a lot, as a replacement for stack-
juggling words (DUP, OVER, SWAP, etc.), which I found hard to get used
to (Factor is derived from Joy and CL, not Forth directly, so it is a
cousin to Forth at the most).

The dynamic OOP is also very un-Forth-like. This was my biggest
problem; that I don't understand dynamic OOP. A lot of the terminology
was new to me. I struggled with this, especially as the documentation
is a reference and assumes that the user already knows how dynamic OOP
works. I think that dynamic OOP is a good thing for desktop-computer
programming, especially script writing (as I said earlier though, I am
dubious of dynamic OOP for large programs). Mostly the problem was my
own ignorance of dynamic OOP, and not necessarily Factor itself.

I decided that, because Lisp/Scheme has beaucoup documentation, I
should learn Lisp/Scheme instead --- and learn how dynamic OOP works
in that way. AFAIK, dynamic OOP was invented by the Lispers --- CLOS
was the original. I may go back to Factor later, if I don't like Lisp/
Scheme for some reason. Factor isn't any more Forth-like than Lisp/
Scheme though (despite its use of a stack), so it no longer has that
attraction to me.

One thing that I did take away from Factor, is the idea of having a
standard data-structure. Factor has "sequences" that it uses for most
everything, with most of the library oriented around working with
sequences. This inspired me to do the same in my novice package --- to
have most of the library oriented around working with one particular
data-structure. I chose linked lists (because I can't implement
sequences without GC), but the idea is pretty much the same. Also, I
liked the quotations. I thought that they were over-used in Factor
when they were used to replace stack-manipulation, but I did like
quotations for use in factoring (afaik, this is where the name
"Factor" comes from). I use something similar in my novice package. I
have EACH for traversing lists, and a lot of similar words that use a
"toucher" function to touch every node (I do this for both linked
lists and LLRB trees). I think that this is a great technique! When I
later come out with Straight Forth as an alternative to Forth-200x, it
will have closures that access the parent's local variables --- that
will be its primary feature.

I don't have very much interest in desktop-computer programming, so my
effort at learning dynamic OOP and all of that related stuff is going
pretty slowly. If I thought that there was a chance at getting a job
at any of this, I would be a lot more enthusiastic. The whole world is
going to Java, which I find absolutely horrible --- but if I really
was serious about getting a job I would bite the bullet and learn
Java, just like everybody else.

Slava told me that he thought the ColdFire was the smallest processor
that Factor could possibly run on. He hoped that Factor could someday
become important in the ARM world, similar to how Java is used in
smart phones now (he considers Factor to be a better language than
Java). I don't have much interest in those big processors though (and
I don't like using an OS either) --- I like programming 8-bit and 16-
bit processors, although they are rapidly becoming obsolete. Straight
Forth will support 16-bit processors --- the MSP430 will likely be my
first target --- the language will be oriented to robotics.

Slava's background is primarily in Common Lisp, btw.

[Rugxulo]

Hi,

On Apr 19, 4:15 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> Seriously, I tried Factor for a while, and wrote some small programs
> in it. I didn't like it very well. I had expected that my Forth
> background would help, but it didn't. Factor has a different flavor

> from Forth. Mostly the problem was my own ignorance of dynamic

> OOP, and not necessarily Factor itself.

That is the inherent problem with using multiple languages, the high-
end stuff never translates very easily. Esp. something as complex as
OOP (which I don't claim to really understand at all), which has
various ideas, features, and implementations that not everybody can
agree upon. It's hard enough just doing simple arithmetic and I/O in
procedural style across Algol-y languages.

> I decided that, because Lisp/Scheme has beaucoup documentation, I
> should learn Lisp/Scheme instead

Can't hurt, in theory (though I don't grok it), but everything relies
upon what standard, version, implementation, OS, tutorial, etc. that
you use. I honestly don't think Lisp is as universal and easy and
powerful and unified as you imply. Even MIT/GNU Scheme only supports
R5RS (1998), and even I know that R6RS (2007) has some critics. Though
I wouldn't dare to say any of it is deprecated based upon age alone.
But you know GNU overall is fairly big on standard support, so if even
they can't agree ....

> I don't have very much interest in desktop-computer programming, so my
> effort at learning dynamic OOP and all of that related stuff is going
> pretty slowly. If I thought that there was a chance at getting a job
> at any of this, I would be a lot more enthusiastic. The whole world is
> going to Java, which I find absolutely horrible --- but if I really
> was serious about getting a job I would bite the bullet and learn
> Java, just like everybody else.

There are various other languages using the Java VM as well as its JIT
(I suppose). So you aren't stuck to Java (language), specifically.

> Slava told me that he thought the ColdFire was the smallest processor
> that Factor could possibly run on. He hoped that Factor could someday
> become important in the ARM world, similar to how Java is used in
> smart phones now (he considers Factor to be a better language than
> Java).

Yes, see my recent post about Android. Java is heavily used there (and
Dalvik VM), but other stuff can work too. Though Android runs on
phones and tablets (ARM), which are quite different in specs. I'd be
hard-pressed to call a tablet minimal, but a phone is a much different
(smaller) thing, though I guess some phones (Apple's iPhone) are more
and more advanced in each version.

> I don't have much interest in those big processors though (and
> I don't like using an OS either) --- I like programming 8-bit and 16-
> bit processors, although they are rapidly becoming obsolete.

I like 16-bit DOS programming myself, but it's not of general use to
most people nor modern OSes (more or less). Indeed you won't get a lot
of sympathy there, sadly. Everything has long ago pretty much switched
to 32-bit or (gaining) 64-bit. That is our future, and the *nix /
Windows majority refuse anything less these days. So it's a safe bet,
though yeah, yet another bunch of changes.

Again, it's like we have to keep implementing VMs because we keep
getting stuck on non-portable crud, heh. And then we have to target
whatever language (or scripts or tools) to that all over again (and
again and ...).

> Straight Forth will support 16-bit processors --- the MSP430
> will likely be my first target --- the language will be oriented to robotics.

You can do robotics in Android, there are several videos on the SL4A
site as well as this (silly cat) example below (not mine but funny):

http://code.google.com/p/android-scripting/
http://www.damonkohler.com/search/label/sl4a

[Pascal J. Bourguignon]

Rugxulo <rug...@gmail.com> writes:

> Can't hurt, in theory (though I don't grok it), but everything relies
> upon what standard, version, implementation, OS, tutorial, etc. that
> you use. I honestly don't think Lisp is as universal and easy and
> powerful and unified as you imply.

There's only one standard: American National Standard ANSI INCITS
226-1994 (R2004).

All conforming implementations conform to that standard, therefore all
your conforming program will run equally on all the conforming
implementations.

(Most CL implementations are conforming, modulo bugs).

The big number of libraries and applications written in Common Lisp that
runs on half a dozen or more different CL implementations is proof that
Common Lisp is as universal, easy, powerful and unified as implied.

> Even MIT/GNU Scheme only supports R5RS (1998), and even I know that
> R6RS (2007) has some critics. Though I wouldn't dare to say any of it
> is deprecated based upon age alone. But you know GNU overall is
> fairly big on standard support, so if even they can't agree ....

Well, even if you consider older lisps, you can run their programs on
Common Lisp (that was the design purpose of Common Lisp):

http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html


And even if you consider older lisps as different from CL than Scheme,
you still have a sizeable intersection:

http://paste.lisp.org/display/122296

>> I don't have very much interest in desktop-computer programming, so my
>> effort at learning dynamic OOP and all of that related stuff is going
>> pretty slowly. If I thought that there was a chance at getting a job
>> at any of this, I would be a lot more enthusiastic. The whole world is
>> going to Java, which I find absolutely horrible --- but if I really
>> was serious about getting a job I would bite the bullet and learn
>> Java, just like everybody else.
>
> There are various other languages using the Java VM as well as its JIT
> (I suppose). So you aren't stuck to Java (language), specifically.

Indeed. For example we have two Common Lisp implementations targetting
the JVM: ABCL and CLforJava.

[lynx]

In <87r4vjh...@kuiper.lan.informatimago.com> "Pascal J. Bourguignon" <p...@informatimago.com> writes:

>All conforming implementations conform to that standard, therefore all
>your conforming program will run equally on all the conforming
>implementations.

>(Most CL implementations are conforming, modulo bugs).

I believe it may more correct to say that decent CL implementations come
quite close to conforming to the standard. (Close enough that the
differences to most users may be unimportant.) But I'm not aware of
even one implementation that is *completely* conforming, bugs
notwithstanding; and it is often explicitly stated in the documentation
how the implementation differs from the standard. This is hardly
peculiar to CL, of course.

[Marco Antoniotti]

Multiple values must be handled explicitly in CL. A working version of your COMPOSE would be

(defun compose* (f g)
(lambda (&rest args)
(multiple-value-call f (apply g args))))



CL-USER> (funcall (compose* #'vector #'values) 1 2 3)
#(1 2 3)


Cheers
--
MA

[Isaac Gouy]

On Apr 19, 12:10 pm, namekuseijin <namekusei...@gmail.com> wrote:
--snip--

> BTW, I wonder why there's no forth or stack-language at theshootoutgame:
>
> http://shootout.alioth.debian.org/dont-jump-to-conclusions.php

From that same page --

http://shootout.alioth.debian.org/dont-jump-to-conclusions.php#removed

And --

http://shootout.alioth.debian.org/gp4/which-programming-languages-are-fastest.php?calc=chart&bigforth=on&gforth=on

[Don Geddis]

lynx <rin...@kaze.void.null> wrote on Fri, 20 Apr 2012:
> But I'm not aware of even one implementation that is *completely*
> conforming, bugs notwithstanding; and it is often explicitly stated in
> the documentation how the implementation differs from the standard.

Is this meant to be a meaningful criticism?

The standard itself has some inconsistencies, in some of the deep dark
recesses, so it's probably logically impossible for any real-world
implementation to "completely conform".

What seems more reasonable instead, as the standard itself says, is that
an implementation "purports to conform". Which means that it treats
deviations from the standard as bugs.

Absent bugs, and absent problems with the standard itself, don't the
Common Lisp implementations basically follow the standard? You seem to
be suggesting that they are purposely making incompatible choices, which
doesn't seem likely.

For example, this looks like SBCL's page on ANSI Conformance:
http://www.sbcl.org/manual/index.html#ANSI-Conformance
Presumably, you mean something more like this list for Allegro:
http://www.franz.com/support/documentation/8.2/doc/implementation.htm#compliance-1
I think an interested reader can scan that list, and decide if it
prevents any feasible danger for their conforming Common Lisp code from
failing to run properly on that implementation.

-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org

[lynx]

In <87lilqe...@mail.geddis.org> Don Geddis <d...@geddis.org> writes:

>lynx <rin...@kaze.void.null> wrote on Fri, 20 Apr 2012:
>> But I'm not aware of even one implementation that is *completely*
>> conforming, bugs notwithstanding; and it is often explicitly stated in
>> the documentation how the implementation differs from the standard.

>Is this meant to be a meaningful criticism?

Of Common Lisp? No. It was only meant to clarify the statement I was
responding to, which seemed to suggest that the playing field was
uniform and that all "conforming" programs would run without any
modification. It seems rare for a CL program of any size to not need at
least a few bits of conditional compilation to satisfy idiosyncrasies
with the different "standard" implementations. Again, this is hardly
peculiar to CL. Nor do I think it's necessarily a bad thing.

>I think an interested reader can scan that list, and decide if it
>prevents any feasible danger for their conforming Common Lisp code from
>failing to run properly on that implementation.

And I believe I implied that well in my "criticism."

[Kaz Kylheku]

On 2012-04-20, lynx <rin...@kaze.void.null> wrote:
> modification. It seems rare for a CL program of any size to not need at
> least a few bits of conditional compilation to satisfy idiosyncrasies
> with the different "standard" implementations. Again, this is hardly
> peculiar to CL. Nor do I think it's necessarily a bad thing.

If you were to put some concrete numbers on quantifiers like "any size"
and "rare", what would they be?

[lynx]

I'm not sure hard numbers are appropriate here, although you are
probably correct in nitpicking my nitpicking. It is true that vague
quantifiers are generally not helpful.

As for "rare," it's just my general impression. Certainly someone who
delves into a different application domain could come away with a
different impression: all or most of the code they want or have ever
been interested in Just Works without needing special conditionals (or
at least some quick source tweaks) for different implementions. By any
chance, has this been your experience? It was not mine. Nor was it the
experience of anyone I used to know who used the language.

As for size, I was deliberate in avoiding a number on this one. I think
a project that takes more than a weekend to hack out the skeleton for is
generally a project of some substance. Hypothetically, a project of
150k lines of code assembled by a small team could probably be
generically written to avoid flagging most implementations, whereas a
much smaller project of only 10k lines written by a single programmer
might be nearly impossible to do this with. What is being built has a
lot to do with it, of course. Others will have very different notions
of size than I do, of course, which I assume is why you asked.

[Rugxulo]

Hi,

On Apr 19, 10:24 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> Rugxulo <rugx...@gmail.com> writes:
> > Can't hurt, in theory (though I don't grok it), but everything relies
> > upon what standard, version, implementation, OS, tutorial, etc. that
> > you use. I honestly don't think Lisp is as universal and easy and
> > powerful and unified as you imply.
>
> There's only one standard: American National Standard ANSI INCITS
> 226-1994 (R2004).

I really didn't mean to cc to comp.lang.lisp here, but I forgot to
remove it (like I did with some other posts). I was just replying in
very general terms to Hugh.

I didn't mean specifically Lisp (as I don't know it) here, just that
any "language" isn't ever as perfectly supported and available as I
always hope it is.

And I was actually referring to the fact that Common Lisp and Scheme
(and other variants) are quite different, yet sometimes people tend to
lump them together unfairly.

> All conforming implementations conform to that standard, therefore all
> your conforming program will run equally on all the conforming
> implementations.

Easier said than done, but I'll take your word for it.

> (Most CL implementations are conforming, modulo bugs).
>
> The big number of libraries and applications written in Common Lisp that
> runs on half a dozen or more different CL implementations is proof that
> Common Lisp is as universal, easy, powerful and unified as implied.

Half a dozen isn't a lot for an entire world. Also, believe it or not,
I'm specifically thinking about FreeDOS and its lack of ports for
various languages. Though I haven't looked too hard for Lisp(s), but I
assume it's not well-supported there (except maybe if translated to
C). Yes, I know it's 2012, but I personally don't consider DOS that
obscure or niche or old, esp. as it used to be on every PC by default.
So not finding working ports, even old ones, frustrates me when people
claim how "portable" their stuff is. I don't expect sympathy (by far),
and I really hate to even bring it up here, but it's just my
preference. So supporting the obligatory Mac, Win, Linux (or more
likely Win + POSIX) isn't enough reason to brag, IMO.

> > Even MIT/GNU Scheme only supports R5RS (1998), and even I know that
> > R6RS (2007) has some critics. Though I wouldn't dare to say any of it
> > is deprecated based upon age alone.  But you know GNU overall is
> > fairly big on standard support, so if even they can't agree ....
>
> Well, even if you consider older lisps, you can run their programs on
> Common Lisp (that was the design purpose of Common Lisp):
>
> http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html

But is that a fluke or a real consideration? I mean, I know some
languages are strict supersets, but usually "compatibility" is broken
in the name of new stuff. I'm not actively criticizing anyone, just
saying, it's frustrating (just in general) trying to get code working
between implementations. Most people never limit themselves to the
lowest common denominator, they often rely on latest greatest only, so
certain code won't run on older than Python 2.7, Perl 5.10, Ada2005,
etc. Frustrating when 2.4.2, 5.8.8, '95 (etc. etc.) aren't good enough
for almost anything anymore.

Yeah yeah, I know, write my own stuff from scratch. Again, easier said
than done.

> And even if you consider older lisps as different from CL than Scheme,
> you still have a sizeable intersection:
>
> http://paste.lisp.org/display/122296

Yes, I forgot about this, I'd barely seen Emacs cl compatibility
before, very interesting. Though honestly you could write a shim or
translator to cover any language dialect's deficits, but it's still
cool.

> > There are various other languages using the Java VM as well as its JIT
> > (I suppose). So you aren't stuck to Java (language), specifically.
>
> Indeed.  For example we have two Common Lisp implementations targetting
> the JVM:  ABCL and CLforJava.

I think I heard that there is some work being done for Scheme for
SL4A. So that's good for you guys.

[Pascal J. Bourguignon]

Rugxulo <rug...@gmail.com> writes:

> And I was actually referring to the fact that Common Lisp and Scheme
> (and other variants) are quite different, yet sometimes people tend to
> lump them together unfairly.

Yes, they should not be lumped together, but I don't think they're that
different either. Of course there are differences, but once you know
them, there are more similarities.

>> All conforming implementations conform to that standard, therefore all
>> your conforming program will run equally on all the conforming
>> implementations.
>
> Easier said than done, but I'll take your word for it.

You just need to know the language (vs. knowing an
implementation). Ie. read the CLHS instead of reading the implementation
notes.

>> (Most CL implementations are conforming, modulo bugs).
>>
>> The big number of libraries and applications written in Common Lisp that
>> runs on half a dozen or more different CL implementations is proof that
>> Common Lisp is as universal, easy, powerful and unified as implied.
>
> Half a dozen isn't a lot for an entire world.

It is, because it is the 99% of the implementations that are actually
used.

> Also, believe it or not,
> I'm specifically thinking about FreeDOS and its lack of ports for
> various languages.

That's because FreeDOS is not used. It's part of the 1% of unused stuff.

But I agree that we lack an easily retarggetable CL implementation.

> Though I haven't looked too hard for Lisp(s), but I
> assume it's not well-supported there (except maybe if translated to
> C). Yes, I know it's 2012, but I personally don't consider DOS that
> obscure or niche or old, esp. as it used to be on every PC by default.
> So not finding working ports, even old ones, frustrates me when people
> claim how "portable" their stuff is. I don't expect sympathy (by far),
> and I really hate to even bring it up here, but it's just my
> preference. So supporting the obligatory Mac, Win, Linux (or more
> likely Win + POSIX) isn't enough reason to brag, IMO.

Your best chance would be to use an old MS-DOS Lisp. Unfortunately,
there were more proprietary lisps than open source lisps, so while you
may find binaries running on MS-DOS, it's possible they won't run on
FreeDOS (I guess you'd need to recompile them for FreeDOS).

>> > Even MIT/GNU Scheme only supports R5RS (1998), and even I know that
>> > R6RS (2007) has some critics. Though I wouldn't dare to say any of it
>> > is deprecated based upon age alone.  But you know GNU overall is
>> > fairly big on standard support, so if even they can't agree ....
>>
>> Well, even if you consider older lisps, you can run their programs on
>> Common Lisp (that was the design purpose of Common Lisp):
>>
>> http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
>
> But is that a fluke or a real consideration?

It's a design purpose of Common Lisp.

If it was a fluke, then CL would not have any point.

> I mean, I know some
> languages are strict supersets, but usually "compatibility" is broken
> in the name of new stuff. I'm not actively criticizing anyone, just
> saying, it's frustrating (just in general) trying to get code working
> between implementations. Most people never limit themselves to the
> lowest common denominator, they often rely on latest greatest only, so
> certain code won't run on older than Python 2.7, Perl 5.10, Ada2005,
> etc. Frustrating when 2.4.2, 5.8.8, '95 (etc. etc.) aren't good enough
> for almost anything anymore.
>
> Yeah yeah, I know, write my own stuff from scratch. Again, easier said
> than done.

There are so called portability libraries for the new stuff. Indeed,
it's implemented differently in the different implementations, and this
is a good thing, until some de-facto standard emerge. Actually,
portability libraries define a de-facto standard API for the new stuff.
Implementations would be well advised to evolve toward those API, so the
portability libraries would become unnecessary, and a new round of
standardization could happen.

>> And even if you consider older lisps as different from CL than Scheme,
>> you still have a sizeable intersection:
>>
>> http://paste.lisp.org/display/122296
>
> Yes, I forgot about this, I'd barely seen Emacs cl compatibility
> before, very interesting. Though honestly you could write a shim or
> translator to cover any language dialect's deficits, but it's still
> cool.

Yes, and that's the point of lisp. Even if you have a small
intersection, or "lowest common denominator", you can implement more
sophisticated features over it.

>> > There are various other languages using the Java VM as well as its JIT
>> > (I suppose). So you aren't stuck to Java (language), specifically.
>>
>> Indeed.  For example we have two Common Lisp implementations targetting
>> the JVM:  ABCL and CLforJava.
>
> I think I heard that there is some work being done for Scheme for
> SL4A. So that's good for you guys.

[Don Geddis]

lynx <rin...@kaze.void.null> wrote on Fri, 20 Apr 2012:
> It was only meant to clarify the statement I was responding to, which
> seemed to suggest that the playing field was uniform and that all
> "conforming" programs would run without any modification.

I still believe that. Without looking at the errata lists ahead of
time, I bet you'd be pretty hard pressed to write a conforming CL
program that fails to execute properly on an implementation that
purports to conform.

> It seems rare for a CL program of any size to not need at least a few
> bits of conditional compilation to satisfy idiosyncrasies with the
> different "standard" implementations.

Well, now, that's a completely independent claim.

Interesting CL programs "of size" tend to use implementation-specific
features which are beyond the ANSI standard (such as multiprocessing or
network sockets). Implementation-specific extensions, quite naturally,
do indeed vary by implementation.

A second source of these kinds of changes, is that in some places the
ANSI standard is somewhat liberal (e.g. how logical pathnames map to
particular real-world OS filesystems), and implementations are free to
make different choices while still remaining conforming. A real, large,
CL program presumably needs to get something specific done, and it may
matter just exactly which valid choice the particular implementation
happened to choose. (To put it another way: programmers often just test
their code on their home implementation, and if it "works", they may not
realize that they've relied on assumptions which are not guaranteed by
the ANSI standard, but which instead just happen to be true in that one
implementation.)

So, I don't disagree that minor code tweaking is often required in
porting large CL programs between different CL implementations.

But I completely reject your claim that the cause is that the
implementations are actually violating the ANSI standard. The typical
minor exceptions to conforming are too obscure to matter to hardly any
program, even a large, significant one.

You've basically confused "conforming program" with "typical large
Common Lisp program (including extensions)". These aren't even close to
being the same thing.

-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org

Artificial Intelligence is the study of how to make real computers act like the
ones in movies.

[Tim Bradshaw]

On 2012-04-20 20:20:02 +0000, Rugxulo said:

> Half a dozen isn't a lot for an entire world.

It's 5 more than there are Perl implementations, for instance. And for
C, well there are obviously implementations which are not gcc, but I
bet they pretty much all have "be compatible with gcc" in their release
criteria.

[Tim Bradshaw]

On 2012-04-20 23:57:28 +0000, Don Geddis said:

> So, I don't disagree that minor code tweaking is often required in
> porting large CL programs between different CL implementations.

And if you think that is a problem, go and look at the source of a
widely-ported C program, say (this may be becoming less of an issue as
the number of platforms people care about drops towards "GCC/Linux/x86"
but that's not the point).

[Rupert Swarbrick]

lynx <rin...@kaze.void.null> writes:
...

> modification. It seems rare for a CL program of any size to not need at
> least a few bits of conditional compilation to satisfy idiosyncrasies
> with the different "standard" implementations. Again, this is hardly
> peculiar to CL. Nor do I think it's necessarily a bad thing.

Is this because implementations vary in their interpretation of the
standard, or is it that most CL programs "of any size" (in your opinion)
concern themselves with one or more of the following?

- multithreading
- GUI things
- networking
- making sense of path names...
- mmap and other posix-ness
- weird bits of MOP internals that would be convenient to access with ::

I would suggest that papering over these differences is what causes the
porting effort, not differences in implementations' quality wrt
following the CL standard.

Rupert

[Kaz Kylheku]

On 2012-04-20, Rugxulo <rug...@gmail.com> wrote:
> Also, believe it or not,
> I'm specifically thinking about FreeDOS and its lack of ports for
> various languages.

DOS Lunatic. *plonk*

[BruceMcF]

On Apr 20, 5:14 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> Rugxulo <rugx...@gmail.com> writes:

> > Also, believe it or not,
> > I'm specifically thinking about FreeDOS and its lack of ports for
> > various languages.

> That's because FreeDOS is not used.  It's part of the 1% of unused stuff.

You mean, in the sense that X86 PC/104 microcontrollers ship with some
other form of Embedded DOS rather than FreeDOS?

[Tim Bradshaw]

On 2012-04-21 18:04:28 +0000, BruceMcF said:

> You mean, in the sense that X86 PC/104 microcontrollers ship with some
> other form of Embedded DOS rather than FreeDOS?

I have no idea whether FreeDOS is used but it certainly is pretty
dangerous to assume that because something does not get used on
anything we think of as "a computer" its unused. In the same way it's
a mistake to think most of the DNA inside you is yours.

[BruceMcF]

Surely nobody would refer to FreeDOS as "not being in use" based on a
misconception that DOS itself was "not in use"? That would be silly.

[Tim Bradshaw]

On 2012-04-21 22:19:34 +0000, BruceMcF said:

> based on a
> misconception that DOS itself was "not in use"?

Well, it meets the "not used on anything you'd think of as a computer"
criteria, I think (at least if qualified by "in bits of the world I
care about", where "I" is the person who I think might think this, not
me).

[Hugh Aguilar]

On Apr 19, 10:49 am, John Passaniti <john.passan...@gmail.com> wrote:
> When you progress as a programmer so that you no longer are bothered
> by syntax but instead are focusing on the meaning of the code, you'll
> be a better programmer.

Threads such as this one, answering Gavino's question about Lisp
versus Forth as the "most powerful language in the world," tend to
devolve into a lot of nonsense --- we get posts like the above by
Passaniti, who has never written a computer program in his life
( other than some Perl scripts).

So lets consider a concrete example:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/dd8e30fcc7589749

This puzzle-problem came from CodeJam. To qualify for CodeJam, a
person would have to write the program in under 8 minutes. That is
actually quite fast; I think that most competent programmers would
take around 1/2 hour. I took about 3 hours to write the program in
Forth though. This was with my novice package. Without the novice
package, I would expect a Forther to take about 3 days. This is a big
part of why Forth failed to be adopted in the work world --- because
it is a waste of time --- as I said earlier, the work world is all
about production.

I think that my program very successfully illustrates everything that
is bad about Forth --- primarily a lack of useful libraries. This is
why I said earlier that Forth was not a good language for desktop-
computer programming. My Straight Forth will only be for micro-
controller programming --- I will have a "sister language" (most
likely Racket) that will be used for desktop-computer programming jobs
that are related in some way to micro-controller programming (usually
processing data that goes to or comes from the micro-controller).

We are talking about desktop-computer programming in this thread
though. I would like to see the CodeJam program written in Lisp or
Factor or any other desktop-computer language for comparison purposes.
You should certainly be able to write a shorter and simpler program
than I wrote. Please time how long it takes you to write your program
and mention that too (if it takes you more than 1 hour, then don't
bother posting your code). With some actual code to compare, this
discussion will become a lot more meaningful --- hopefully the non-
programmers (John Passaniti, Elizabeth Rather, etc.) will stop posting
messages --- everybody who participates, please move over to that
thread (you can cross-post to comp.lang.lisp or whatever forum is
appropriate for the language that you use).

[BruceMcF]

On Apr 21, 8:01 pm, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2012-04-21 22:19:34 +0000, BruceMcF said:
>> based on a
>> misconception that DOS itself was "not in use"?

> Well, it meets the "not used on anything you'd think of as a computer"

> criteria, ...

Like, unless its got a keyboard and a screen attached, or otherwise in
a room full of racks connected to the internet, its not a device that
requires programming?

Even a quick peak outside the window in the form of a quick google for
industrial SBC's would suggest that is an excessively narrow view of
the world.

[Tim Bradshaw]

On 2012-04-22 01:35:20 +0000, BruceMcF said:

> Like, unless its got a keyboard and a screen attached, or otherwise in
> a room full of racks connected to the internet, its not a device that
> requires programming?

Yes

>
> Even a quick peak outside the window in the form of a quick google for
> industrial SBC's would suggest that is an excessively narrow view of
> the world.

Exactly my point

[Elias Mårtenson]

On Sunday, 22 April 2012 09:12:18 UTC+8, Hugh Aguilar wrote:

I would like to see the CodeJam program written in Lisp or
> Factor or any other desktop-computer language for comparison purposes.

You will be. The CodeJam statistics page lists all contributions along with its source code: http://go-hero.net/jam/

It hasn't been updated for the 2012 results yet though.

[Kaz Kylheku]

FreeDOS may be used, but anything that you make portable to FreeDOS just for
the heck of it will likely not be used in those installations of FreeDOS.
DOS being used does not translate to your program for DOS being used.

Those kinds of systems have their specific software coded to their unique
requirements; they don't need your compiler for a functional language, or text
editor, swiss army knife OS utility or game or symbolic algebra system, or
whatever.

(If the deployers of that system were that keen on experimenting, they would
not be using DOS in the first place, would they!)

Porting a Common Lisp implementation to DOS, or making a new one, is a complete
waste of time. It's not something that will be used, even if DOS is.

So, this is something that would only be done for "fun", not for any economic
reasons, by someone who enjoys programming all by himself, for a crap system on
a crap architecture, something that nobody whatsoever will use and appreciate.

[Pascal J. Bourguignon]

Actually, I got a FreeDOS CD from DELL last time my (then) company
bought DELL computers (without MS-Windows, that was a Linux place).

So I think we may assume there's a certain number of FreeDOS
installation running on modern hardware.


Let FreeDOS users port a CL implementation on it (I'd start trying with
clisp or ecl), and they'll be all set.

[Pascal J. Bourguignon]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> Let FreeDOS users port a CL implementation on it (I'd start trying with
> clisp or ecl), and they'll be all set.

Oh, and Movitz too could be a good choice to run on FreeDOS. After all,
DOS and bare hardware have a lot in common.

[quiet_lad]

On Apr 22, 2:01 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

youv got to movitz movitz!!

[WJ]

kodifik wrote:

> There is this stack-oriented language called Factor.
> It has a quite good development environment.
> It has lots of libraries (even openGL).
> It is everything Forth should/could have been,
> but it is not meeting a great welcome either.
>
> From my ignorance, stack-orientation seems
> a too low-level thing to mess with.
> I mean: ideally, the compiler should take care of that.

Use of the stack can become too messy; if it is used
rationally it can be very helpful.

Factor:

Apply a closure ("quotation") to each element of a sequence.

{ 1 3 5 7 9 } [ pprint bl ] each
1 3 5 7 9

By using the stack, we can make "each" function as a
reduce or fold operator:

0 { 1 3 5 7 9 } [ + ] each .
25

[Doug Hoffman]

ANS Forth objects:

' . i{ 1 3 5 7 9 } map:
1 3 5 7 9 ok

0 ' + i{ 1 3 5 7 9 } map: .
25 ok

[Mark Wills]

> 25 ok- Hide quoted text -
>
> - Show quoted text -

Ooh! Eyegasm! I like it!

Have a +1 :-)

[Doug Hoffman]

> Ooh! Eyegasm! I like it!

Yes. These kinds of problems are pretty simple. I use objects because
I already have the scaffolding handy.

It should be pretty easy to do in Forth without objects:

1) build an array or list in the heap
2) write a function that applies any xt to each element
3) free the memory, garbage collection works well

I would expect that others have already done this.

-Doug

[WJ]

{ 1 3 5 7 9 } sum .
25

[WJ]

Instead of CL, tCL:

namespace path {::tcl::mathop ::tcl::mathfunc}

% + {*}{1 3 5 7 9}
25