forth vs common lisp

[quiet_lad]

cl claims to be the most powerful programming language in the world!!!
can forth outdo it?
www.paulgraham.com

[BruceMcF]

On Apr 14, 8:05 pm, quiet_lad <gavcom...@gmail.com> wrote:
> cl claims to be the most powerful programming language in the world!!!
> can forth outdo it?www.paulgraham.com

cl *itself* claims that?

Why, sure, Forth can outdo that ... those, OTOH, most any language
can:

: .Forth-Claim ( -- )
CR ." I am more powerful than the most powerful "
." programming language in the world ! !! !!!"
CR ;

Outdoing *claims* is easy. Its backing them up that's tricky.

[Mark Wills]

Well, for many many years I dismissed Forth as crap simply because I
couldn't read/understand it. I don't want to fall into the same trap
again (I know next to nothing about Lisp) but it sure looks like a
'write only' language to me right now.

[Fanzo]

maybe, anyway too much parenthesis

[jacko]

I agree. I designed ScriptLanguage to use RPN because of this. Sometimes [ ] are needed to surround a nested parse token or item, but literals "" delimited auto stack, and all tokens must be space delimited like forth. The brackets in lisp are due to the very simple parse rules, and the need to nest lists to appear as single symbols to the parser. It is possible to make a complex parser in lisp, and make it do a macro preprocessing of any input making the extensible language you need. But chicken and egg.

Cheers Jacko

[BruceMcF]

The "l" *is* an abbreviation for an acronym for "littered with
inherently silly parentheses" or some such ( lots of, intrinsically,
etc.). Take out the parentheses and you'd have to change the name.

Whereas FORTH stands for Find Obfuscated Reverse-polish Threading
Here.

[A. K.]

IIRC Apple once developed a language called Dylan that was basically a
Common Lisp without parentheses.

But obviously they trashed it for Objective-C.

[BruceMcF]

On Apr 15, 4:22 pm, "A. K." <a...@nospam.org> wrote:
> But obviously they trashed it for Objective-C.

I'll not say what I at one time maintained C stood for, since I no
longer use language like that very often. Indeed, since its been over
15 years since I've had to program in C, the animosity has cooled
substantially.

[lynx]

In <4f8afc4e$0$1381$4faf...@reader2.news.tin.it> Fanzo <crist...@gmail.com> writes:

>quiet_lad wrote:
>> cl claims to be the most powerful programming language in the world!!!
>> can forth outdo it?
>> www.paulgraham.com

"Most powerful?" For what? I found it a satisfying language to work
with. You might, too. Or you might not.

Most Lisp editors have built-in "paren matching," so the parenthesis
don't really pose an issue.

Like Forth, it is hardly a "write only" language in skilled hands.

It is, however, a very different proposition than Forth. Skip the
language war. Get a copy of Touretsky or Seibel and try it for
yourself!

http://www.cs.cmu.edu/~dst/LispBook/
http://www.gigamonkeys.com/book/

(Graham's books may be too hard to start out with.)

Clozure CL, SBCL, and CMUCL are excellent, mature, and freely available
CL implementations. Take your pick.

I happen to like both Forth and Common Lisp. I really like colorForth,
too. I will not compare these here. Each of them appeals to me
aesthetically for different reasons.

[jacko]

Get free42 and code :)

[Hugh Aguilar]

On Apr 14, 6:05 pm, quiet_lad <gavcom...@gmail.com> wrote:
> cl claims to be the most powerful programming language in the world!!!
> can forth outdo it?www.paulgraham.com

Any language that you write programs in is more powerful than any
language that you don't write programs in.

Gavino, you could write a program in GW-BASIC and that would make GW-
BASIC the most powerful language in the world --- as compared to not
writing programs in Lisp, Forth, etc..

I think that Lisp is a better language for desktop-computer
programming than Forth, but that Forth is better for micro-controller
programming than Lisp. I don't know Lisp very well though, so I use
Forth for desktop-computer programming. When I work as a computer
programmer, I use whatever language my employer uses --- that is the
"most powerful" language in the sense that it causes a paycheck to
appear every Friday. Right now I work as a cab-driver, so I just
program for fun --- any language that seems interesting and fun is the
"most powerful" within that context --- this changes from day to day.

Stop pestering everybody with these weird questions! What is the most
powerful language in the world? Could Forth be used to guide a
spaceship to Pluto? Do dogs smile? Who built the Giza pyramid complex?
What is the sound of one hand clapping? What brilliance would result
if Gavino were able to hold a thought in his head for more than 30
seconds?

[Zbiggy]

In comp.lang.forth, Hugh Aguilar wrote:

> I think that Lisp is a better language for desktop-computer
> programming than Forth,

...because?

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.

> but that Forth is better for micro-controller programming than Lisp.

This goes without saying.
--
Forth is a preserver of health (Hippocrates)

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

[Paul Rubin]

Zbiggy <zbigniew2...@gmail.REMOVE.com> writes:
> set b [doIt3 $a1 $b1 $c1]

> set c [doIt4 $x1 $y1 $z1] ...

> Using Lisp it can be even worse, it seems.

If you want to use temporaries in Lisp, it's perfectly fine to do so.

> Lisp seems to me (well, I may be wrong) a language for people more
> "purely theoretically" - and less technically - oriented.

