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 "WJ" <w_a_x_man@yahoo.com> - 2013-03-08 10:01 +0000
              Re: forth vs common lisp Doug Hoffman <glidedog@gmail.com> - 2013-03-08 06:22 -0500
                Re: forth vs common lisp Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-08 03:36 -0800
                  Re: forth vs common lisp Doug Hoffman <glidedog@gmail.com> - 2013-03-08 07:02 -0500
              Re: forth vs common lisp "WJ" <w_a_x_man@yahoo.com> - 2013-04-02 09:34 +0000
              Re: forth vs common lisp "WJ" <w_a_x_man@yahoo.com> - 2013-04-08 23:26 +0000
          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 "WJ" <w_a_x_man@yahoo.com> - 2013-04-05 18:59 +0000
                            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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#11506

On Apr 21, 5:12 pm, Tim Bradshaw <t...@tfeb.org> wrote:
> 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.

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.

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

#11510

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

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

#11514

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.

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

#11515

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

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

#11519 — Re: FreeDOS CL

Tim Bradshaw <tfb@tfeb.org> writes:

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

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 Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

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

#11520 — Re: FreeDOS CL

"Pascal J. Bourguignon" <pjb@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.

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

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

#12746 — Re: FreeDOS CL

On Apr 22, 2:01 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> "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.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.

youv got to movitz movitz!!

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

#11527

FreeDOS is a useful test boot OS.

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

#11516

On 2012-04-21, Tim Bradshaw <tfb@tfeb.org> wrote:
> 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.

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.

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

#11497

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.

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

#11501

On 2012-04-20, Rugxulo <rugxulo@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*

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

#11505

You have given me some interesting connections for android scripting. Thanks.

It makes me wonder if the input/output of ScriptLanguage should be implemented as a socket server delivering HTTP responses. Image MIME also maybe. Adding an open URL command too. This would allow connection connection to the JSON SL4A socket to display native controls, and to run scripts in any SL4A interpreter. It could also deliver AJAX/JSON returns to a JavaScript UI.

For non android platforms, an applet embed with a server could do much of the same, except not call other language interpretors. A nice interface to google app engine persistent store could make some powerful apps.

Compiled against the right libraries with try/catch new creations could build a single jar basis of both methods. I wonder if my project will change some.

Cheers Jacko

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

#20430

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

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

#20435

On 3/8/13 5:01 AM, WJ wrote:
> 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
>

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

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

#20437

On Mar 8, 11:22 am, Doug Hoffman <glide...@gmail.com> wrote:
> On 3/8/13 5:01 AM, WJ wrote:
>
>
>
>
>
> > 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
>
> 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- Hide quoted text -
>
> - Show quoted text -

Ooh! Eyegasm! I like it!

Have a +1 :-)

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

#20438

On 3/8/13 6:36 AM, Mark Wills wrote:
> On Mar 8, 11:22 am, Doug Hoffman <glide...@gmail.com> wrote:

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

> 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

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

#21305

WJ wrote:

> 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

{ 1 3 5 7 9 } sum .
25

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

#21526

WJ wrote:

> 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

Instead of CL, tCL:

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

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

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

#11396

In comp.lang.forth, Hugh Aguilar wrote:

>> 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,

Without the code example it's difficult to say, whether one really disposed
of "stack juggling" - or just moved the problem to different part of code.

> and likely in Lisp too.

I thought, in Lisp stack isn't available directly, like in Forth?

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

Although surely you've got much more experience in Forth-programming, I'm not
quite sure, is your approach quite proper.

Yes, there are situations, when we need *exactly* list (or whatever) as data
structure, but most of the time, when creating a program, we just need "to
do something" (whatever it can be). And IMHO the better way would be to
discover, how that "something" can be done using the facilities offered by
chosen language, instead of insisting "it must be a record" (struct, list,
whatever).

In Forth we're using memory locations almost like in machine code, and it's
quite enough - as long, as one is able to calculate proper address to get
the needed data. Are such calculations superfluous in other languages? No,
they are just "hidden" (not made directly by programmer) - and most probably
there are many more, than in case of Forth.
-- 
Forth is a preserver of health (Hippocrates)

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

#11446

Hi,

On Apr 18, 8:50 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> 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.

