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

Groups > comp.lang.lisp > #9632 > unrolled thread

Re: forth vs common lisp

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-18 18:50 -0700
    Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-19 04:08 +0200
      Re: forth vs common lisp Ron Aaron <rambamist@gmail.com> - 2012-04-19 06:25 +0300
      Re: forth vs common lisp Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2012-04-19 09:28 +0200
      Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-19 01:03 -0700
        Re: forth vs common lisp namekuseijin <namekuseijin@gmail.com> - 2012-04-19 12:10 -0700
          Re: forth vs common lisp Isaac Gouy <igouy2@yahoo.com> - 2012-04-20 08:53 -0700
    Re: forth vs common lisp kodifik <kodifik@eurogaran.com> - 2012-04-19 02:05 -0700
      Re: forth vs common lisp Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-19 04:29 -0500
        Re: forth vs common lisp Tamas Papp <tkpapp@gmail.com> - 2012-04-19 10:15 +0000
          Re: forth vs common lisp Paul Rubin <no.email@nospam.invalid> - 2012-04-19 08:45 -0700
            Re: forth vs common lisp Marco Antoniotti <marcoxa@gmail.com> - 2012-04-20 04:34 -0700
      Re: forth vs common lisp namekuseijin <namekuseijin@gmail.com> - 2012-04-19 11:53 -0700
      Re: forth vs common lisp Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-19 14:15 -0700
        Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-19 16:06 -0700
          Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-20 05:24 +0200
            Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-20 04:17 +0000
              Re: forth vs common lisp Don Geddis <don@geddis.org> - 2012-04-20 08:34 -0700
                Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-20 16:54 +0000
                  Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-20 17:03 +0000
                    Re: forth vs common lisp lynx <rinkasu@kaze.void.null> - 2012-04-20 17:56 +0000
                  Re: forth vs common lisp Don Geddis <don@geddis.org> - 2012-04-20 16:57 -0700
                    Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 13:06 +0100
                  Re: forth vs common lisp Rupert Swarbrick <rswarbrick@gmail.com> - 2012-04-20 21:12 +0100
            Re: forth vs common lisp Rugxulo <rugxulo@gmail.com> - 2012-04-20 13:20 -0700
              Re: forth vs common lisp "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-20 23:14 +0200
                Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 11:04 -0700
                  Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 22:12 +0100
                    Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 15:19 -0700
                      Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-22 01:01 +0100
                        Re: forth vs common lisp BruceMcF <agila61@netscape.net> - 2012-04-21 18:35 -0700
                          Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-22 03:13 +0100
                        Re: FreeDOS CL "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-22 10:58 +0200
                          Re: FreeDOS CL "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-04-22 11:01 +0200
                            Re: FreeDOS CL quiet_lad <gavcomedy@gmail.com> - 2012-06-06 16:01 -0700
                    Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-22 03:43 +0000
              Re: forth vs common lisp Tim Bradshaw <tfb@tfeb.org> - 2012-04-21 13:02 +0100
              Re: forth vs common lisp Kaz Kylheku <kaz@kylheku.com> - 2012-04-21 16:29 +0000

Page 2 of 2 — ← Prev page 1 [2]

#9654

In <20120420095157.3@kylheku.com> Kaz Kylheku <kaz@kylheku.com> writes:

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

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

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

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

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

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

#9659

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

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

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

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

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

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

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

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

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

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               don@geddis.org
Artificial Intelligence is the study of how to make real computers act like the
ones in movies.

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

#9662

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

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

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

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

#9663

[Multipart message — attachments visible in raw view] — view raw

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

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

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

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

Rupert

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

#9655

Hi,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#9657

Rugxulo <rugxulo@gmail.com> writes:

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

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


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

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


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

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

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

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

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


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

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



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

It's a design purpose of Common Lisp.

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


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

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


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

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


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

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

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

#9665

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

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

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

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

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

#9668

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

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

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

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

#9670

On Apr 21, 5:12 pm, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2012-04-21 18:04:28 +0000, BruceMcF said:
> > You mean, in the sense that X86 PC/104 microcontrollers ship with some
> > other form of Embedded DOS rather than FreeDOS?

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

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

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

#9671

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

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

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

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

#9673

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

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

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

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

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

#9674

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

> Like, unless its got a keyboard and a screen attached, or otherwise in
> a room full of racks connected to the internet, its not a device that
> requires programming?
Yes
> 
> Even a quick peak outside the window in the form of a quick google for
> industrial SBC's would suggest that is an excessively narrow view of
> the world.
Exactly my point

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

#9680 — Re: FreeDOS CL

Tim Bradshaw <tfb@tfeb.org> writes:

> On 2012-04-21 22:19:34 +0000, BruceMcF said:
>
>> based on a
>> misconception that DOS itself was "not in use"?
>
> Well, it meets the "not used on anything you'd think of as a computer"
> criteria, I think (at least if qualified by "in bits of the world I
> care about", where "I" is the person who I think might think this, not
> me).

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

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


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

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

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

#9681 — Re: FreeDOS CL

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

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

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

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

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

#10426 — Re: FreeDOS CL

On Apr 22, 2:01 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>
> > Let FreeDOS users port a CL implementation on it (I'd start trying with
> > clisp or ecl), and they'll be all set.
>
> Oh, and Movitz too could be a good choice to run on FreeDOS.  After all,
> DOS and bare hardware have a lot in common.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.

youv got to movitz movitz!!

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

#9677

On 2012-04-21, Tim Bradshaw <tfb@tfeb.org> wrote:
> On 2012-04-21 18:04:28 +0000, BruceMcF said:
>
>> You mean, in the sense that X86 PC/104 microcontrollers ship with some
>> other form of Embedded DOS rather than FreeDOS?
>
> I have no idea whether FreeDOS is used but it certainly is pretty 
> dangerous to assume that because something does not get used on 
> anything we think of as "a computer" its unused.  In the same way it's 
> a mistake to think most of the DNA inside you is yours.

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

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

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

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

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

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

#9661

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

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

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

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

#9664

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

DOS Lunatic. *plonk*

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web