If you're talking about CL, it's not like that at all, it was written by
hackers and has a lot of creature comforts. It's sort of like Perl or
C++ in that regard. It looks disorganized from the outside, but like a
workbench whose contents have evolved over time, whenever you reach for
a tool, it tends to be just where you put your hand. Scheme and Haskell
are both much more theoretically oriented than CL. CL lends itself to a
kitchen-sink approach to programming, as opposed to Forth's minimalistic
and highly focused approach. CL's runtime error checking (aka dynamic
typing), garbage collection, and convenient syntax for nested structures
make it (IMO) much easier to use for complicated programs. The cost of
this is much higher resource consumption and some unpredictability of
performance (such as GC pauses) that limit its suitability for small
computers and for realtime applications.

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

[Zbiggy]

In comp.lang.forth, Paul Rubin wrote:

> Zbiggy <zbigniew2...@gmail.REMOVE.com> writes:
>> set b [doIt3 $a1 $b1 $c1]
>> set c [doIt4 $x1 $y1 $z1] ...
>> Using Lisp it can be even worse, it seems.
>
> If you want to use temporaries in Lisp, it's perfectly fine to do so.

It's not I was talking about.

Correct me, if I'm wrong, but it seems to me, that the same code written
in Lisp would require more parentheses.

>> Lisp seems to me (well, I may be wrong) a language for people more
>> "purely theoretically" - and less technically - oriented.
>
> If you're talking about CL, it's not like that at all, it was written by
> hackers and has a lot of creature comforts. It's sort of like Perl or

> C++ in that regard. [..]

Now I know, that most probably I won't be fond of Lisp: while realizing,
that they are widely used, I dislike both C++ and Perl... ;)

> CL lends itself to a kitchen-sink approach to programming, as opposed
> to Forth's minimalistic and highly focused approach.

...and that's why I prefer TCL and Forth over Perl and C++. Well, we've got
plenty of programming languages at our disposal, and everyone can choose
his "better fit".

[Paul Rubin]

Zbiggy <zbigniew2...@gmail.REMOVE.com> writes:
> Correct me, if I'm wrong, but it seems to me, that the same code written
> in Lisp would require more parentheses.

The parentheses of Lisp are like the postfix of Forth. You get used to
them and it stops being a problem.

>> If you're talking about CL, ... It's sort of like Perl or C++

> Now I know, that most probably I won't be fond of Lisp: while realizing,

> that they are widely used, I dislike both C++ and Perl... ;) ...

> ...and that's why I prefer TCL and Forth over Perl and C++. Well, we've got
> plenty of programming languages at our disposal, and everyone can choose
> his "better fit".

Tcl is pretty dirty IMHO. You might like Python or Scheme.

[Zbiggy]

In comp.lang.forth, Paul Rubin wrote:

>> Correct me, if I'm wrong, but it seems to me, that the same code written
>> in Lisp would require more parentheses.
>
> The parentheses of Lisp are like the postfix of Forth.

No, they aren't; I read somewhere an interview with Chuck Moore, where he
stated, that he decided to get rid of "funny characters" to make the code
more readable.

Of course the code requiring less of such stuff is much more readable.

> You get used to them and it stops being a problem.

Not quite: it's one of the things "one can live with", but it'll always
remain cumbersome.

> Tcl is pretty dirty IMHO. You might like Python or Scheme.

Maybe one day I'll try...

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

[Zbiggy]

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.

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

[Ecki]

> >> Correct me, if I'm wrong, but it seems to me, that the same code
> >> written in Lisp would require more parentheses.
> >
> > The parentheses of Lisp are like the postfix of Forth.
>
> No, they aren't; I read somewhere an interview with Chuck Moore,
> where he stated, that he decided to get rid of "funny characters" to
> make the code more readable.
>
> Of course the code requiring less of such stuff is much more readable.

IMHO that would finally request compilers to understand pseudo-natural
language in the sense that (a) a somehow (well?) defined subset is used
and (b) some also well defined and widely accepted set of meta-language
(mathematical expressions, ...) is to be understood.

I fear, that would break all defining comittees, at least at the
point, where one wants chinese and the other arabic.

So I tend more to be of the opinion Paul expressed.

> > You get used to them and it stops being a problem.
>
> Not quite: it's one of the things "one can live with", but it'll
> always remain cumbersome.

As in natural language, for me a german dialect (east thuringian) is
best understandable (but common german best readable), while english is
in some aspects (technically oriented) better for me than, say,
hungarian, and e.g. turkish fully worthless. For some collegue, this is
best, and german is complicated... there's nothing "one can [only] live
with", but more "how one is thinking".

Back to programming: I'm doing some C for years, and some less Assembler
too. The other day I started learning C++, but understanding it took me
years. At some point I tried Prolog - it took me much effort to
(temporarily) forget much of what I thought programming is like. So my
personal conclusion is, that there's (nearly) no better or worse in
general, but only for given circumstances (means: each evaluation of
programming languages is a projection and so depends on the importance
one gives each component - not even explicitly, but also implicitly).

The problem seems to be more one of the target domain and its
complexity, and as such each programming language has to be evaluated
in how good (effectiveness, granularity, strength (elegance) of
expression, development and compile time effort and overhead, run time
footprint, and so on) it is in solving a given problem (look at
rosettacode at specific problem's solutions). So if a project arises,
problems usually (a) differ and (b) change, thus may the value of any
programming language choosen. That's the point, where "one [either has
to] live with" a choice taken under different circumstances or to
change.

> > Tcl is pretty dirty IMHO. You might like Python or Scheme.
>
> Maybe one day I'll try...

One even might like brainfuck - that's only a personal preference. Part
of what I'm payed for is Shell and AWK code, and there are good reasons
for that choice. :)

Just my 2 cents...

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

[John Passaniti]