You use what already exists unless you have different requirements or
taste, then you have to do it yourself, most likely. So usually canned
solutions are accepted, if possible, as easier to use. And it all
depends on both who is doing the work (and his/her skills) as well as
the project requirements. The fact that "most" commonly available (?)
Forth systems don't suit your specific needs doesn't mean Forth can't
be used, but it may just mean less people use (or need) it
specifically. Obviously more work goes into the C/C++ camps for
whatever reason.

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

Keep in mind that "Lisp" isn't one language, and there are several
"standard"s out there, not to mention implementations for (usually
popular) OSes. So what you find will vary quite greatly (educated
guess).

> Both Forth and Lisp are extensible, so these are the
> only two languages that I would consider for a large project.

"Most" others would probably suggest Java or C++. It's just a
preference, not a hard requirement.

> Nobody wants to hire me (or any Forther) to write a large program
> though, so we will never know how well Forth would work.

A lot of people in this group seem to have lots of experience, esp. in
business and big apps, so I doubt it's totally impossible. I'm sure
there are plenty of examples, I just don't know offhand. My naivety
doesn't negate the truth.   ;-)

Besides, don't you remember Brodie's CD from a few months ago?
Seriously, Hugh, you obviously have a lot of ideas and experience and
passion for Forth. If you can come up with a good idea and are willing
to work on it, put up some design docs, start the implementation, and
get listed on Kickstarter (or whatever). Don't get your hopes too
high, but who knows .... It's certainly no worse than not trying at
all.

> Forth failed, not because Forth is a bad language, but rather because
> of a lack of leadership.

Who would do it? They were all busy writing books or real code or
implementing their own systems. They don't have time to do it all. As
you can see, most heavy lifting is done by a very few people. The same
is probably true about any language.

I'll admit that certain languages seem to disappear without a
perceived leader (BDFL ?), but that doesn't mean they're "dead". It's
no more dead than an OS or implementation, it still exists and runs
and works. Popularity is for various silly reasons, usually not for
true merit but just lack of time and volunteers. "If it works, use
it." It doesn't matter how old or kludgy.   ;-)

> Nobody was writing libraries of useful code.

How would you know if they were, search Taygeta? SourceForge? Berlios?
Or would it just be propagated through the various Forth
implementations?

> Nobody was serious about supporting application programming ---
> everybody was dinking around with science-fair projects involving
> compiler-writing that had no practical value

Then why write StraightForth? Seriously, though, I get your point, but
not everybody is trying to be a professional Forth system, and not
everybody worries about utilizing every little end-user feature that
could possibly exist in a modern OS. It's really too much work for too
few people. Just standardizing on anything, however "minimal" you may
or may not think it is, is indeed worthwhile progress (though
thankless and grueling). All the extras can come later once you have a
good foundation.

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

Forth didn't die in 1994, but the world was a far different place
then. MS-DOS was last updated (and soon deprecated), NT was just
getting off the ground, Win95 was still in the works, and 64-bit Alpha
was still new. That may have also been when Mac switched to PPC. So a
lot of stuff was transitioning, esp. to 32-bit GUIs. I know you wish
Forth had better libraries, but that's not Forth's fault but the (lack
of) people implementing it. C++ doesn't have a standard GUI either. If
you want a de facto semi-portable GUI for a language, you may have to
jump to Java.

Standards are not exactly well-reviewed, it seems. Or at least those
who have some minor interest never know whom to contact or only into
the scene later on. It's hard to get and respect everyone's opinion.
You can't ever please everyone. And some people hate certain
standards, and they're not "wrong", just have a different perception
of everything. (Why else would we have thousands of languages??)

What can you do? Change the standard? Update it? Invent your own?
That's about all, you can only control yourself. "If it lacks
something, extend it. But if it works well, there's no reason to throw
away any of what's there." -- (TP55 OOP guide) -- And keep in mind
that TP/BP/Delphi never followed the "standard"s of Pascal!

Just write your own and publish it as an alternative. I guess that's
what you're already doing. That's your right, and that's the only real
way to prove your point. Actually implementing changes gives you much
more credibility (for good or bad) than just opinions (which is why no
one listens to me, heheh).

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

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

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

csiph-web