From: Cyber Surfer
Subject: Re: C++ vs. any Lisp on a 386/Windows/on top of OS2 -- recommendations?
Date: 
Message-ID: <CnD0AL.1K6@cix.compulink.co.uk>
In article <··········@tove.cs.umd.edu>,
····@cs.umd.edu (John R. Bane) writes:
 
> Bad news: Runtime generator works by removing EVAL and COMPILE (system has no
> interpreter - everything is compiled), so delivered applications lose some

Isn't that what you'd expect? EVAL is supposed to be "bad style",
and if you want COMPILE, that's going to add a _lot_ of overhead
to an app. Most MS Windows users wion't thank you for that.

> flexibility.  MS Windows interface isn't CLIM, and can be fragile; landing in
> the debugger under a window callback can easily hose your Windows
> environment, requiring a reboot.

It's the same with any deveopment system for MS Windows. The answer
is use NT, if you can afford it, or perhaps OS/2. If you _must_ use
MS Windows, you should expect it to be fragile. That's part of the
baggage you get with a platform that used to include a "real mode",
a memory mode with no memory protection at all. It still runs every
app in the same address space! NT and OS/2 at least use the "protected
mode" available with the 386/486/Pentium CPUs.

MS Windows no longer supports the 286, as it no langer has a real mode.

> Quirks: Development environment has Windows look-and-feel; no Emacs.

That's a feature, surely? If you want a non-Windows look and feel,
use something else. A Windows development system will usually be
aimed at Windows developers, and they _usually_ want software that
looks and feels like other software for that platform.

When software behaves differently, they complain. I've read many
reviews of cross-development tools where the reviews lists non-Windows
behaviour as a negative point.

Martin Rodgers

--- Cyber Surfing on CIX ---

From: Simon E Spero
Subject: Re: C++ vs. any Lisp on a 386/Windows/on top of OS2 -- recommendations?
Date: 
Message-ID: <2n72lc$nl7@bigblue.oit.unc.edu>
In article <··········@cix.compulink.co.uk>,
Cyber Surfer <············@cix.compulink.co.uk> wrote:
>In article <··········@tove.cs.umd.edu>,
>····@cs.umd.edu (John R. Bane) writes:
>
>Isn't that what you'd expect? EVAL is supposed to be "bad style",

Eval is only bad style if you succumb to the dark side. In an extensible
applications, it's a big win, as the app can then be extended. 
From: Cyber Surfer
Subject: Re: C++ vs. any Lisp on a 386/Windows/on top of OS2 -- recommendations?
Date: 
Message-ID: <CnGq3C.313@cix.compulink.co.uk>
In article <··········@bigblue.oit.unc.edu>,
···@tipper.oit.unc.edu (Simon E Spero) writes:

> >Isn't that what you'd expect? EVAL is supposed to be "bad style",
> 
> Eval is only bad style if you succumb to the dark side. In an extensible
> applications, it's a big win, as the app can then be extended. 

True, but most extensible applications I know and use do it by
embedding a custom language designed specifically for the app.
I've only seen one app (AutoCAD) in use that used Lisp as the
embedded language, and AFAIK it wasn't written in Lisp itself.

Anyway, I'm not convinced that EVAL would be seen as a feature
by the developers of the apps I know or know of, and the languages
they're written in don't have anything like EVAL. It's handy in
Lisp, but also costly when you want a stand-alone program. You
have to decide if your users will accept that cost.

I can't comment on apps that are written in Lisp. I suspect
that the users of such apps are rather different to the users
of apps that use languages like VB as the embedded language. :-)

Martin Rodgers

--- Cyber Surfing on CIX ---
From: Cyber Surfer
Subject: Re: CLISP
Date: 
Message-ID: <CnGq3E.31p@cix.compulink.co.uk>
In article <··········@bigblue.oit.unc.edu>,
···@tipper.oit.unc.edu (Simon E Spero) writes:

> The answer was no.  If it runs in a DOS shell under Windows, it's
> a DOS program, not a Windows program.  That's how I see it.
> 
> However... I am embarrased to say that I've looked at the DJGPP
> readme file more closely, and now I'm not sure whether "No" was
> actually the correct answer.
> 
> DJGPP can be gotten from omnigate.clarkson.edu in
> /ftp/pub/msdos/djgpp.  Maybe you can decide for yourself based on
> the README and new features files.

Thanks. Sorry about any misunderstanding, but I've asked about
this in a number of places, and received some rather unhelpful
suggestions, and vague information. It amay have confused me
more than a little!

I'll take a look at omnigate.clarkson.edu:/ftp/pub/msdos/djgpp
as soon as I can. Thanks again.

Martin Rodgers

--- Cyber Surfing on CIX ---