On Apr 19, 5:11 am, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:

> Correct me, if I'm wrong, but it seems to me, that the same
> code written in Lisp would require more parentheses.

It never ceases to amaze me about how some programmers get so hung up
over syntax. Yes, in Lisp you are going to be typing more parenthesis
than in most other languages. But so what? In Forth, you may be
typing more whitespace to separate words than in languages where
whitespace is less significant. In Python, you may be hitting the
return and tab keys more because indentation is part of the structure
of the language. In most object-oriented languages you may be typing
period more often to address methods and properties of an object.

The parenthesis in Lisp aren't important. What is important is what
the parenthesis *mean*. In Lisp, parenthesis start and end a list.
And usually, the first item in a list is the operation for the rest of
that list. So say I write this:

(+ 1 2)

This is a list. When evaluated, it executes addition on the
arguments, producing the value 3. So knowing nothing more about Lisp
than that, what if I now show you this:

(+ 1 (+ 2 3))

Still confused? How about if I break it up:

(+ 1
(+ 2 3)
)

Either way, wow, lots of scary parenthesis there, huh?. But what did
I just tell you-- each is a list. So break each list down. We can
see that the outer list is adding 1 to the value returned by another
list. What is that list? Well that's another addition that gives the
value 5. So hopefully, you can see this bit of Lisp returns the value
6.

There is obviously more to Lisp than just that. Sometimes a list is
just data. Sometimes a list is a set of arguments to a function.
Sometimes it has another purpose. But it's all just lists, and once
you understand the handful of roles those lists play, you end up with
a language that has a much more simple and regular syntax than Forth.

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.

[Zbiggy]

In comp.lang.forth, John Passaniti wrote:

> It never ceases to amaze me about how some programmers get so hung up
> over syntax. Yes, in Lisp you are going to be typing more parenthesis
> than in most other languages. But so what?

But I addressed the question "so what" already; I gave even an example.
Didn't you read?

[Zbiggy]

In comp.lang.forth, Ron Aaron wrote:

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

It's a pity, actually, that Reva doesn't offer any interface to some GUI
toolkit: could be Tk, FLTK or Fox... full support for curses, for text mode,
also could be nice.

[Ron Aaron]

On 04/19/2012 09:55 PM, Zbiggy wrote:
> In comp.lang.forth, Ron Aaron wrote:
>
>> 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.
>
> It's a pity, actually, that Reva doesn't offer any interface to some GUI
> toolkit: could be Tk, FLTK or Fox... full support for curses, for text mode,
> also could be nice.

"IUP" is a GUI toolkit.

http://www.tecgraf.puc-rio.br/iup/

[Zbiggy]

There isn't any information about it on main page; there is only, in section
"Related projects":

"The Reva GUI. This is not being actively developed any more, but you may
find it interesting" - which suggests something abandoned.

Besides, on IUP's page, there is a remark: "IUP is a portable toolkit for
building graphical user interfaces. It offers APIs in three basic languages:
C, Lua and LED".

What about Reva?

[John Passaniti]

On Apr 19, 2:15 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:

> But I addressed the question "so what" already; I gave
> even an example. Didn't you read?

What I specifically responded to was your statement that Lisp has a
lot of parenthesis which is an observation about syntax, not about
semantics. What I showed you is that Lisp has a syntax with greater
simplicity and regularity than Forth.

Since you don't cite what specific comments you claim I didn't read,
I'll guess:

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

If that's what you were referring to, then what you need to understand
is that lists in Lisp aren't just artificial contrivance that
programmers are somehow forced to use. Lists are *fundamental* in
Lisp, they are how you consistently represent both data and programs.

> In Forth we're using memory locations almost like in
> machine code, and it's quite enough [...]

What exactly do you think a list is in Lisp? In Lisp, a list is
nothing but a chain cells in memory that contain pairs of a "first"
and "rest" pointer. It's directly related to what is going on in raw
memory. Take the example I gave before:

(+ 1 2)

In Lisps, this would be implemented something like this:

first--> +
rest-->
first--> 1
rest-->
first--> 2
rest--> end

And in fact, this is one of the reasons why Lisp is a simpler language
than Forth. It's called homoiconicity which is a fancy way of saying
that the external representation of Lisp matches the internal
representation. So when you see a Lisp program, it isn't some weird
abstract thing. It's exactly what you would see if you followed the
chain of first/rest pointers.

At some point, I'm sure you didn't understand the relationship between
Forth source code and how it related to memory and the interpretation
of that memory by the CPU. Lisp source code has an even more direct
relationship to memory and the interpretation of that memory by the
CPU.

[Zbiggy]

In comp.lang.forth, John Passaniti wrote:

>> But I addressed the question "so what" already; I gave
>> even an example. Didn't you read?

> Since you don't cite what specific comments you claim I didn't read,
> I'll guess:

Wrong guess.

I meant example, given in:
http://groups.google.com/group/comp.lang.forth/msg/f0ce845d2aae27a0

This is the answer for your "so what?".

> Lisp source code has an even more direct relationship to memory and the
> interpretation of that memory by the CPU.

Maybe, but - at the moment - I've got to believe you. Perhaps it has.

[Elizabeth D. Rather]

On 4/18/12 11:37 PM, Zbiggy wrote:
> In comp.lang.forth, Paul Rubin wrote:
>
>>> Correct me, if I'm wrong, but it seems to me, that the same code written
>>> in Lisp would require more parentheses.
>>
>> The parentheses of Lisp are like the postfix of Forth.
>
> No, they aren't; I read somewhere an interview with Chuck Moore, where he
> stated, that he decided to get rid of "funny characters" to make the code
> more readable.

