Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #11299 > unrolled thread

forth vs common lisp

Back to article view | Back to comp.lang.forth

Contents

  forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-04-14 17:05 -0700
    Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-14 17:10 -0700
      Re: forth vs common lisp Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-15 08:49 -0700
        Re: forth vs common lisp jacko <jackokring@gmail.com> - 2012-04-15 10:02 -0700
    Re: forth vs common lisp Fanzo <cristianof6@gmail.com> - 2012-04-15 17:47 +0200
      Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-15 11:20 -0700
        Re: forth vs common lisp "A. K." <akk@nospam.org> - 2012-04-15 22:22 +0200
          Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-15 13:29 -0700
            Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-04-24 09:33 -0700
      Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-15 23:44 +0000
    Re: forth vs common lisp jacko <jackokring@gmail.com> - 2012-04-15 17:41 -0700
    Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-18 09:49 -0700
      Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-18 19:34 +0100
        Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-18 18:50 -0700
          Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-19 04:08 +0200
            Re: forth vs common lisp Ron Aaron <rambamist@gmail.com> - 2012-04-19 06:25 +0300
              Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 19:55 +0100
                Re: forth vs common lisp Ron Aaron <rambamist@gmail.com> - 2012-04-19 21:39 +0300
                  Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 20:47 +0100
                    Re: forth vs common lisp Ron Aaron <rambamist@gmail.com> - 2012-04-19 22:37 +0300
                      Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 21:59 +0100
            Re: forth vs common lisp Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2012-04-19 09:28 +0200
            Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-19 01:03 -0700
          Re: forth vs common lisp kodifik <kodifik@eurogaran.com> - 2012-04-19 02:05 -0700
            Re: forth vs common lisp Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-19 04:29 -0500
              Re: forth vs common lisp Tamas Papp <tkpapp@gmail.com> - 2012-04-19 10:15 +0000
                Re: forth vs common lisp Paul Rubin <no.email@nospam.invalid> - 2012-04-19 08:45 -0700
            Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-19 14:15 -0700
              Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-19 16:06 -0700
                Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-20 05:24 +0200
                  Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-20 04:17 +0000
                    Re: forth vs common lisp Don Geddis <don@geddis.org> - 2012-04-20 08:34 -0700
                      Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-20 16:54 +0000
                        Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-20 17:03 +0000
                        Re: forth vs common lisp Don Geddis <don@geddis.org> - 2012-04-20 16:57 -0700
                          Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 13:06 +0100
                  Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-20 13:20 -0700
                    Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-20 23:14 +0200
                      Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 11:04 -0700
                        Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 22:12 +0100
                          Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 15:19 -0700
                            Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-22 01:01 +0100
                              Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 18:35 -0700
                                Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-22 03:13 +0100
                              Re: FreeDOS CL "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-22 10:58 +0200
                                Re: FreeDOS CL "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-22 11:01 +0200
                                  Re: FreeDOS CL quiet_lad <gavcomedy@gmail.com> - 2012-06-06 16:01 -0700
                            Re: forth vs common lisp jacko <jackokring@gmail.com> - 2012-04-22 06:18 -0700
                          Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-22 03:43 +0000
                    Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 13:02 +0100
                    Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-21 16:29 +0000
                Re: forth vs common lisp jacko <jackokring@gmail.com> - 2012-04-21 14:38 -0700
          Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 11:17 +0100
          Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-19 15:39 -0700
        Re: forth vs common lisp Paul Rubin <no.email@nospam.invalid> - 2012-04-18 22:17 -0700
          Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 10:11 +0100
            Re: forth vs common lisp Paul Rubin <no.email@nospam.invalid> - 2012-04-19 01:28 -0700
              Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 10:37 +0100
                Re: forth vs common lisp Ecki <ecki@intershop.de> - 2012-04-19 12:12 +0200
                Re: forth vs common lisp "Elizabeth D. Rather" <erather@forth.com> - 2012-04-19 09:35 -1000
                  Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 21:56 +0100
                    Re: forth vs common lisp "Elizabeth D. Rather" <erather@forth.com> - 2012-04-19 11:25 -1000
                      Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 00:00 +0100
            Re: forth vs common lisp John Passaniti <john.passaniti@gmail.com> - 2012-04-19 09:49 -0700
              Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 19:15 +0100
                Re: forth vs common lisp John Passaniti <john.passaniti@gmail.com> - 2012-04-19 12:01 -0700
                  Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-19 21:12 +0100
                    Re: forth vs common lisp John Passaniti <john.passaniti@gmail.com> - 2012-04-19 15:25 -0700
                      Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 00:59 +0100
                        Re: forth vs common lisp Paul Rubin <no.email@nospam.invalid> - 2012-04-19 18:49 -0700
                        Re: forth vs common lisp John Passaniti <john.passaniti@gmail.com> - 2012-04-20 07:14 -0700
                          Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 20:57 +0100
                            Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 21:21 +0100
                              Re: forth vs common lisp Nomen Nescio <nobody@dizum.com> - 2012-04-22 12:21 +0200
                                Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-22 12:27 +0100
                                  Re: forth vs common lisp Nomen Nescio <nobody@dizum.com> - 2012-04-22 14:59 +0200
                                    Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-22 15:25 +0100
                                    Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-06-03 15:09 -0700
                                      Re: forth vs common lisp Alex McDonald <blog@rivadpm.com> - 2012-06-03 18:21 -0700
                                        Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-06-03 18:58 -0700
                                        Re: forth vs common lisp and the abstraction claims of haskell and lisp quiet_lad <gavcomedy@gmail.com> - 2012-06-06 16:01 -0700
                                Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-22 15:38 +0100
                                Re: forth vs common lisp jacko <jackokring@gmail.com> - 2012-04-22 06:23 -0700
                            Re: forth vs common lisp John Passaniti <john.passaniti@gmail.com> - 2012-04-21 13:30 -0700
              Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-21 18:12 -0700
        Re: forth vs common lisp Nomen Nescio <nobody@dizum.com> - 2012-04-20 11:55 +0200
          Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 12:14 +0100
            Re: forth vs common lisp Nomen Nescio <nobody@dizum.com> - 2012-04-20 16:56 +0200
              Re: forth vs common lisp Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-20 19:52 +0100
        Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-05-22 02:34 -0700
      Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-19 15:10 -0700
      Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-04-24 09:58 -0700
      Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-05-22 02:31 -0700
        Re: forth vs common lisp Ron Aaron <rambamist@gmail.com> - 2012-05-22 12:55 +0300
          Re: forth vs common lisp quiet_lad <gavcomedy@gmail.com> - 2012-05-28 15:19 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#11434

In comp.lang.forth, Ron Aaron wrote:

> I suppose you are right that there is no mention of IUP on the main
> page; however there is an abundance of code examples in the package if
> you download it.

Aaaaaa... indeed. Maybe it's time to give Reva a shot. ;)
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11389

In article <87d374jwx0.fsf@kuiper.lan.informatimago.com>,
 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> Hugh Aguilar <hughaguilar96@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

[toc] | [prev] | [next] | [standalone]

#11390

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.

[toc] | [prev] | [next] | [standalone]

#11395

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.

[toc] | [prev] | [next] | [standalone]

#11397

In comp.lang.forth kodifik <kodifik@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 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.

[toc] | [prev] | [next] | [standalone]

#11399

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

> In comp.lang.forth kodifik <kodifik@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

[toc] | [prev] | [next] | [standalone]

#11408

Tamas Papp <tkpapp@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.

[toc] | [prev] | [next] | [standalone]

#11439

On Apr 19, 3:05 am, kodifik <kodi...@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.

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.

[toc] | [prev] | [next] | [standalone]

#11449

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

[toc] | [prev] | [next] | [standalone]

#11456

Rugxulo <rugxulo@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.


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

[toc] | [prev] | [next] | [standalone]

#11457

In <87r4vjhypv.fsf@kuiper.lan.informatimago.com> "Pascal J. Bourguignon" <pjb@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. 

[toc] | [prev] | [next] | [standalone]

#11476

lynx <rinkasu@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/               don@geddis.org

[toc] | [prev] | [next] | [standalone]

#11478

In <87lilqe7su.fsf@mail.geddis.org> Don Geddis <don@geddis.org> writes:

>lynx <rinkasu@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."

[toc] | [prev] | [next] | [standalone]

#11479

On 2012-04-20, lynx <rinkasu@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?

[toc] | [prev] | [next] | [standalone]

#11494

lynx <rinkasu@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/               don@geddis.org
Artificial Intelligence is the study of how to make real computers act like the
ones in movies.

[toc] | [prev] | [next] | [standalone]

#11498

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).

[toc] | [prev] | [next] | [standalone]

#11484

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.

[toc] | [prev] | [next] | [standalone]

#11486

Rugxulo <rugxulo@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.

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

[toc] | [prev] | [next] | [standalone]

#11502

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?

[toc] | [prev] | [next] | [standalone]

#11504

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web