Doesn't sound right, since he was quite comfortable using "funny
characters" in word names. I think Chuck reacted against the use of
parens, etc., in Fortran (which was the most universal HLL when he
developed Forth) to manage the order in which expressions were
evaluated. The result can be error-prone and hard to read. Much simpler
to just let the programmer have full control, and specify operations in
the desired order.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Ron Aaron]

On 04/19/2012 10:47 PM, Zbiggy wrote:

> There isn't any information about it on main page; there is only, in section
> "Related projects":

That is a different, "related" project -- which was abandoned precisely
because IUP is a better (in my opinion) solution for the cross-platform
GUI. Or more correctly, I couldn't summon up the energy to pursue it
once I realized that IUP would do what I wanted, very well.

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.

I don't know what's on the IUP project's page, since I have no
connection to them except to communicate occasionally with their
developers. IUP was developed for Lua by the Lua team, but it works
easily enough with Reva.

[Zbiggy]

In comp.lang.forth, Elizabeth D. Rather wrote:

>>>> Correct me, if I'm wrong, but it seems to me, that the same code written
>>>> in Lisp would require more parentheses.
>>>
>>> The parentheses of Lisp are like the postfix of Forth.
>>
>> No, they aren't; I read somewhere an interview with Chuck Moore, where he
>> stated, that he decided to get rid of "funny characters" to make the code
>> more readable.
>
> Doesn't sound right, since he was quite comfortable using "funny
> characters" in word names. I think Chuck reacted against the use of
> parens, etc., in Fortran

I won't find this interview instantly, but similar statement is present on
his "colorForth" pages ( http://www.colorforth.com/cf.htm ):

#v+
In Forth, a new word is defined by a preceeding colon, words inside a
definition are compiled, outside are executed. In colorForth a new word is
red, green words are compiled, yellow executed. This use of color further
reduces the syntax, or punctuation, needed.
#v-

Then he decided to make it even simpler in his colorForth.

[Zbiggy]

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

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

[Elizabeth D. Rather]

Ah, but there's a distinction between disliking "syntax" and disliking
"funny characters." In other words, it's a functional dislike, not an
aesthetic one.

[Zbiggy]

In comp.lang.forth, Elizabeth D. Rather wrote:

> Ah, but there's a distinction between disliking "syntax" and disliking
> "funny characters." In other words, it's a functional dislike, not an
> aesthetic one.

Yes, maybe I wasn't precise enough: he wrote, that the code, where the words
- and their parameters - are separated just by whitespaces, and not by any
of that "funny characters", is much more readable.

Of course, he was right; getting back to my TCL example, something like
this:

doIt7 doIt6 doIt5 doIt4 doIt3 doIt2 doIt1

...is shorter, and better readable than any of both previous versions. If
the word names weren't "serially generated", it could be quite clear, and
all this without any need for transitional variables.

[Rugxulo]

Hi,

On Apr 18, 11:49 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> On Apr 14, 6:05 pm, quiet_lad <gavcom...@gmail.com> wrote:
>
> > cl claims to be the most powerful programming language in the world!!!
> > can forth outdo it?www.paulgraham.com
>
> Any language that you write programs in is more powerful than any
> language that you don't write programs in.

In the very simplest stuff, yes, but a lot of the heavy abstractions
don't port very easily. It's truly difficult to write really really
portable and strictly conformant programs. I don't claim to be
anywhere near an expert, only very barely a lowly hacker, but not all
languages (libs, runtimes, OSes) are the same. It's a shame, too,
because it makes programs less useful when they don't transition well
(IMHO). I always get my hopes up and am almost always disappointed.

"Adapting old programs to fit new machines usually means adapting new
machines to behave like old ones." -- Alan Perlis

> Gavino, you could write a program in GW-BASIC and that would make GW-
> BASIC the most powerful language in the world --- as compared to not
> writing programs in Lisp, Forth, etc..

Keep in mind that the language syntax, strictly speaking, usually
doesn't do much without lots of libraries to interface to the OS and a
runtime. Sometimes this is easier on some OSes than others, and
obviously some language's pseudo-standard libraries are more robust
than others.

Jeff Vavasour wrote a simple Breakout (arcade) emulator in GW-BASIC.
And I know there's QBForth on forthfreak.net somewhere. And one guy's
(old) 186 emulator was written in FBC. But most of the trillions of
BASIC variants' code isn't very portable. The "standard"s for BASIC
are long gone and old (I think???). Doesn't mean nobody uses it, and
there are more popular and robust implementations, but it depends on
the end user, not the language, on how good / useful / powerful the
tool is.

Everyone seems to love Javascript even though most say it sucks, but
in the hands of Fabrice Bellard, you can have something really
interesting (JSLinux). It doesn't change the usefulness (or perceived
lack) in the language, just means the carpenter is more important than
the tools. Even the weakest OS (DOS?) can have powerful apps (Dillo w/
FLTK).

You have to really be motivated to bring an inferior language
implementation up to your level. It is almost like writing half of it
from scratch. You either make do with what you already have in order
to build more or you find a canned solution already. It just depends
on time, documentation, motivation, available hardware, etc. It's not
really easy to do.

I know this sounds kinda obvious and trite, I'm just saying ....

> Stop pestering everybody with these weird questions! What is the most
> powerful language in the world? Could Forth be used to guide a
> spaceship to Pluto? Do dogs smile? Who built the Giza pyramid complex?
> What is the sound of one hand clapping? What brilliance would result
> if Gavino were able to hold a thought in his head for more than 30
> seconds?

Heh, no offense to Gavino, but this was funny. ;-)

[John Passaniti]

On Apr 19, 4:12 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:

> This is the answer for your "so what?".

Then yes, I read it. No, I don't understand the point you're making.
You first have the weird notion that TCL is in some sense like Lisp.
Why exactly do you believe that? You then have the equally weird
notion that because a definition in TCL can be broken up into lines
and a Lisp expression can do the same, that there is some
relationship. Huh? You can break Forth up how ever you like as well
taking a more vertical style (good for documenting stack effects) or a
more horizontal style (good for short compact definitions). You can
do the exact same in Lisp.

Regardless, you're still talking about *syntax* which is
simultaneously the most obvious and the least interesting aspect of
Lisp, Forth, and for that matter most languages.

> > Lisp source code has an even more direct relationship to
> > memory and the interpretation of that memory by the CPU.
>
> Maybe, but - at the moment - I've got to believe you.
> Perhaps it has.

You don't have to believe me. Like Forth, you can pick up the basics
of Lisp in less than a day. It's not a difficult language to learn,
and you'll very quickly see that the relationship between Lisp source
code and what is going on internally is directly 1-to-1.

[Rugxulo]

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

[Zbiggy]

In comp.lang.forth, John Passaniti wrote:

> Then yes, I read it. No, I don't understand the point you're making.
> You first have the weird notion that TCL is in some sense like Lisp.
> Why exactly do you believe that?

It's not just me; the people with longer experience in using both languages
stated this:

#v+
[..] LISP and Tcl are at least superficially so similar that there is little
to give or take? Both languages treat program code like data, and build
strongly on lists (dynamic in length and types) as major data structure. In
LISP as in Tcl, a command is a list where the first element ("CAR") is the
command name and the others are its arguments. LISP's "property lists" are
a mapping from strings to lists, or what Tcl'ers know as an array.
#v-

http://wiki.tcl.tk/1318

> You then have the equally weird
> notion that because a definition in TCL can be broken up into lines
> and a Lisp expression can do the same, that there is some
> relationship. Huh? You can break Forth up how ever you like as well
> taking a more vertical style (good for documenting stack effects) or a
> more horizontal style (good for short compact definitions). You can
> do the exact same in Lisp.

Actually, I don't want to do this. And my example was kind of illustration,
that usually it's hard to keep TCL code clear and readable, when *not doing*
this.

And since on the same WWW page you'll find the statement:

"LISP is more consequent in enclosing each and every list in parens, so
you'll see much more of those in any LISP code".

...exactly because of this I wrote: "using Lisp it can be even worse". More
parentheses = more transitional variables needed to separate parts of code =
"worse situation", because the code is less readable (and I have more to
type).

Anyway, I'm not trying to state "Lisp sucks" - just wrote, that multitude of
"funny characters" required by the language - and no chance for implicit
arguments passing (no stack) - means inconvenience to me. I can live with
this - I'm writing TCL scripts anyway - but it is, and always will be, just
cumbersome. Still: TCL is more readable to me than e.g. Perl, and I like its
"substitution", since it's very useful, because it makes string processing
much easier.

Took a glance at several short Lisp listings - and it seems to me, that it's
designed for mathematicians. Actually, just before posting this, found at
wikipedia: "Lisp was originally created as a practical mathematical notation
for computer programs, influenced by the notation of Alonzo Church's lambda
calculus."

[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

[Paul Rubin]

Zbiggy <zbigniew2...@gmail.REMOVE.com> writes:
> Took a glance at several short Lisp listings - and it seems to me, that it's
> designed for mathematicians. Actually, just before posting this, found at
> wikipedia: "Lisp was originally created as a practical mathematical notation
> for computer programs, influenced by the notation of Alonzo Church's lambda
> calculus."

That was in the 1950's. CL is from the 1980's, the result of decades of
evolution and hacking, mostly on large (for the respective era)
computers. That means while Forth tries to be minimalistic for the sake
of small-machine resources and implementation simplicity, CL
implementations tend to have fancy development tools and powerful
compilers, and the language itself has lots of features and libraries
(again by the standards of the era).

I wouldn't put too much emphasis on Chuck's problem with the
parentheses, given that the alternative he presents is for programmers
to juggle a stack around in their heads.

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


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

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

[Nomen Nescio]

> Not writing anything in Lisp - but I'm using TCL, which has somewhat
> Lisp-like syntax

Tcl doesn't have a Lisp-like syntax. At all. Lisp uses prefix, Tcl uses
"normal" infix. Tcl isn't anything like Lisp. Probably the biggest proof is
I was productive with Tcl after an hour or two and after 3 decades of
thinking about learning Lisp and trying and giving up for various reasons I
still don't "get" Lisp.

[Zbiggy]

In comp.lang.forth, Nomen Nescio wrote:

>> Not writing anything in Lisp - but I'm using TCL, which has somewhat
>> Lisp-like syntax
>
> Tcl doesn't have a Lisp-like syntax. At all. Lisp uses prefix, Tcl uses
> "normal" infix.

In fact, TCL also uses prefix:

#v+
% namespace path ::tcl::mathop
% puts [+ 5 6]
11
#v-

[John Passaniti]

On Apr 19, 7:59 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:

> It's not just me; the people with longer experience in using
> both languages stated this:

So by the logic expressed in the link you provided, black and white
are similar because they are both colors, Democrats and Republicans
are similar because they are both political parties, Mexican and
Korean food are similar because because they both like seafood, and
Forth and COBOL are similar because both languages are procedural.
Excellent point. Here, have some tokens for a video game arcade.
They're similar to money, so you should be to buy yourself something
nice.

Saying that TCL and Lisp are similar in that both treat program code
like data and use lists is stunning in it's superficiality. But
"superficiality" was indeed a key word in the lead sentence of the
page you cite:

> #v+
>  [..] LISP and Tcl are at least superficially so similar that

> there is little to give or take? [...]

The link you cite is about kinda-sorta emulating some features of Lisp
in TCL. But those emulations are weak cousins to what Lisp offers and
suffer from a painful verbosity imposed by TCL.

> "LISP is more consequent in enclosing each and every list in
> parens, so you'll see much more of those in any LISP code".
>
> ...exactly because of this I wrote: "using Lisp it can be even
> worse". More parentheses = more transitional variables needed
> to separate parts of code = "worse situation", because the code
> is less readable (and I have more to type).

What you've just described by these "transitional variables needed" is
a consequence of weakly emulating aspects of Lisp in TCL. In Lisp,
there is no such problem. Honest. Take the time to do even the
smallest amount of research into Lisp and don't assume that just
because you see some painful examples of a Lisp style in TCL that Lisp
necessarily follows suit.

> Anyway, I'm not trying to state "Lisp sucks" - just wrote, that
> multitude of "funny characters" required by the language - and
> no chance for implicit arguments passing (no stack) - means
> inconvenience to me.

But that statement isn't based on Lisp. That statement is based (in
part) on a weak emulation of Lisp in TCL. The purpose of a stack in
Forth is to provide a *list* of unnamed values that Forth operators
can work on. Well gosh, look at this:

(reduce + 0 '(1 2 3 4))

This is Lisp, specifically Scheme. This program takes an initial
value (zero) and then applies the + operator to each value of the
list. The result is ten. You will note that there are no
"transitional variables" that are being used to either build up the
program or to pass arguments to +. You'll also notice that because
this is a list, it can be any length.

> I can live with this - I'm writing TCL scripts anyway -
> but it is, and always will be, just cumbersome.

So again, just so everyone here understands-- you can live with the
""transitional variables" that come not from Lisp, but from a Lisp
weakly emulated in TCL. Got it.

> Took a glance at several short Lisp listings - and it seems
> to me, that it's designed for mathematicians. Actually, just
> before posting this, found at wikipedia: "Lisp was originally
> created as a practical mathematical notation for computer
> programs, influenced by the notation of Alonzo Church's
> lambda calculus."

I'm not sure why this matters. Perl was originally designed for
report generation; it later became popular as a web programming
language and is now is popular in bioinformatics. JavaScript was
originally designed as a way to add interactivity to web pages; now
it's being used on the server side and to script embedded systems.
What a language may or may not be designed for says little about how
it may ultimately be used. As a functional programming language, the
Lisp family of languages is certainly centered around the application
of functions. But a "function" is not just a mathematical object.

[Nomen Nescio]

Zbiggy said:

> In fact, TCL also uses prefix:
>
> #v+
> % namespace path ::tcl::mathop
> % puts [+ 5 6]
> 11
> #v-

Yet that is not the idiomatic way to write Tcl. expr is used to compute the
value of an expression, doesn't require mathop, and more to the point is
readable by normal Tcl programmers:

% puts [expr 5 + 6]
11
%

If you posted your "way" to comp.lang.list they might appreciate it.

For extra credit since this is comp.lang.forth and everything is postfix,
let's see if you can write postfix in Tcl ;-) postfix is more useful than
either prefix or infix but then I prefer HP calculators and Forth.

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

[Zbiggy]

In comp.lang.forth, Nomen Nescio wrote:

>> In fact, TCL also uses prefix:
>>
>> #v+
>> % namespace path ::tcl::mathop
>> % puts [+ 5 6]
>> 11
>> #v-
>
> Yet that is not the idiomatic way to write Tcl. expr is used to compute the
> value of an expression, doesn't require mathop, and more to the point is
> readable by normal Tcl programmers:
>
> % puts [expr 5 + 6]
> 11
> %
>
> If you posted your "way" to comp.lang.list they might appreciate it.

It's not "my way", it is quite normal and obvious way - and (in)famous
[expr {}] is nothing more, than "convenience layer" for those
"infix-oriented", just like yourself.

If you're reading comp.lang.tcl, just ask them, is TCL prefix, or really
infix - if you still didn't notice, that TCL's syntax is:

command parameter_1 parameter_2 ... parameter_n

It the above isn't prefix for you, then nothing is prefix for you.

[Zbiggy]

In comp.lang.forth, John Passaniti wrote:

> Well gosh, look at this:
>
> (reduce + 0 '(1 2 3 4))
>
> This is Lisp, specifically Scheme. This program takes an initial
> value (zero) and then applies the + operator to each value of the
> list. The result is ten. You will note that there are no
> "transitional variables" that are being used to either build up the
> program or to pass arguments to +. You'll also notice that because
> this is a list, it can be any length.

Look at this then:

expr [join { 1 2 3 4 } +]

Here you see 2 interesting things:

1. That TCL can be more Lisp-like, than you think.
2. That giving such trivial, simplistic example proves nothing.

[Zbiggy]

In comp.lang.forth, Zbiggy wrote:

>> (reduce + 0 '(1 2 3 4))

> expr [join { 1 2 3 4 } +]

Oh, I forgot: even more "canonical" way would be:

namespace path ::tcl::mathop
+ 5 6 7 6 7 8

Here you are. No need for transitional variables, and - of course - the list
can be as long, as you wish. Just "+" at the beginning needed; that's all.

The problem is, that - you know - not everyone are using Lisps and TCLs
just for addition of list elements. Some are trying to create little more
complicated and useful things.

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

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

[John Passaniti]

On Apr 20, 3:57 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:

> Look at this then:
>
>   expr [join { 1 2 3 4 } +]
>
> Here you see 2 interesting things:
>
> 1. That TCL can be more Lisp-like, than you think.
> 2. That giving such trivial, simplistic example proves nothing.

You're wrong on both counts. Your trivial, simplistic example proves
you don't understand Lisp and at this point, it seems like something
beyond mere willful ignorance. You keep focusing entirely on syntax
without considering semantics and mechanism. You seem to think that
if you can make a language *look* like another language, than it is
somehow comparable. That's a trivial and superficial view.

Let's break down the TCL example you gave. You created a string out
of the members of a list with the string "+" between them. At this
point, you don't have anything that the system can evaluate, so you
have to pass it to eval which interprets it and returns the result.
So in your example, you took data from one form (a list), converted it
to another form (a string), evaluated the string, and got a result (a
number). Wow, could you find a more inefficient way to do the same
thing? How about instead using a language where programs and data
start as a list and stay as a list? Might be a bit more efficient,
huh?!

> Oh, I forgot: even more "canonical" way would be:
>
> namespace path ::tcl::mathop
> + 5 6 7 6 7 8

Sure, but that is now even farther from Lisp because the arguments to
+ aren't a list, and you're further limited to just the set of
operations in tcl::mathop. So using that same awesome technique,
apply it to an arbitrary function that accepts three arguments at a
time, with an arbitrary number of sets of such arguments.

> The problem is, that - you know - not everyone are using Lisps
> and TCLs just for addition of list elements. Some are trying
> to create little more complicated and useful things.

Yep, and that's where the biggest difference between TCL and Lisp
exists. The examples you've given of TCL are a dead end. Using
tcl::mathop to add a sequence of numbers is limited, and using expr/
join to wildly transform a list to a string to a value only works with
the standard math operators provided by TCL. In the real world,
you'll probably want to use more complicated and arbitrary functions
and build programs up from that. The simple examples I gave in Lisp
aren't much more than a sophisticated desk calculator, but as programs
get more complicated and interesting, you can build on those. And you
can do that because the list structure is fundamental, and when the
entire language is based on that, it lets you do far more
sophisticated things.

I'm surprised you don't realize this. You know that in Forth, the
consistency of using a stack as the fundamental mechanism to pass and
return values from words is what leads to a variety of useful
properties. It allows you to have unnamed values flow in and out, and
this offers more than syntactic brevity; it provides a point of
consistency across both the built-in words of a language and the words
that the user extends the system with; it lets you freely construct
words that take and return arbitrary numbers of arguments. The same
things are all equally true in Lisp, except that instead of a stack,
the list is the fundamental mechanism and everything--- both data and
programs-- are represented in them.

I'm bored. Most people by now in the conversation would have put
aside their preconceptions and would have been driven by intellectual
curiosity to dive into Lisp to understand what makes the language
special. You show no such curiosity. Everything you write on the
subject is consistently superficial, either focusing on syntax or a
very weak understanding of what a list it. TCL gives you something
called a "list" and so you boldly assume that a list in Lisp is the
same thing (and suffers from the same properties). And now your
latest excuse to not spend an hour or two learning about what you're
so eager to comment on is that the examples here are trivial. Yet
when you first started learning Forth, I'll bet you first used it as
an immediate calculator and your first programs were to do simple
mathematical transformations of data. Man, that's some powerful
ignorance there, and while it would be fun to explore why you don't
want to learn, I'll let the people who know you struggle with that
attribute of your personality.

Just promise me this: If at some point, circumstance compels you to
want to learn about Lisp and you'll probably dive into any of the Lisp
family of languages. When you do that, please come back to this
thread and review what you wrote. Thanks.

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

[jacko]

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

[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

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

[Nomen Nescio]

> In comp.lang.forth, Zbiggy wrote:
>
>> (reduce + 0 '(1 2 3 4))
>
> expr [join { 1 2 3 4 } +]
>
> Oh, I forgot: even more "canonical" way would be:
>
> namespace path ::tcl::mathop
> + 5 6 7 6 7 8

Having to reference external libs is hardly canonical. Does anybody really
write Tcl like that?

> Here you are. No need for transitional variables, and - of course - the
> list can be as long, as you wish. Just "+" at the beginning needed; that's
> all.

And now you will tell us Tcl is really the same as APL since Tcl really has
vector operations and the same syntax as APL.

[Zbiggy]

In comp.lang.forth, Nomen Nescio wrote:

>>> (reduce + 0 '(1 2 3 4))
>>
>> expr [join { 1 2 3 4 } +]
>>
>> Oh, I forgot: even more "canonical" way would be:
>>
>> namespace path ::tcl::mathop
>> + 5 6 7 6 7 8
>
> Having to reference external libs is hardly canonical. Does anybody really
> write Tcl like that?

"External libs"? The above is "referencing external libs" to you?

You're right, you've convinced me. I mean: your experience with TCL must
be indeed 2-3 hours long.


Perhaps you should start by reading something easier, e.g. Wikipedia?

http://en.wikipedia.org/wiki/Tcl

[..]
Features

Tcl's features include
* All operations are commands, including language structures. They are
written in prefix notation.
[..]

[Nomen Nescio]

> Perhaps you should start by reading something easier, e.g. Wikipedia?

That explains it. People who quote wikipedia need to rethink what "reliable
sources" means!

[jacko]

FreeDOS is a useful test boot OS.

[Zbiggy]

In comp.lang.forth, Nomen Nescio wrote:

Then show me your "reliable source", which stated, that TCL is "infix".

..."that explains it" - its s.c. "reliability" - to me! :)

[Zbiggy]

In comp.lang.forth, Nomen Nescio wrote:

>>> (reduce + 0 '(1 2 3 4))
>>
>> expr [join { 1 2 3 4 } +]
>>
>> Oh, I forgot: even more "canonical" way would be:
>>
>> namespace path ::tcl::mathop
>> + 5 6 7 6 7 8
>
> Having to reference external libs is hardly canonical. Does anybody really
> write Tcl like that?

http://www.tcl.tk/man/tcl/TclCmd/expr.htm

#v+
[..]
MATH FUNCTIONS

When the expression parser encounters a mathematical function such as
sin($x), it replaces it with a call to an ordinary Tcl function in the
tcl::mathfunc namespace. The processing of an expression such as:

expr {sin($x+$y)}

is the same in every way as the processing of:

expr {[tcl::mathfunc::sin [expr {$x+$y}]]}

which in turn is the same as the processing of:

tcl::mathfunc::sin [expr {$x+$y}]

The executor will search for tcl::mathfunc::sin using the usual rules for
resolving functions in namespaces. Either ::tcl::mathfunc::sin or
[namespace current]::tcl::mathfunc::sin will satisfy the request, and
others may as well (depending on the current namespace path setting).
[..]
#v-

Waiting for your statement, that TCL/Tk docs - which you most probably never
read - "aren't reliable enough".

[jacko]

> And now you will tell us Tcl is really the same as APL since Tcl really has
> vector operations and the same syntax as APL.

LOL.... :D

Surely you mean J, as any fool could show APL different, due to the stickers on the keyboard.

[quiet_lad]

On Apr 15, 1:29 pm, BruceMcF <agil...@netscape.net> wrote:
> On Apr 15, 4:22 pm, "A. K." <a...@nospam.org> wrote:
>
> > But obviously they trashed it for Objective-C.
>
> I'll not say what I at one time maintained C stood for, since I no
> longer use language like that very often. Indeed, since its been over
> 15 years since I've had to program in C, the animosity has cooled
> substantially.

lol

[quiet_lad]

On Apr 18, 9:49 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> On Apr 14, 6:05 pm, quiet_lad <gavcom...@gmail.com> wrote:
>
> > cl claims to be the most powerful programming language in the world!!!
> > can forth outdo it?www.paulgraham.com
>
> Any language that you write programs in is more powerful than any
> language that you don't write programs in.
>
> Gavino, you could write a program in GW-BASIC and that would make GW-
> BASIC the most powerful language in the world --- as compared to not
> writing programs in Lisp, Forth, etc..
>
> I think that Lisp is a better language for desktop-computer
> programming than Forth, but that Forth is better for micro-controller
> programming than Lisp. I don't know Lisp very well though, so I use
> Forth for desktop-computer programming. When I work as a computer
> programmer, I use whatever language my employer uses --- that is the
> "most powerful" language in the sense that it causes a paycheck to
> appear every Friday. Right now I work as a cab-driver, so I just
> program for fun --- any language that seems interesting and fun is the
> "most powerful" within that context --- this changes from day to day.
>
> Stop pestering everybody with these weird questions! What is the most
> powerful language in the world? Could Forth be used to guide a
> spaceship to Pluto? Do dogs smile? Who built the Giza pyramid complex?
> What is the sound of one hand clapping? What brilliance would result
> if Gavino were able to hold a thought in his head for more than 30
> seconds?

driving a cab when know programming? wtf

[quiet_lad]

you are sadly right, I suffer from paralysis of analysis, and fret
over lisp vs haskell vs smalltalk vs forth having the most power and
making me the most money... when I dont even study each one...I have
issues....I do enjoy when I write a program and it works though, that
is awesome! I use mostly bash and tcl so far since they help so much
with unix management.... so much faulty software at work barf

[quiet_lad]

On Apr 18, 11:34 am, 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?
>
> 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.

>
> > but that Forth is better for micro-controller programming than Lisp.
>

> This goes without saying.

> --
> Forth is a preserver of health (Hippocrates)

I use tcl more n more in unix work. Amazing lil language.

[Ron Aaron]

On 05/22/2012 12:31 PM, quiet_lad wrote:

> you are sadly right, I suffer from paralysis of analysis, and fret
> over lisp vs haskell vs smalltalk vs forth having the most power and
> making me the most money... when I dont even study each one...

The language you use, is far more powerful (for you) than the one you
don't. Use something and worry about "power" later.

[quiet_lad]

fair enuf, for me tcl taking over from bash

[quiet_lad]

amen to that, wikipedia is massively communist, and every democrats
fact checker, lol, slaughter all democrats

[Alex McDonald]

Another post that demonstrates why people have justification in
thinking you a fool.

[quiet_lad]

funny because you sound like a fool :)

[quiet_lad]

On Jun 3, 6:21 pm, Alex McDonald <b...@rivadpm.com> wrote:

Well I am an objectivist but am not very pro israel and I do think
polytheism is the way to go religion wise. I admire Henry George who
said tax rent only and I am trying to integrate that with lazzie faire
ideas from objectivism.

[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