Theory #51 (superior(?) programming languages)

25 views
Skip to first unread message

Cyber Surfer

unread,
Jan 29, 1997, 3:00:00 AM1/29/97
to

In article <5clrnr$g...@fido.asd.sgi.com>
mik...@engr.sgi.com "Mike McDonald" writes:

> I think you are seriously underestimating Microsoft's profits. Bill is
> spending BIG bucks hiring as many big named researchers as he can.

I frequently recommend browsing the MSR website. If this was all
you saw of MS, you might get a very different impression of them.
For example, they have researchers using Common Lisp and Haskell,
two of my favourite languages. Their papers can be read by anyone.

Alas, this gets very little attention. Instead, we get the "evil
empire" label again and again. Some of Erik's points are good,
but he's only refering to the surface, i.e. what MS are selling
_today_. MSR should be compared to places like MIT, CMU, etc.
I'd like to know how their work compares, given the relatively
short time MSR has existed.

The danger is that the "evil empire" hatemail will become an
self-fullfully prophecy, by slowly killing everything that isn't
"mainstream" enough, e.g. things like ActiveVRML. Do we want the
VR world dominated by "C/C++ of death" attitudes? I'd prefer a
world of people who're a little more open minded. Why not support
a fledgling idea, and help it grow into something powerful?

If we continually bash MS, and spread the idea that MS are a lost
cause with nothing to offer us, we may miss something valuable.
I have no intention of spending the next 10 years coding in C++!
Let's support the non-C++ technology being used, and in some cases
_developed_, by MS.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."


Ken Tilton

unread,
Jan 30, 1997, 3:00:00 AM1/30/97
to

Cyber Surfer wrote:
>
> I frequently recommend browsing the MSR website. If this was all
> you saw of MS, you might get a very different impression of them.
> For example, they have researchers using Common Lisp and Haskell,
> two of my favourite languages.

Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
Microsoft Common Lisp?

The rounding error on his interest could finance the whole thing. :)

Seriously, we could get up a petition explaining why MsCL would be a
great thing (newsgroup project) and all sign it.


Ken


==========================================================
Dear Mr. Gates,

Minor premise: Bill Gates is a programmer.
Major premise: Common Lisp is a Great Language.
SomeLatinus OrOtherus: Bill Gates should do Visual Common Lisp.

Common Lisp is garbage-collected, dynamic, introspective,
object-oriented, exceptions-enabled, compiled and ANSI Standard.

And it is not Java. :)

Anyway, /I/ would love to see a Visual Common Lisp.

Signed,

Ken Tilton, Missing Link Software
educational software developer (now using MCL)
ti...@bway.net

============================================================

Cyber Surfer

unread,
Jan 31, 1997, 3:00:00 AM1/31/97
to

In article <32F179...@bway.net> ti...@bway.net "Ken Tilton" writes:

> Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp?
>
> The rounding error on his interest could finance the whole thing. :)
>
> Seriously, we could get up a petition explaining why MsCL would be a
> great thing (newsgroup project) and all sign it.

I'm hoping that this will indeed someday happen. Probably after
Intentional Programming has run out of steam.

> ==========================================================
> Dear Mr. Gates,
>
> Minor premise: Bill Gates is a programmer.
> Major premise: Common Lisp is a Great Language.
> SomeLatinus OrOtherus: Bill Gates should do Visual Common Lisp.
>
> Common Lisp is garbage-collected, dynamic, introspective,
> object-oriented, exceptions-enabled, compiled and ANSI Standard.
>
> And it is not Java. :)
>
> Anyway, /I/ would love to see a Visual Common Lisp.
>
> Signed,
>
> Ken Tilton, Missing Link Software
> educational software developer (now using MCL)
> ti...@bway.net
>
> ============================================================

The flaw here is that Gates is a Basic fan. He stated in Byte
many moons ago (mid 80s?) that his intention was to make Basic
a universal scripting language. He's just succeeded in doing
that, for Windows. Happily for us, he's also made it possible
for other languages to use the same technology.

Who might have predicted that Basic would make this possible?
Was it actually Basic, or the whim of a successful business man?
That's a question for histories of the 22nd century, who'll no
doubt be reading an archive of this thread, trying to understand
where it all went right/wrong (you can bet that historians will
disagree about _that_).

One thing is certainly true. Money talks.

Will Ware

unread,
Jan 31, 1997, 3:00:00 AM1/31/97
to

Ken Tilton (ti...@bway.net) wrote:
> why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp? ...get up a petition explaining why MsCL would be a

> great thing (newsgroup project) and all sign it.

MSCL is an interesting idea, but Gates probably doesn't decide anything on
the basis of anything so egalitarian as a petition. Making a case for its
viability as a business decision would be more influential. An example might
be a petition, not asking that he develop and market MSCL, but representing
people who are pretty sure they would use it if he did. Show him some
market share and maybe he'll start to drool.

Another thing that might have some influence would be to point out cases
where a business had a win by using Lisp. I remember reading one of these
recently, probably in this newsgroup, but now I don't remember what the
story was. And it may be that Gates himself is unaware that Lisp is used
within Microsoft; it couldn't hurt to point that out.

Elsewhere in this thread, somebody pointed out Gates is a Basic fan. If he
allows his own preferences to affect his business decisions, perhaps he can
be won over with features of Lisp that are remniscent of Basic. The big one
that springs to mind is instant feedback, typing something and getting an
immediate response.

If MS came out with a Visual Common Lisp, it would violently thrust Lisp
into common usage. On the one hand, it would leave in its wake a vanguard
of people wearing "I hacked Lisp before Lisp was cool" T-shirts, and many
of them would rue the loss of Lisp's status as arcana. On the other hand,
there would quickly follow the creation of all kinds of tools and libraries
to make life easier for Lisp programmers (mostly commercial of course, but
the gnu-ish stuff would continue to thrive). And the world would be made a
better place for having Lisp in a much more prominent role.
--
-------------------------------------------------------------
Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289

Rainer Joswig

unread,
Jan 31, 1997, 3:00:00 AM1/31/97
to

In article <32F179...@bway.net>, ti...@bway.net wrote:

> Cyber Surfer wrote:
> >
> > I frequently recommend browsing the MSR website. If this was all
> > you saw of MS, you might get a very different impression of them.
> > For example, they have researchers using Common Lisp and Haskell,
> > two of my favourite languages.
>

> Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> Microsoft Common Lisp?

Ask his wife. She should already know about this stuff ("BOB").

--
http://www.lavielle.com/~joswig/

Samuel S. Paik

unread,
Jan 31, 1997, 3:00:00 AM1/31/97
to

>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
>Microsoft Common Lisp?

Why would Microsoft be interested in such a large standardized ball
of wax? Obviously, Microsoft Visual Lisp will look something like this:

define fact (x)
if (x eq 0)
return 0;
else
return x * fact (x - 1);
end fact;

[BIG SMILEY HERE]

Sam

--
408-749-8798 / pa...@webnexus.com
I speak for xyne KS since I AM xyne KS.
Resisitance is not futile! http://www.be.com/

Samuel S. Paik

unread,
Jan 31, 1997, 3:00:00 AM1/31/97
to

>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
>Microsoft Common Lisp?

Oh, and obviously they would call it "Microsoft Visual L++"

Sam,
who was initially confused why Microsoft would want to do an enhanced
J (APL successor).

Jan Gray

unread,
Feb 1, 1997, 3:00:00 AM2/1/97
to

Will Ware <ww...@world.std.com> wrote in article
<E4wA0...@world.std.com>...

> If MS came out with a Visual Common Lisp, it would violently thrust Lisp
> into common usage...

Surprise, been there and done that. At the time it hardly had the effect
you wish for. -:

From Byte, Mar. 1986:
p.32A: "Microsoft languages speak for themselves."
[an eight page insert describing Microsoft C,
Macro Assembler, FORTRAN, COBOL, Pascal,
QuickBasic, muMATH, and...Microsoft LISP:]

p.32H: "LISP: The language of Artificial Intelligence."

"What's Microsoft LISP got going for you? It runs significantly faster
than the competition. And this new version adds several advanced
libraries. Over 400 Common LISP functions, macros and
special forms. Most implemented in machine code."

"If you're putting AI on your PC, Microsoft LISP is your language."


Don't hold your breath for Microsoft Visual Standard ML either.
Speaking only for myself,

Jan Gray
Redmond, WA
//www3.sympatico.ca/jsgray

Hussar

unread,
Feb 1, 1997, 3:00:00 AM2/1/97
to

ww...@world.std.com (Will Ware) wrote:

>MSCL is an interesting idea, but Gates probably doesn't decide anything on
>the basis of anything so egalitarian as a petition. Making a case for its
>viability as a business decision would be more influential. An example might
>be a petition, not asking that he develop and market MSCL, but representing
>people who are pretty sure they would use it if he did. Show him some
>market share and maybe he'll start to drool.

It would probably be better to get some small, dynamic company to do
the project. Then show it to Microsoft, let them rip it off or buy the
original company, and then market it.

That way it would be done right, and expensive.
-- What you accomplish today is very important --
-- You're trading a day of your life for it. --

The reply-to email address on this post is false.
To send email to me, use this address, backwards:
net.tiac@hussar


Cyber Surfer

unread,
Feb 2, 1997, 3:00:00 AM2/2/97
to

In article <01bc1003$a834f340$717dbacd@p5-166> jsg...@acm.org "Jan Gray" writes:

> Surprise, been there and done that. At the time it hardly had the effect
> you wish for. -:
>
> From Byte, Mar. 1986:
> p.32A: "Microsoft languages speak for themselves."
> [an eight page insert describing Microsoft C,
> Macro Assembler, FORTRAN, COBOL, Pascal,
> QuickBasic, muMATH, and...Microsoft LISP:]
>
> p.32H: "LISP: The language of Artificial Intelligence."
>
> "What's Microsoft LISP got going for you? It runs significantly faster
> than the competition. And this new version adds several advanced
> libraries. Over 400 Common LISP functions, macros and
> special forms. Most implemented in machine code."
>
> "If you're putting AI on your PC, Microsoft LISP is your language."

Was this a Lisp that was developed in-house? I doubt it.
Just below the Lisp section of that advert is...muMath.
Perhaps my memory is deceiving me, but I recall reading
a review of muLisp in the late 70s or very early 80s
that included muMath (and muSimp, an "algol"-like parser
for muLisp). Could it be that MS acquired a later version
of muLisp?

It's not impossible for a company to buy a product from
the people who developed it, and then not understand it
well enough to know what to do with it (e.g. Borland and
ObjectVision - a great development tool waiting to be born,
or a power data entry app? Borland couldn't decide).

Perhaps MS had the same problem with Lisp. Poor marketing
of Lisp, and excellent marketing of C, C++, Basic, etc,
could've been the cause of this product failure.

The previous page tells you about MS Pascal and QuickBasic.
MS Pascal is either no longer supported, or is so poorly
supported that MS keep it a secret. Did MS give up, rather
than compete with Borland Pascal, or was it an internal
political issue?



> Don't hold your breath for Microsoft Visual Standard ML either.
> Speaking only for myself,

I won't be holding my breath, but this is mainly because
I don't believe that any particular languages is _the_ tool
to use. I merely see a language as a tool that may be used.
I leave the politics and religious wars to other people.

Note that MS put Lisp right at the end of a series of pages
about various languages, with C at the front. Lisp and muMath
share the page with...Sort. Even then, MS treated Lisp as
a low priority. If potential Lisp developers failed to buy
Lisp, I think that they can hardly be blamed. Byte readers
would've at least had some small understanding of what Lisp
was and could do, dispite the dominance of C and Basic memes
in that publications.

When Byte stopped reviewing Lisp systems, it was only a matter
of time before I stopping reading that magazine. Since then,
Byte has done even more to promote C and Basic. Dick Pountain's
column has remained, spreading the memes of higher level languages,
but it's irregular. The message is not as positive as people
here on UseNet can find.

What should we conclude from this? That MS suck? MS are way
too big to generalise with such a statement. Do MSR also suck?
That's debatable. Does Byte suck? Is that an equally fair
statement? I don't know.

It's certainly relative. UseNet gives us news of developing
tools and technology, right from the horse's mouth. A magazine
has to select news, interprete it, and then present it in a
form that hopefully its readers will understand and appreciate.
That's a difficult task. MS have another challenge, which is
too sell (some of) it to (some of) us.

Today, Byte looks to me more like a fat commercial for MS
software - not that UseNet is entirely free of such bias,
either. We're only human, after all.

Michael Sperber [Mr. Preprocessor]

unread,
Feb 2, 1997, 3:00:00 AM2/2/97
to

>>>>> "MR" == Cyber Surfer <cyber_...@nospam.wildcard.demon.co.uk> writes:

MR> In article <01bc1003$a834f340$717dbacd@p5-166> jsg...@acm.org "Jan Gray" writes:

>> From Byte, Mar. 1986:
>> p.32A: "Microsoft languages speak for themselves."
>> [an eight page insert describing Microsoft C,
>> Macro Assembler, FORTRAN, COBOL, Pascal,
>> QuickBasic, muMATH, and...Microsoft LISP:]
>>
>> p.32H: "LISP: The language of Artificial Intelligence."
>>

>> "What's Microsoft LISP got going for you? [ ... ]

MR> Was this a Lisp that was developed in-house? I doubt it.

No, it was done by the Soft Warehouse, a Honolulu-based company.
(Indeed the same one that did muMath and muSimp.) Cool stuff, back
then.

Cheers =8-} Mike

Will Hartung

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

ww...@world.std.com (Will Ware) writes:

>If MS came out with a Visual Common Lisp, it would violently thrust Lisp
>into common usage.

Do you really think so? Is it the belief that MS merely has to stamp
something with its brand, and it instantly becomes accessible and
popular?

I'll grant that MS has great marketing, makes savy business deals, and
tends to stick to its guns when swaying the market, but its brand name
isn't all powerful.

I'm going to flick on the wayback machine and have it set to the early
80's.

Microcomputers were coming into their own, we had a plethora of
different "home" computers, and CPM was powering the bleeding edge
micro-business solutions.

Rogue HAM radio and Model Raliroading geeks were buried in their
basements, with their heads swimming in clouds of solder smoke, trying
to get their own franken-puters Alive(!).

Memory was scarce, mass storage was rated in "minutes" rather than
megabytes. Assembly language was the gurus choice...at least until
they could get ... BASIC.

For whatever reason, the micro-cpu world grabbed hold of BASIC, in
some form, and ran off into the night laughing. Was it because Gates
and Co. did the initial port to the Altair? Making it a readily
available high-level language for anyone calling? I don't know.

I do know that in 1977, Radio Shack sold their Model I computer with
4K and BASIC (MS-BASIC I might add) in ROM. Soon after, just about
every single pre-built standalone computer being sold had BASIC of
some kind. Apple, Commodore, Exidy, Ohio Scientific, Atari...even
Sinclair.

BASIC was being used to write zillions of vertical apps on CPM
machines. And every consumer computer magazine was dedicating pages
and pages to BASIC code listings.

Oh sure, there were other languages. FORTRAN and COBOL were being
ported. I remeber fighting with TRS-80 FORTRAN, but couldn't make
heads or tails because all of the books were talking about cards
readers and tape drives. I just wanted INPUT and PRINT.

Now, how many folks do you think had their first exposure to a
computer come from a home computer running BASIC? How many of these
skilled and erudite pundits in the press came up through the ranks of
Apples and Trash-80's? How many folks do you think may consider it a
crime that W95 dropped QBASIC...finally!

PC's were the next big thing, and it brought to life a product that
was simmering on CPM machines...Turbo Pascal. Who could go wrong for
$29? And how people complained about Pascal vs BASIC.

But Borland prevailed, getting a lot of mindshare and press with Turbo
Pascal.

In its heyday, there was Turbo Pascal, some C compilers, Modula-2,
etc. Anyone know that Borland created a Turbo Modula-2? They did, but
it didn't go anywhere and was sold off. FORTH, BASIC, Methods (early
Smalltalk V), etc. Bunches of languages.

There was Computer Languages magazine, Dr. Dobbs in its prime,
everything.

Borland came out with their product "Turbo Prolog". Big Name company,
nice system, WIERD language. No doubt in the midst of the AI hype.

Borland had more Language mindshare than MS did, was MS as focusing on
applications really, and did Prolog become the great redeemer?

No.

Now, maybe the implementation had lots of problems, I don't know.
Maybe Borland was too mainstream to market Prolog effectively. Perhaps
the systems were too limited to really let Prolog spread its wings and
fly.

But for whatever reason, Turbo Prolog died a nameless death.

Right now, the only languages that any real mindshare in the computing
populace are BASIC and C. The folks that would have learned BASIC on
their home computers in the past (because it was there), are now
choosing between VB or VC++...for a first language. Can you imagine
installing VC++ and going through a book "C++ in 21 days" to learn
programming? EGADS!

The best thing that MS could do with Lisp, is turn it into a COMPILED
BATCH module alternative for their C++ development system, and bundle
it with VC++. Enabling folks to do mixed language development. Putting
it instantly into the hands of a zillion developers. Whether they use
it or not, at least they now have a "Lisp" book sitting on their
shelf...err...CD.

A standalone version of MSCL would be considered as a niche product for
niche applications, and thereby ignored by the mainstream.

The press and the people would ask "Why do we need another language?
We got C for the fast stuff, and VB for the easy stuff! Why muddy the
waters?"

I downloaded a little program that someone wrote using VC++ from the
net. It was a utility for a board game. It was about 6MB of stuff.
300K of code, and the rest DLLs. MS supplied DLLs, including the
installer. I was horrified. "C++ makes small EXEs!" Harumph!

LISP is great for poking around and programming little things. It is
good for programming "interesting programs". It handles BIG stuff
pretty well. It is rich in its vast utilities, yet simple at its core
(save for, say, CLOS :-)).

MSs blessing of something does not make it "good", it does not make it
"better". About the only think that MSs blessing does for something is
make it available, and, perhaps, cheap.

And that's what people expect from MS. They want some full color
glossies, and they want it cheap. MS can do that, Bill could probably
fund that effort from the spare change on his dresser.

Visual CL exists today, in ACLs package. Cyber Surfer would like
better connectivity to Windows stuff. I think they should offer ODBC
out of the box (on their sampler CD), along with a decent DB Sample
App. It could also use a Source Code debugger/stepper.

Do that, and then bundle it in one of those "Free CD" issues with some
reasonable magazine shouting "FREE DYNAMIC OBJECT SYSTEM INSIDE".

But, Franz doesn't have the change that Bill has. It would be rather
expensive to pull off the advertisement, trying to promote a language
that is unlike everything else.

C++ and VB are easy to like, because "everybody" likes it. Its easy to
drift into the crowd and chant "Me TOO!". Its easy for beginners and
amateurs because MOST programmers are beginners. MOST programmers know
not what they do. They don't know why they bump into the limits they
do, because most are cook book, cut and paste programmers. They don't
do this for fun. Its not really interesting, just more interesting
than being a bank clerk or an auto mechanic. They'd rather be a
computer mechanic...less dirt under the finger nails. 9 to 5
programmers. Their interests lie elsewhere.

You can be a 9 to 5 programmer in Lisp, or anything else. If you don't
care about what you're coding, they you don't care about what you're
coding in. People work because they have to, not because they want to.
People code because its their job. If they're changing languages, its
because they want a new job. "I should learn XYZ so I can be more
marketable!".

I think LISPs next area should be intruding into the realm of Power
Builder and its ilk. These "4GLs" are mostly pretty horrible little
idiot savant languages that has easy access to databases. LISP should
mosey up next to Smalltalk, put its head down, and try to break
through.

MS could do something like this, but it would be at the expense of VB.
Pushing VB is good for MS because all of MS Office now has VB,
and VB is tight with W95. So, apps written in MSVB can easily leverage
MS Office on MS Windows. Of course, you can extend MS VB with MS C++.
The whole goal of MS is to sell MS stuff, and now that they have a
hard lock down on what 99% of the users do 99% of the time on 99% of
the computers, I don't see them rocking the boat much soon.

Umm, IMHO of course.


--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck

Bruce Hoult

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

pa...@webnexus.com (Samuel S. Paik) writes:
>Hey, why don't we appeal to the hacker in Bill Gates and ask him to do a
> >Microsoft Common Lisp?
>
> Why would Microsoft be interested in such a large standardized ball
> of wax? Obviously, Microsoft Visual Lisp will look something like this:
>
> define fact (x)
> if (x eq 0)
> return 0;
> else
> return x * fact (x - 1);
> end fact;
>
> [BIG SMILEY HERE]

No, no, that's not right. Wrong syntax, buggy, statement oriented rather than
expression oriented...


define method fact (x)
if (x = 0)
1;
else


x * fact (x - 1)

end if;
end method;


Or even better...

define method fact (x)
local ff (x, t);
if (x = 0)
t;
else
ff(x - 1, t * x);
end if;
end method;

ff (x, 1);
end method;


Now, I could live with a language like that. And it could even happen -- it's been
*months* since Microsoft stole something from Apple...

-- Bruce

--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...

Cyber Surfer

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

In article <vfr750E5...@netcom.com> vfr...@netcom.com "Will Hartung" writes:

> I do know that in 1977, Radio Shack sold their Model I computer with
> 4K and BASIC (MS-BASIC I might add) in ROM. Soon after, just about
> every single pre-built standalone computer being sold had BASIC of
> some kind. Apple, Commodore, Exidy, Ohio Scientific, Atari...even
> Sinclair.

I was one of the geeks using a TRS-80 Model I. Like many others,
I learned a lot from the mistakes made with that machine, and
the many attempts to fix them (e.g. Newdos, LDOS, and other
alternatives to the horror that was TRS-DOS).

> Oh sure, there were other languages. FORTRAN and COBOL were being
> ported. I remeber fighting with TRS-80 FORTRAN, but couldn't make
> heads or tails because all of the books were talking about cards
> readers and tape drives. I just wanted INPUT and PRINT.

I fixed that problem by creating my own I/O functions, using
the superb MACRO-80 assembler. With DOS, MS took a step backward
by giving us MASM, which has none of the power of MACRO-80.
The name is a _big_ clue to the source of its power. ;)



> Borland came out with their product "Turbo Prolog". Big Name company,
> nice system, WIERD language. No doubt in the midst of the AI hype.

They bought it from somebody else...



> Borland had more Language mindshare than MS did, was MS as focusing on
> applications really, and did Prolog become the great redeemer?

Perhaps Borland had no idea what to do with Prolog? Could be.

> Now, maybe the implementation had lots of problems, I don't know.
> Maybe Borland was too mainstream to market Prolog effectively. Perhaps
> the systems were too limited to really let Prolog spread its wings and
> fly.

Turbo Prolog was certainly criticised at the time for being
"non-standard". I think that was a little unfair.



> But for whatever reason, Turbo Prolog died a nameless death.

Actually, no it didn't! It was sold back to PDC, who still
sell it today. Check out their website, and Visual Prolog. ;)

> The best thing that MS could do with Lisp, is turn it into a COMPILED
> BATCH module alternative for their C++ development system, and bundle
> it with VC++. Enabling folks to do mixed language development. Putting
> it instantly into the hands of a zillion developers. Whether they use
> it or not, at least they now have a "Lisp" book sitting on their
> shelf...err...CD.

It would certainly have to intgrate well with their existing
tools, like VC++ and VB. That would mean being able to compile
code directly to a DLL, supporting all the wierd tricks that
MS use to make Windows run (exports, imports, C, C++ _and_ MS
style Pascal linkage), plus multi-threading (to keep the
("it can't do multi-threading, so must be crap" brigade from
killing it, as they're trying to do with VB and Delphi).

I've said all this before, and been shot down. It'll probably
happen this time, too. We have to incompatible orthodoxies
here, and MSCL would have to be acceptable to _both_ of them.
That's tough to do, but not impossible IMHO.

> I downloaded a little program that someone wrote using VC++ from the
> net. It was a utility for a board game. It was about 6MB of stuff.
> 300K of code, and the rest DLLs. MS supplied DLLs, including the
> installer. I was horrified. "C++ makes small EXEs!" Harumph!

I feel the same way. There's a lot of propaganda floating
about, and it doesn't just hurt Lisp. The difference between
Lisp and VB is that few people care whether VB is "less
efficient" than C++. There are enough people prepared to
accept the "deficiencies" of VB in order to get the software
they want within a reasonable period of time. Since a lot
of it will b built using components written in C++, there's
very little to complain about.

MSCL will have to fully support ActiveX. At the very least,
there are political reasons for this, but we can expect that
a lot of Windows developers will be less interested in a tool
that doesn't support the masses of components available.
Where would VB be today, if it didn't support VBX?

> Visual CL exists today, in ACLs package. Cyber Surfer would like
> better connectivity to Windows stuff. I think they should offer ODBC
> out of the box (on their sampler CD), along with a decent DB Sample
> App. It could also use a Source Code debugger/stepper.

Support ActiveX would be very tasty, too. This is stuff that
would appeal to staggeringly larger numbers of developers!
There are Lisps for Unix that can do impressive database things,
and perhaps some of them to it as standard, but I can't remember.
VC++ and VB come with this kind of support as standard, so MSCL
would need it, too.

> Do that, and then bundle it in one of those "Free CD" issues with some
> reasonable magazine shouting "FREE DYNAMIC OBJECT SYSTEM INSIDE".
>
> But, Franz doesn't have the change that Bill has. It would be rather
> expensive to pull off the advertisement, trying to promote a language
> that is unlike everything else.

Yes, being smaller than MS has its disadvantages.

> Umm, IMHO of course.

Likewise. ;)

Fergus Henderson

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:

>vfr...@netcom.com "Will Hartung" writes:
>
>> Maybe Borland was too mainstream to market Prolog effectively. Perhaps
>> the systems were too limited to really let Prolog spread its wings and
>> fly.
>
>Turbo Prolog was certainly criticised at the time for being
>"non-standard". I think that was a little unfair.

I think that criticisms of Turbo Prolog as being non-standard
were entirely fair, given that Turbo Prolog is about as similar
to standard Prolog as Java is to C++.

--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.

Cyber Surfer

unread,
Feb 3, 1997, 3:00:00 AM2/3/97
to

In article <5d52eu$9...@mulga.cs.mu.OZ.AU>
f...@murlibobo.cs.mu.OZ.AU "Fergus Henderson" writes:

> >Turbo Prolog was certainly criticised at the time for being
> >"non-standard". I think that was a little unfair.
>
> I think that criticisms of Turbo Prolog as being non-standard
> were entirely fair, given that Turbo Prolog is about as similar
> to standard Prolog as Java is to C++.

Yep, and how standard is VB? Conforming to a standard is no
guarantee of success, just as non-conforming is no guarantee
of failure. PDC Prolog aka Visual Prolog aka Turbo Prolog is
still available. In what way did Turbo Prolog fail? If this
is similar to VB's "failure", then I hope that it has much
more of the same!

Some of the problems of langage politics is a blind insistance
on adhering to standards. We may whinge about MS when they
ignore a standard, but if it's hurting them, it's hard to tell.

If I'm mistaken about Turbo Prolog's history, then I apologise.
I realise that you're know far more about Prolog than I do,
and probably ever will, do I'd prefer to bow to your superior
knowledge. However, what I recall of Turbo Prolog was that
it was a capable system, as capable as PDC Prolog is today.
The fact that the dialect and implementation are the same is
a minor issue for some programmers, and they're hardly a
minority. That's what gives me a few doubts.

This is one of life's great mysteries.

belka

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

In <855006...@wildcard.demon.co.uk> Cyber Surfer (cyber_...@nospam.wildcard.demon.co.uk) wrote of times long forgotten:

: PDC Prolog aka Visual Prolog aka Turbo Prolog is


: still available. In what way did Turbo Prolog fail?

Strict typing for predicates, no type polymorphism,
very artificial way to achieve type coercion (add another predicate).
Add that to standard Prolog problem: necessity to use '!' (cut)
for any performance, which is worse than 'go to' for program logic,
and very hard to debug due to backtracking intermixed with frivolous cuts.

Scheme after that (a nice PC-Scheme from TI) was a heaven.

Talking of Prolog, why did Micro-Prolog fail (even in Prolog camp)
is more of a question.

: The fact that the dialect and implementation are the same is


: a minor issue for some programmers, and they're hardly a
: minority. That's what gives me a few doubts.

Turbo Prolog wasn't Prolog. Period. Marketing trick
at a time when AI was buzz-word du jour.

Re: Common LISP, MS or otherwise.

Besides already discussed evident reasons I'd like to look
into statistics about who uses different languages.
A table of programmers IQ averages per language, suitably normalized,
might be suprising. That is, Common Lisp is too complex for many.

Garry,
who doesn't programm his VCR and uses exclusively
C and assemblers for the last 7-8 years.
--
Garry Belka be...@attel.com Attel Technologies San Jose, CA, USA

Erik Naggum

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

[comp.arch removed]

* Cyber Surfer


| Some of the problems of langage politics is a blind insistance on
| adhering to standards.

adhering, yes; blind, no.

language standards are specifications to which implementors (vendors) are
held responsible. without such specifications, implementors would seek to
implement anything they wanted that seemed useful, and thus making the
_language_ less reliable and less useful. I'm a language guy, and so to me
the stability of a language is directly related to how much I dare express
in that language. if I were an "app" guy, I would probably be interested
more in how much I _could_ express in a language to "get some work done".
put another way, I ask what an expression in a language means, and if I
worry about what an expression _does_, it is only because what it means is
not sufficiently well-defined for me to trust it. I believe the Sapir-Worf
hypothesis that languages determine what we can think about, and I worry
that if language loses meaning and instead is redefined in terms of actions
or operations, we lose sight of the main value of languages: abstraction.

however, Microsoft (and others) does not seem to think that specifications
are at all useful until long after the fact. many programmers think
specifications are a drag, and try to avoid them. by requiring that a
vendor adhere to the specifications for what they say they are selling, we
do nothing more than is already required in any other industry. it is when
we accept that a vendor can produce anything it wants and push changes on
its customers with impunity that we do make serious departures from
established practice in good engineering. I don't think this merits a
label like "blind adherence".

unfortunately, standards are themselves political vehicles, and whether a
standard is good or bad depends on many factors. however, when a standard
is no good, you don't see very many people adhere to it, although you may
still find parts of the corporate culture buying very expensive hype, in
blatant disrespect for technical expertise. this is symptomatic of the way
standards are treated -- decisions are made by non-technical people who are
more interested in pecuniary matters than either technical or human.

I found http://www.javasoft.com/people/jag/StandardsPhases/index.html to be
a succinct summary of the many thoughts I have also made during the 5 years
I worked with ISO standardization (1991-1996). I grew to hate the
political nonsense and the growing desire for ISO to push uniqueness the
way commercial entities do to attract customers. instead of serving the
technical communities, ISO has changed its focus to serve the marketing
departments, with the attendant lack of interest in technical problems.
ideally, Working Groups should be working groups, and the political stuff
should not take place until after the drafts and recommendations reached
Sub-Committee (or Technical Committee, where the WG or Special WG is
directly under the TC) level. however, to an increasing degree, vendors
send political representatives to WG meetings who don't contribute with
technical expertise, but rather block progress for non-technical reasons.
or they make political "demands" instead of presenting their case in such a
way as to encourage others to follow. ideally, a working group should only
vote for technical reasons, not for political reasons.

#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.

Cyber Surfer

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

In article <5d5vef$d...@news.aimnet.com> be...@attel.com "belka" writes:

> : PDC Prolog aka Visual Prolog aka Turbo Prolog is
> : still available. In what way did Turbo Prolog fail?
>
> Strict typing for predicates, no type polymorphism,
> very artificial way to achieve type coercion (add another predicate).
> Add that to standard Prolog problem: necessity to use '!' (cut)
> for any performance, which is worse than 'go to' for program logic,
> and very hard to debug due to backtracking intermixed with frivolous cuts.

A _technical_ failure, perhaps. However, it can and apparently
still is being used by developers. Curious...



> Scheme after that (a nice PC-Scheme from TI) was a heaven.

Ah, more language politics. Yes, I too prefer Scheme, but so
what? If that was enough to ensure the failure of a produce,
then VB would be history. Instead, it's a _major_ commercial
success. If that's your idea of "failure", then I'd lik to have
some of that!



> Talking of Prolog, why did Micro-Prolog fail (even in Prolog camp)
> is more of a question.

I know very little about Micro-Prolog, so I can't comment.

> : The fact that the dialect and implementation are the same is
> : a minor issue for some programmers, and they're hardly a
> : minority. That's what gives me a few doubts.
>
> Turbo Prolog wasn't Prolog. Period. Marketing trick
> at a time when AI was buzz-word du jour.

Tell PDC, not me. I don't give a shit. My choice of Prolog
would be LPA or perhaps Amzi. An "MS Prolog" would probably
look just like Visual Prolog does today, except that it might
be given some kiss-ass marketing to make it a killer. Not
that this is likely to happen!



> Re: Common LISP, MS or otherwise.
>
> Besides already discussed evident reasons I'd like to look
> into statistics about who uses different languages.
> A table of programmers IQ averages per language, suitably normalized,
> might be suprising. That is, Common Lisp is too complex for many.

I wonder if a "Visual Scheme" might be better? I suspect it
would be just as "difficult". Mind you, C++ can be challenging
for a great many programmers!

A good tutorial can help. I'd love to see a "Common Lisp for
C++ Programmers", or a similar book for Scheme. What we usually
get are books aimed at advanced Lisp people. I'm grateful for
the technical subjects (e.g. compiler theory) in many Lisp books,
but I'm very comfortable with subject. However, most C++ programmers
appear to feel rather differently. Either compiler theory is
being introduced very badly (perhaps C++ people should think
of it as merely a specilised area of string handling?), or
most programmers just can't cope with it. A "CL for C++ dummies"
tutorial might avoid such things, just as some of the more basic
Lisp tutorials already do.

Cyber Surfer

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

In article <30640078...@naggum.no> er...@naggum.no "Erik Naggum" writes:

> directly under the TC) level. however, to an increasing degree, vendors
> send political representatives to WG meetings who don't contribute with
> technical expertise, but rather block progress for non-technical reasons.
> or they make political "demands" instead of presenting their case in such a
> way as to encourage others to follow. ideally, a working group should only
> vote for technical reasons, not for political reasons.

You've said a lot here that I agree with. Alas, I see no
evidence that things are otherwise.

Robert Rodgers

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
>I wonder if a "Visual Scheme" might be better? I suspect it
>would be just as "difficult". Mind you, C++ can be challenging
>for a great many programmers!

Of course it would be better. The problem with C++ is that it
*encourages* errors. Even cool (IMHO) features were implemented
stupidly so that in some cases, the parsers don't really handle likely
constructs properly (e.g., specifying templates for arguments in
templates -- list<dummy, allocator<dummy>> [boom!]).

Actually, from this perspective, the best (commercially) thing about
C++ is that it allows poorly debugged, poorly written and
architecturally deranged code to be marketed commercially despite
common failures, because most of the crashes wont happen at the same
time / same feature. This does wonders for tech support -- "We need
you to be able to reproduce the problem, you understand . . ." -- and
also seems to be a popular development strategy these days.

>A good tutorial can help. I'd love to see a "Common Lisp for
>C++ Programmers", or a similar book for Scheme.

If anyone knows of such a book -- written by someone who actually
knows C++ -- please! add it to the FAQ!


Followups out of comp.arch.


RSR

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://www.wam.umd.edu/~rsrodger (updated 2/2/97)
please discontinue use of r...@msn.com


Fergus Henderson

unread,
Feb 4, 1997, 3:00:00 AM2/4/97
to

cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:

>f...@murlibobo.cs.mu.OZ.AU "Fergus Henderson" writes:
>
>> I think that criticisms of Turbo Prolog as being non-standard
>> were entirely fair, given that Turbo Prolog is about as similar
>> to standard Prolog as Java is to C++.
>
>Yep, and how standard is VB?

Well, I haven't actually used VB, but my guess is that
it does a fair job of backwards-compatibility.
I'll bet you could find a bunch of simple programs such as

10 PRINT 'HELLO WORLD'
20 REM is it single quotes or double-quotes?
30 REM long time since I wrote any basic ;-)
40 FOR I FROM 1 TO 100
50 PRINT I
60 NEXT I

and run them in VB. Of course, taking a typical VB program
and trying to run it on anything else is a hopeless task.

Similarly, Turbo Pascal was pretty non-standard, but
you could convert standard Pascal programs to Turbo Pascal
without much difficulty. The non-standard aspect was that
it had a large number of non-standard extensions.

In constrast, Turbo Prolog had several important non-standard
features that could be construed as *restrictions*, e.g.
the requirement that everything be statically typed,
and the lack of standard builtins such as functor/3 and arg/3.
In fact, the syntaxes of Turbo Prolog and standard Prolog are entirely
non-intersecting: it is not possible to write a program which is
valid in both. The upshot of all this was that taking a
standard Prolog program and converting it to Turbo Prolog
was a quite difficult exercise, and in some cases might require
completely redesigning your program. It's probably easier to convert a
typical C++ program to Java or vice versa than to convert a Prolog
program to Turbo Prolog.

>However, what I recall of Turbo Prolog was that
>it was a capable system, as capable as PDC Prolog is today.

Turbo Prolog *was* a quite capable system, as is PDC Prolog today.

The point is that the differences in languages were so great
that calling Turbo Prolog "Prolog" was really a misnomer
invented by marketing. When people found out that Turbo
Prolog wasn't really Prolog as they knew it, and that they
couldn't use it to run their Prolog programs, they were
understandably critical.

Cyber Surfer

unread,
Feb 5, 1997, 3:00:00 AM2/5/97
to

In article <5d8ha3$a...@mulga.cs.mu.OZ.AU>, f...@mundook.cs.mu.OZ.AU
says...

> >Yep, and how standard is VB?
>
> Well, I haven't actually used VB, but my guess is that
> it does a fair job of backwards-compatibility.
> I'll bet you could find a bunch of simple programs such as
>
> 10 PRINT 'HELLO WORLD'
> 20 REM is it single quotes or double-quotes?
> 30 REM long time since I wrote any basic ;-)
> 40 FOR I FROM 1 TO 100
> 50 PRINT I
> 60 NEXT I
>
> and run them in VB. Of course, taking a typical VB program
> and trying to run it on anything else is a hopeless task.

Altho line numbers are rare - if ever - used in VB programs,
they're still supported. At least VB2 supported them. I don't
know about VB4.

On the other hand, there are plenty of VB features that get
used far more often than GOTO that probably won't be found in
many other Basics.

I should add that I've never seen the ANSI Basic spec, and it's
been years since I last read anything about that dialect.



> Similarly, Turbo Pascal was pretty non-standard, but
> you could convert standard Pascal programs to Turbo Pascal
> without much difficulty. The non-standard aspect was that
> it had a large number of non-standard extensions.

Turbo Pascal was in fact far more standard than MS Pascal.
When the British Standards Institute tested these two compilers,
plus Prospero Pascal, only the latter passed the validation
suite without errors. MS Pascal failed two thirds of the tests.

Not that this is likely to have killed MS Pascal. Nor do I
think that VB's comformity (or lack of of it?) to ANSI Basic
is the reason for its success.

> In constrast, Turbo Prolog had several important non-standard
> features that could be construed as *restrictions*, e.g.
> the requirement that everything be statically typed,
> and the lack of standard builtins such as functor/3 and arg/3.

This is a far more serious problem IMHO. I had doubts about
this, at the time, and I still do.

> In fact, the syntaxes of Turbo Prolog and standard Prolog are entirely
> non-intersecting: it is not possible to write a program which is
> valid in both. The upshot of all this was that taking a
> standard Prolog program and converting it to Turbo Prolog
> was a quite difficult exercise, and in some cases might require
> completely redesigning your program. It's probably easier to convert a
> typical C++ program to Java or vice versa than to convert a Prolog
> program to Turbo Prolog.

A lot of Windows programmers will be given C++ source code. This is
what you get from MSDN (the MS Developes Network). The fact that MS
support Windows with masses of examples in C/C++ doesn't help non-C/C++
languages. VB isn't as well supported by MSDN, but it has other
strengths, like the easy use of components.

I don't like seeming to argue in favour of MS tools, but if you find
yourself developing Windows software, this stuff is hard to ignore.
A little like IBM in the mainframe and mini world? Perhaps. We don't
have to like them, and our feelings are unlikely to change anything.
A significant portion of the corporate world has chosen Windows,
and C++. Whether MS embrace standards or spit on them, they won't
go away. Worse, the "Embrace, Extend, Eliminate" strategy may give
them an _edge_ of those who "play fair" and adhere to the standards.



> >However, what I recall of Turbo Prolog was that
> >it was a capable system, as capable as PDC Prolog is today.
>
> Turbo Prolog *was* a quite capable system, as is PDC Prolog today.

That's my opinion, too. I just don't know whether I'd want to use it.
If a "Visual Lisp" looked something like this, disregarding standards
in the same way, would it be so different from the way in which MS
have disregarded other standards? I can imagine them doing it and
_succeeding_. I just don't expect them to do it any time soon.

> The point is that the differences in languages were so great
> that calling Turbo Prolog "Prolog" was really a misnomer
> invented by marketing. When people found out that Turbo
> Prolog wasn't really Prolog as they knew it, and that they
> couldn't use it to run their Prolog programs, they were
> understandably critical.

Yes, the _existing_ Prolog programmers. Lack of good marketing
failed to attract programmers new to Prolog. That may be where
MS, PDC, etc have an edge. I wouldn't touch VB with a barge pole,
but that's coz I remember an earlier dialact of Basic (from MS,
BTW), and VB disregards _that_, by using DIM to define global
variables. It's also inconsistant, by using LOCAL for local vars.
I'd have expected GLOBAL, but no, they used DIM - which used to
mean DIMension an array.

Perhaps my disgust with what VB has done to Basic is similar to how
many existing Prolog programmers felt when they saw Turbo Prolog?
Someone who'd nevr seen Prolog before might've felt more positive
about it, but with the lack of education (i.e. marketing) they
were probably unlikely to appreciate it. Hence the "failure".

Of course, I could be wrong. If there are more programmers for
Windows using standard Prolog than than VB, then I might not doubt
the value of standards. I know that's an odd way to look at it,
but VB appears to be a bigger commercial success than VB, so
perhaps that's more popular than having a powerful language, like
Prolog? Visual Prolog offers the kind of features I'm looking for
in a Prolog system, and yet it has all these "problems" - just
as VB does!

So, what should I use? Most of the time, I don't really case, as long
it's not VB or C++. Even with all of its problems, Visual Prolog still
beats those two, and oddly enough, it's closer to standard Prolog than
VB and C++ will _ever_ be. That's coz VB and C++ are not Prolog...

Ian Kemmish

unread,
Feb 5, 1997, 3:00:00 AM2/5/97
to

In article <vfr750E5...@netcom.com>, vfr...@netcom.com says...

>
>The press and the people would ask "Why do we need another language?
>We got C for the fast stuff, and VB for the easy stuff! Why muddy the
>waters?"

The press and the people swallowed Java easily enough...

All the press need is an angle. Casting half an eye over the history of X11
and NeWS, a suitable angle might be ``Lisp does everything Java does, is
more mature, runs on more platforms, and isn't owned by Sun''. :-)


============================================================================
Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ
i...@five-d.com Tel: +44 1767 601 361 Fax: +44 1767 312 006
Info on Jaws and 5D's other products on http://www.five-d.com/5d
============================================================================
`Save string while you're young. Then when you're older, you'll have a ball.'


Chris Bitmead

unread,
Feb 5, 1997, 3:00:00 AM2/5/97
to

In article <5d5vef$d...@news.aimnet.com> be...@gral.attel.com (belka) writes:

>Re: Common LISP, MS or otherwise.
>
>Besides already discussed evident reasons I'd like to look
>into statistics about who uses different languages.
>A table of programmers IQ averages per language, suitably normalized,
>might be suprising. That is, Common Lisp is too complex for many.

Are you saying that if statistics showed that CL programmers were
smarter, you would therefore conclude that CL was harder?


Fergus Henderson

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

i...@five-d.com (Ian Kemmish) writes:

>In article <vfr750E5...@netcom.com>, vfr...@netcom.com says...
>>

>>The press and the people would ask "Why do we need another language?
>>We got C for the fast stuff, and VB for the easy stuff! Why muddy the
>>waters?"
>

>The press and the people swallowed Java easily enough...
>
>All the press need is an angle. Casting half an eye over the history of X11
>and NeWS, a suitable angle might be ``Lisp does everything Java does, is
>more mature, runs on more platforms, and isn't owned by Sun''. :-)

Yes, that might be a suitable angle, but the press reports NEWS, and
Lisp isn't new.

Zvi Lamm

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

Fergus Henderson (f...@murlibobo.cs.mu.OZ.AU) wrote:
: cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:

: >Turbo Prolog was certainly criticised at the time for being


: >"non-standard". I think that was a little unfair.

: I think that criticisms of Turbo Prolog as being non-standard


: were entirely fair, given that Turbo Prolog is about as similar
: to standard Prolog as Java is to C++.


As someone who started programming Prolog on Turbo Prolog, I feel I have
to testify that one can not learn Prolog from Turbo Prolog since they are
different lanaguages.

The real fact is that even though Turbo Prlog is a nice system, it lacks
so many Prolog features, making lack most of Prolog strength.

First time I head of a DCG (that the grammer extension that let's you
write parsers quick) - first Turbo Prolog frustration.

First time I heard of setof/3 - another point down against Turbo.

And so the list grew.

Result was I decided Turbo Prolog is a nice language for writing quick
applications, that use Prolog as a smart database; but that when you need
to use some of Prolog 's best features you should look elsewhere.

I still feel that way.

You can program Turbo Prolog for years - and not know what Prolog is.

Sad but true.

--
Ehud Lamm msl...@pluto.mscc.huji.ac.il

Reini Urban

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

On Wed, 5 Feb 1997 16:41:24 -0000, Cyber Surfer wrote:
>If a "Visual Lisp" looked something like this, disregarding standards
>in the same way, would it be so different from the way in which MS
>have disregarded other standards? I can imagine them doing it and
>_succeeding_. I just don't expect them to do it any time soon.

BTW:
A product called "Visual Lisp" already exists! Wonder if they already
protected it as trademark. It's a simple AutoLISP editor by a company
called Sierra Hermitage.

see http://xarch.tu-graz.ac.at/autocad/lsp_tools/visual-lisp.html
(they have only compuserve accounts)

but this would be as i guess no major problem for the microshloft imperium.
;|Reini - All opinions expressed are probably wrong|;

Peter da Silva

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

In article <5dbqqm$a...@mulga.cs.mu.oz.au>,

Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> wrote:
> Yes, that might be a suitable angle, but the press reports NEWS, and
> Lisp isn't new.

Define a new language that looks like lisp and has all the lisp features
and runs standard lisp programs, but don't call it lisp, and make it so
you can write programs that look sorta pascalish... maybe borrow from Logo
or Smalltalk for the "new" syntax. People like algol-style syntax, even
if it's as variant as VB's or C's.

That'd be news, yes?
--

The Reverend Peter da Silva, ULC, COQO, BOFH.

Har du kramat din varg, idag? `-_-'

Erik Naggum

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

* Peter da Silva

| Define a new language that looks like lisp and has all the lisp features
| and runs standard lisp programs, but don't call it lisp, and make it so
| you can write programs that look sorta pascalish... maybe borrow from
| Logo or Smalltalk for the "new" syntax. People like algol-style syntax,
| even if it's as variant as VB's or C's.
|
| That'd be news, yes?

it sort of sounds like Apple's Dynamic Language (Dylan) to me.

#\Erik
--
my other car is a cdr

scha...@wat.hookup.net

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

In <5ddj8d$9...@web.nmti.com>, pe...@nmti.com (Peter da Silva) writes:
> ...

>Define a new language that looks like lisp and has all the lisp features
>and runs standard lisp programs, but don't call it lisp, and make it so
>you can write programs that look sorta pascalish... maybe borrow from Logo
>or Smalltalk for the "new" syntax. People like algol-style syntax, even
>if it's as variant as VB's or C's.

C's syntax is more Algol like than Pascal's (both Algol60 and Algol68)

Hartmann Schaffer


Richard A. O'Keefe

unread,
Feb 6, 1997, 3:00:00 AM2/6/97
to

vfr...@netcom.com (Will Hartung) writes:
>Borland came out with their product "Turbo Prolog".

They bought it in. I used to work for a Prolog company. We had a chance
to buy the system that became known as Turbo Prolog, and we turned it down
because while it seemed like a neat product, it was about as incompatible
with other Prolog systems (inlcuding our product) as it could possibly be.

>Borland had more Language mindshare than MS did, was MS as focusing on
>applications really, and did Prolog become the great redeemer?

Borland managed to get glossy ads for Turbo Prolog into all sorts of
places. In our more cynical moments, we blamed "ordinary" Prolog's
failure to take off the way we'd hoped on people's disappointment with TP.
The classic "Prolog" textbook is Clocksin & Mellish. All the code in that
book worked in every Prolog known to the authors. Turbo Prolog accepted
NONE of it. TP actually sold a lot of copies, for a Prolog product, but
a lot of copies stayed on shelves when the purchasers found they couldn't
actually _use_ it to do what they'd bought it for.

>Now, maybe the implementation had lots of problems, I don't know.

The implementation was a fine implementation of a good language,
it just wasn't the language that people expected when they saw the
name "Prolog". Like, can you imagine selling as "Lisp" something
that wouldn't run _any_ examples from _any_ previously written Lisp
textbook?

>Maybe Borland was too mainstream to market Prolog effectively.

Borland didn't develop the original system. Obviously they were more
committed to their "core product line".

>But for whatever reason, Turbo Prolog died a nameless death.

Turbo Prolog is neithr nameless nor dead.
The people who developed the thing in the first place are
_continuing_ to develop and to market it under the name "PDC Prolog".
By all accounts it's a very effective DOS programming tool.
(But then, so is LPA Prolog for Windows, which seems to have excellent
integration with the Win32 environment.)

>The best thing that MS could do with Lisp, is turn it into a COMPILED
>BATCH module alternative for their C++ development system, and bundle
>it with VC++.

As a matter of fact, there is an extremely important reason why MS
_need_ something like Lisp.

OLE.

C++ is clearly the wrong programming language for OLE. (Anything that
requires *manual* reference counting is a disaster waiting to happen.)
The hacks they need to get "reflection" in C++ in order to support OLE
Automation are duck soup in Lisp.

--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Clayton Weaver

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

So if I'm programming in kanji, for example, what do left and right
parentheses look like?

I'm wondering if lisp plays easier in languages where parenthetical
delimiters aren't quite the slim ascender that latin alphabets use. It
get's a lot easier to read with nested syntax coloring on just the ()
characters, for example. They just don't stand out from each other with
much emphasis when they are all the same color on a monitor displaying
ascii code pages or latin1.

I was wondering about emacs, which gets roundly criticized by people
who prefer fast and small for it's bulk and at times lethargic lisp
foundations on some hardware configurations. But emacs should benefit over
time from the same developments that make it easier to use gui
environments: cheap ram, cheap disks, and faster processors. If you have
enough ram and a fast enough machine and you can easily tell one ( from
another in (((((, either because each nesting colors the parentheses
differently or because they are an altogether more emphatic character in a
particular language's glyphs, does elisp (and common lisp and scheme by
exension) get more convenient to use and acquire the sort of do all
programming persona now enjoyed by tools like C, perl, and tcl?

Regards, Clayton Weaver cgw...@eskimo.com (Seattle)


Kellom{ki Pertti

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

In article <Pine.SUN.3.95q.97020...@eskimo.com> Clayton Weaver <cgw...@eskimo.com> writes:
I'm wondering if lisp plays easier in languages where parenthetical
delimiters aren't quite the slim ascender that latin alphabets use. It
get's a lot easier to read with nested syntax coloring on just the ()
characters, for example.

Most Lisp programmers do not see parens. If you show the definition

(define (foo x)
(if (or (zero? x)
(< x 10)
(- x 1))
(- x 1)))

to a Lisp programmer, he will see it as

(define (foo x)
(if (or (zero? x)
(< x 10))
(- x 1)
(- x 1)))

Indenting Lisp code is so easy to do right automatically that at least
I have a background assumption that code is correctly intended. The
essential information in the above is thus retained even in

define foo x
if or zero? x
< x 10
- x 1
- x 1


--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of Technology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)

Cyber Surfer

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

With a mighty <32fa38ec...@news.sime.com>,
rur...@buehnen-graz.com wibbled into the void...


> BTW:
> A product called "Visual Lisp" already exists! Wonder if they already
> protected it as trademark. It's a simple AutoLISP editor by a company
> called Sierra Hermitage.

I wasn't aware of that, thanks.



> see http://xarch.tu-graz.ac.at/autocad/lsp_tools/visual-lisp.html
> (they have only compuserve accounts)
>
> but this would be as i guess no major problem for the microshloft imperium.
> ;|Reini - All opinions expressed are probably wrong|;

Yes, I'm sure some arrangement could be made. ;-)

Thanks.

Cyber Surfer

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

With a mighty <5dcv7g$q...@news.huji.ac.il>,
msl...@pluto.mscc.huji.ac.il wibbled into the void...

> Fergus Henderson (f...@murlibobo.cs.mu.OZ.AU) wrote:
> : cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>
> : >Turbo Prolog was certainly criticised at the time for being

> : >"non-standard". I think that was a little unfair.
>
> : I think that criticisms of Turbo Prolog as being non-standard
> : were entirely fair, given that Turbo Prolog is about as similar
> : to standard Prolog as Java is to C++.
>
>
> As someone who started programming Prolog on Turbo Prolog, I feel I have
> to testify that one can not learn Prolog from Turbo Prolog since they are
> different lanaguages.
>
> The real fact is that even though Turbo Prlog is a nice system, it lacks
> so many Prolog features, making lack most of Prolog strength.
>
> You can program Turbo Prolog for years - and not know what Prolog is.

This is my point. You can still use it! It may be "wrong", but doesn't
stop everyone.

> Sad but true.

Agreed. I wish it could be otherwise, but alas, language standards
are not laws, and the means by which they're enforced are considerably
different. Not necessarily weaker, but certainly different. If they're
not powerful enough to either stop programmers from using PDC Prolog, or
to encourage PDC to make their Prolog more standard, then I believe that
this is unfortunate.

I wouldn't be suprised if PDC feel differently...but I'd be a lot happier
if they feel the same way that we do. If that's the case, then we should
asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
non-standard as it is, and yet continues to sell.

Peter da Silva

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

In article <30642571...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
> it sort of sounds like Apple's Dynamic Language (Dylan) to me.

Never heard of it, probably because it doesn't have a spiffy marketing-
friendly turbovisualhyper++ name. *g*

John Bayko

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

In article <5dbqqm$a...@mulga.cs.mu.OZ.AU>,

Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> wrote:
>
>Yes, that might be a suitable angle, but the press reports NEWS, and
>Lisp isn't new.

You know what would be new? Lisp for JVM!
Who wants to start it?

--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko

Alaric B. Williams

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

On 6 Feb 1997 21:42:37 GMT, pe...@nmti.com (Peter da Silva) wrote:

>In article <5dbqqm$a...@mulga.cs.mu.oz.au>,


>Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> wrote:
>> Yes, that might be a suitable angle, but the press reports NEWS, and
>> Lisp isn't new.
>

>Define a new language that looks like lisp and has all the lisp features
>and runs standard lisp programs, but don't call it lisp, and make it so
>you can write programs that look sorta pascalish... maybe borrow from Logo
>or Smalltalk for the "new" syntax. People like algol-style syntax, even
>if it's as variant as VB's or C's.

>That'd be news, yes?

How about my dream language I'm working on:

- Lists are more abstract than Lisp/Scheme; not necessarily chains of
cons cells. As such, they can be easily implemented as vectors in
certain circumstances etc. at the compiler's whim
- Decent object system
- Impure function like Scheme
- Assertions to make compiler's job easier in type inferencing, ie we
can assert that a function parameter is of a certain type, in a
certain range, etc. so the compiler can tell it can use 32 bit
integers safely, and if not, the point at which arithmetic could
overflow and the compiler must switch to 64 bit ints of variable size
ints
- Unspecified syntax. Code comes in binary form as a tree structure
like Java bytecode. It can be rendered in one's favourite syntax.
- Good parallelism support in the kernel
- Proper abstract association type [ name: value name: value ] as
opposed to lists (value value value)
- Tail recursive
- Higher order functions and classes (ie, paremetric types / as
values)
- delay (lazy evaluation) and future (arbitary evaluation), and
promises of either type are automatically forced by primitive
functions except for those that merely pass data on (let, define,
apply, etc)
- Core library is less minimal than Scheme, but more structued than
CL. Primitives include:
- Standard helper functions (map, filter, apply, etc)
- Knowledge base library (bring AI to the real world by giving
programmers the power to create intelligentish software), not Prolog
predicate calculus but something a little more interesting. I'm not
sure exactly what right now, since I haven't performed more than a
brief survey of AI techniques available yet.
- A standard for the serialisation of all the basic types (numbers
etc) which is adhered to well, so code and data are very portable.

I'm working on this to be part of my dream OS, ARGON. The ARGON page
is at http://www.abwillms.demon.co.uk/os/, but the ARGOT language
section is a little dated now; take my utterances above as overriding
that. The rest is still valid.

ABW
--

"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."

(Windows for Early Warning and Defence User's manual P385)

Alaric B. Williams Internet : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

Per Bothner

unread,
Feb 7, 1997, 3:00:00 AM2/7/97
to

In article <5dg90g$n...@sue.cc.uregina.ca>,

John Bayko <ba...@borealis.cs.uregina.ca> wrote:
> You know what would be new? Lisp for JVM!
> Who wants to start it?

I've already done it, if you consider Scheme to be Lisp.
Kawa compiles Scheme to Java byte codes.
See http://www.cygnus.com/~bothner/kawa.html.
A beta of Kawa 1.2 is available from ftp://ftp.cygnus.com/pub/bothner.
--
--Per Bothner
Cygnus Solutions bot...@cygnus.com http://www.cygnus.com/~bothner

Matt Kennel

unread,
Feb 8, 1997, 3:00:00 AM2/8/97
to

Peter da Silva (pe...@nmti.com) wrote:
: In article <5dbqqm$a...@mulga.cs.mu.oz.au>,
: Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> wrote:
: > Yes, that might be a suitable angle, but the press reports NEWS, and
: > Lisp isn't new.

: Define a new language that looks like lisp and has all the lisp features
: and runs standard lisp programs, but don't call it lisp, and make it so
: you can write programs that look sorta pascalish... maybe borrow from Logo
: or Smalltalk for the "new" syntax. People like algol-style syntax, even
: if it's as variant as VB's or C's.

Yeah, and maybe even architect it so you can have 'sealed' libraries
with a strong bias towards final-compiled performance, and small footprint,
and.....

: That'd be news, yes?

Yeah, the news is Apple set the Dylan pointer to nil.


Fergus Henderson

unread,
Feb 8, 1997, 3:00:00 AM2/8/97
to

cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:

>msl...@pluto.mscc.huji.ac.il wibbled into the void...
>> Fergus Henderson (f...@murlibobo.cs.mu.OZ.AU) wrote:
>> : I think that criticisms of Turbo Prolog as being non-standard
>> : were entirely fair, given that Turbo Prolog is about as similar
>> : to standard Prolog as Java is to C++.
>>
>> As someone who started programming Prolog on Turbo Prolog, I feel I have
>> to testify that one can not learn Prolog from Turbo Prolog since they are
>> different lanaguages.

[...]


>> You can program Turbo Prolog for years - and not know what Prolog is.
>
>This is my point. You can still use it! It may be "wrong", but doesn't
>stop everyone.

Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.

>> Sad but true.
>
>Agreed. I wish it could be otherwise, but alas, language standards
>are not laws, and the means by which they're enforced are considerably
>different. Not necessarily weaker, but certainly different. If they're
>not powerful enough to either stop programmers from using PDC Prolog, or
>to encourage PDC to make their Prolog more standard, then I believe that
>this is unfortunate.

I don't think that it is sad that Turbo Prolog is different from
Prolog. I'm quite happy with variety in the logic programming
community. I don't think PDC should change their product to conform to
the ISO Prolog standard. I just think it is entirely misleading
advertising to name it "Prolog".

The very idea that PDC should "make their Prolog more standard"
is premised on a fundamental misunderstanding, namely that PDC
have a Prolog. They don't. PDC couldn't possibly make Turbo
Prolog standard. The only way PDC could produce an ISO Prolog
conforming product would be to start again virtually from scratch.
Asking PDC to make their Prolog more standard is like asking
someone to make their Fortran compiler conform to the C standard.
(Except that Fortran is probably closer to C than PDC Prolog is
to Prolog.)

>If that's the case, then we should
>asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
>non-standard as it is, and yet continues to sell.

It continues to sell because it is a useful programming language.
Again, your comment seems to be premised on a fundamental misunderstanding.
It is like asking why someone's Fortran compiler continues to sell,
even though it's not C. The reason is because they are different
languages.

Cyber Surfer

unread,
Feb 9, 1997, 3:00:00 AM2/9/97
to

With a mighty <5dif4s$n...@mulga.cs.mu.OZ.AU>,
f...@murlibobo.cs.mu.OZ.AU wibbled into the void...

> >This is my point. You can still use it! It may be "wrong", but doesn't
> >stop everyone.
>
> Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.

This is the same argument that I'd use to claim that VB is neither
"Visual" nor "Basic". Sadly, it's unlikely to influence MS. Regardless
of what we call a produce, the vendor will call it whatever they please,
and people will use it. My point is that PDC Prolog aka Visual Prolog
is being used.

We may quible over a minor point, like what language _dialect_ a product
implements, but my guess it is that Visual Prolog is far closer to
what you call Prolog than VB or VC++ will _ever_ be.

> I don't think that it is sad that Turbo Prolog is different from
> Prolog. I'm quite happy with variety in the logic programming
> community. I don't think PDC should change their product to conform to
> the ISO Prolog standard. I just think it is entirely misleading
> advertising to name it "Prolog".

Well, tell 'em, then! And maybe I'll tell MS that they should change
Visual Basic's name, too. Hmm, Form Basic?



> The very idea that PDC should "make their Prolog more standard"
> is premised on a fundamental misunderstanding, namely that PDC
> have a Prolog. They don't. PDC couldn't possibly make Turbo
> Prolog standard. The only way PDC could produce an ISO Prolog
> conforming product would be to start again virtually from scratch.

You're assuming that everyone wants an ISO Prolog. A lot of people just
want a development tool. Visual Prolog looks like it has excellent
Windows support, in the sense that it uses an IDE with a form designer,
toolbar and menu support, etc. Some developers will be more concerned
about that than compatibility with a language standard. Perhaps enough to
sustain a market for a product like Visual Prolog.

> Asking PDC to make their Prolog more standard is like asking
> someone to make their Fortran compiler conform to the C standard.
> (Except that Fortran is probably closer to C than PDC Prolog is
> to Prolog.)

NO, I strongly disagree here. C and Fortran appear to me to differ more
than Visual Prolog differs from standard Prolog. The differences may be
_important_, but that's not the same thing. The ISO Prolog committee may
define ISO Prolog, but I don't feel they can decide what is and is not
_Prolog_, the family of Prolog dialects. Visual Prolog is close enough to
members of this family for me to call it Prolog, while C and Fortran are
very distant. When we look at these languages and Prolog dialects
together, Visual Prolog is not so different from other Prologs.

Let's call them distant cousins, and call C and Fortran completely
different species, rather than relatives to _any_ Prolog.



> >If that's the case, then we should
> >asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
> >non-standard as it is, and yet continues to sell.
>
> It continues to sell because it is a useful programming language.
> Again, your comment seems to be premised on a fundamental misunderstanding.
> It is like asking why someone's Fortran compiler continues to sell,
> even though it's not C. The reason is because they are different
> languages.

IMHO it's more likely that not enough people care about language purity.
Hence VB, VC++, and other atrocities. Perhaps the people who sell Visual
Prolog aren't as concerned about such things as yourself? I guess so.

So, complain to PDC. Perhaps they'll listen and do something about it.

Fergus Henderson

unread,
Feb 9, 1997, 3:00:00 AM2/9/97
to

cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:

>f...@murlibobo.cs.mu.OZ.AU wibbled into the void...
>
>> >This is my point. You can still use it! It may be "wrong", but doesn't
>> >stop everyone.
>>
>> Sure. Using Turbo Prolog is not wrong. Calling it Prolog is wrong.
>
>This is the same argument that I'd use to claim that VB is neither
>"Visual" nor "Basic".

But VB works fine for

10 PRINT "HELLO WORLD"

and many other "standard" BASIC programs. Why shouldn't they call it BASIC?
I have disagreement with people calling a *superset* of BASIC "BASIC".
But Visual Prolog is not a superset of Prolog (in fact, it's not even
a subset either).

>We may quible over a minor point, like what language _dialect_ a product
>implements, but my guess it is that Visual Prolog is far closer to
>what you call Prolog than VB or VC++ will _ever_ be.

Sure. But the differences between Visual Prolog and Prolog are more
than dialect issues. They're fundamental ones.

>> The very idea that PDC should "make their Prolog more standard"
>> is premised on a fundamental misunderstanding, namely that PDC
>> have a Prolog. They don't. PDC couldn't possibly make Turbo
>> Prolog standard. The only way PDC could produce an ISO Prolog
>> conforming product would be to start again virtually from scratch.
>
>You're assuming that everyone wants an ISO Prolog.

No, I'm certainly _not_ assuming that. You must have misunderstood
something.

>> Asking PDC to make their Prolog more standard is like asking
>> someone to make their Fortran compiler conform to the C standard.
>> (Except that Fortran is probably closer to C than PDC Prolog is
>> to Prolog.)
>
>NO, I strongly disagree here. C and Fortran appear to me to differ more
>than Visual Prolog differs from standard Prolog.

Let's see:

VP -> Prolog Fortran -> C
Syntax: Small-to-medium differences Very big differences
Type system: Huge differences Small-to-medium differences
Underlying operational semantics:
Similar Similar
Features to add:
Garbage collection dynamic memory allocation
Preprocessing (term_expansion) C preprocessor
User-defined operators
DCGs
Pointers
Bitfields
functor, arg, univ
higher-order stuff (call)
meta-programming stuff
(clause, assert, retract)
Exception handling

So the differences between VP and Prolog seem to me to be at least as
great as the differences in Fortran and C. Perhaps you are placing too
much emphasis on the syntax, which is about the only aspect where
C differs from Fortran more than Prolog differs from VP.

>The differences may be
>_important_, but that's not the same thing. The ISO Prolog committee may
>define ISO Prolog, but I don't feel they can decide what is and is not
>_Prolog_, the family of Prolog dialects.

Sure. I agree. There's plenty of non-ISO-conforming systems that I
would quite hapily call "Prolog".

But the differences between Turbo Prolog and Prolog are large enough,
IMHO, that Turbo Prolog is a different language, not just a dialect.

>Visual Prolog is close enough to
>members of this family for me to call it Prolog, while C and Fortran are
>very distant. When we look at these languages and Prolog dialects
>together, Visual Prolog is not so different from other Prologs.

Turbo Prolog and Prolog are both logic programming languages.
Fortran and C are both imperative languages.

>Let's call them distant cousins,

I'll be happy to call Visual Prolog and Prolog cousins, if you'll
call C and Fortran cousins.

But I wouldn't call Fortran C.

Cyber Surfer

unread,
Feb 9, 1997, 3:00:00 AM2/9/97
to

With a mighty <5dk3p8$f...@mulga.cs.mu.OZ.AU>,

f...@murlibobo.cs.mu.OZ.AU wibbled into the void...

> But VB works fine for


>
> 10 PRINT "HELLO WORLD"
>
> and many other "standard" BASIC programs. Why shouldn't they call it BASIC?
> I have disagreement with people calling a *superset* of BASIC "BASIC".

VB deviates from the language that I remember as Basic, a language that
used DIM to dimension arrays instead of declare global variables. VB is
still a dialect of Basic, regardless of such issues.

> But Visual Prolog is not a superset of Prolog (in fact, it's not even
> a subset either).

Is Scheme a subset of CL? I think not. It may be that there are some
features not found in Scheme, but present in CL, but as another thread
not a million newsgroups from here has shown, Scheme and CL are Lisp
dialects that bother offer features not found in the other, and not
easy to implement in the other.

I think that the superset/subset issue is an interesting one, but not
enough to convince me that Visual Prolog is not a _dialect_ of Prolog.
It may be a non-standard dialect, but I can live with that, just as
I can live with all the non-standard Lisps.



> >We may quible over a minor point, like what language _dialect_ a product
> >implements, but my guess it is that Visual Prolog is far closer to
> >what you call Prolog than VB or VC++ will _ever_ be.
>
> Sure. But the differences between Visual Prolog and Prolog are more
> than dialect issues. They're fundamental ones.

So you say. I say the same thing about VB, but I don't expect anyone
to take any notice. With Basic, it seems (or has done, in the past) that
there are as many dialects as implementations. I've been lead to believe
(by a number of Prolog books, and other sources of information) that
Prolog implementations are often unique dialects, but most of them
have a common subset. The exceptions to have included Prolog dialects
like Prolog II and Prolog III. Do you seen these languages as Prolog, or
do you claim that these too are not Prolog?

How far to we take language purity?



> >You're assuming that everyone wants an ISO Prolog.
>
> No, I'm certainly _not_ assuming that. You must have misunderstood
> something.

I wonder what that might have been. If you can explain to me at what
point a language ceases to be Prolog, then I'd greatly appreciate it.
I've been puzzled by this question for years.

> So the differences between VP and Prolog seem to me to be at least as
> great as the differences in Fortran and C. Perhaps you are placing too
> much emphasis on the syntax, which is about the only aspect where
> C differs from Fortran more than Prolog differs from VP.

How did you quantify the language differences? This is the same argument
that I use to claim that VB is not Basic, nor is it visual, so I have an
interest in how this may be done, plus how large numbers of people may be
pursuaded by your argument.

> >The differences may be
> >_important_, but that's not the same thing. The ISO Prolog committee may
> >define ISO Prolog, but I don't feel they can decide what is and is not
> >_Prolog_, the family of Prolog dialects.
>
> Sure. I agree. There's plenty of non-ISO-conforming systems that I
> would quite hapily call "Prolog".

Then this could be purely subjective, could it not? We would need to show
some objective evidence, to strongly support a claim that a compiler is
not an implementation of a language that is a member of the languages
called Prolog.



> But the differences between Turbo Prolog and Prolog are large enough,
> IMHO, that Turbo Prolog is a different language, not just a dialect.

Fair enough, I'll accept that this is your opinion. I remain unconvinced,
but that be due to seeing to many abuses of languages over the 15 or
more years that I've been programming. Some of this abuses were performed
by people who were (rightly) more concerned with getting a job done, and
creating a tool to help them do that. I'm not sure if that makes the
abuses forgivable, of course.



> Turbo Prolog and Prolog are both logic programming languages.
> Fortran and C are both imperative languages.

This is my point! PD Prolog and the familiy of Prolog dialects share
enough distingishing features, IMHO, that I'm happy to call PDC Prolog
a member of that family. It may be an illegitimate child, but I don't
feel that this is important. You may feel differently, and it appears
that you do. Fair enough.



> >Let's call them distant cousins,
>
> I'll be happy to call Visual Prolog and Prolog cousins, if you'll
> call C and Fortran cousins.

I most certainly am. ;-) In-breed, of course.



> But I wouldn't call Fortran C.

Neither would I. However, Ido frequently refer to C and C++ as "C", which
may be stretching the truth a little, but a lot of people will know what
I mean. I don't feel that the differences are important, as I dislike
them equally. In the same way, I feel that both Scheme and CL are Lisp,
and I like them equally.

My question still remains: who will stop PDC from calling their product
Prolog? Nobody, I suspect. So, this could be a non-issue. IMHO the only
issue is whether or not a tool can do what is claimed for it or not,
whether or not it can do what a developer demands from it, and whether or
not it will continue to be available in the future. That's where the
degree of compatibility with other compilers can matter.

If you use a language for teaching, then the name might be significant,
but I can't comment on that, nor I can I feel any great concern about it.
I'd love there to be more Prolog programmers, and I wouldn't wish to tie
their education to the product of any single vendor, but that's the full
extent of my concern for this issue.

I guess that's coz I'm more interested in general, language independant,
programming skills, and coz I've seen little evidence of that in the
C/C++ code that I see a lot of. Apart from what I write myself, that is.
The question of which language to use and what to call it seems pretty
silly to me, when there're so many bigger issues to worry about.

William Clodius

unread,
Feb 9, 1997, 3:00:00 AM2/9/97
to

Minor quibles:

Modern Fortran has dynamic memory, something it calls pointers (they are
actually descriptors which may carry array shape information), and bit
manipulation routines that provide most of the functionality of
bitfields. It doesn't have a language defined preprocessor, but many
people use the C preprocessor anyway, (which can be a problem if, for
instance, the preprocessor thinks that // starts a C++ comment). The
standards bodies currently are trying to decide whether or not to add a
simple conditional compilation mechanism, or something cpp based which
is more aware of Fortran syntax. In those terms C and Fortran are even
more comparable than Fergus implies.

However Fortran 90 does have a more sophisticated type system than C,
less low level operational semantics, and a far more sophisticated
notion of array.

--

William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov

Fergus Henderson

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:

>So you say. I say the same thing about VB, but I don't expect anyone
>to take any notice. With Basic, it seems (or has done, in the past) that
>there are as many dialects as implementations. I've been lead to believe
>(by a number of Prolog books, and other sources of information) that
>Prolog implementations are often unique dialects, but most of them
>have a common subset. The exceptions to have included Prolog dialects
>like Prolog II and Prolog III. Do you seen these languages as Prolog, or
>do you claim that these too are not Prolog?

I don't actually know a lot of details about Prolog II and Prolog II,
but from what little I have heard, I'd call them Prolog.

>> >You're assuming that everyone wants an ISO Prolog.
>>
>> No, I'm certainly _not_ assuming that. You must have misunderstood
>> something.
>
>I wonder what that might have been.

Well, I didn't say anything about what people _want_. I was talking
about what is or is not Prolog, not about whether people want it.

>If you can explain to me at what
>point a language ceases to be Prolog, then I'd greatly appreciate it.
>I've been puzzled by this question for years.

Well, obviously it's a fuzzy border. You could certainly image a lot
of borderline cases. But Visual Prolog is clearly on the other side of
the border, IMHO.

>> So the differences between VP and Prolog seem to me to be at least as
>> great as the differences in Fortran and C. Perhaps you are placing too
>> much emphasis on the syntax, which is about the only aspect where
>> C differs from Fortran more than Prolog differs from VP.
>
>How did you quantify the language differences?

Using the best tool for reasoning with fuzzy logic known to date --
a human brain ;-)

But you saw the table comparing TurboProlog->Prolog with Fortran->C
in my previous post, didn't you?

>Then this could be purely subjective, could it not?

It's not _purely_ subjective, but yes there are subjective aspects.

>We would need to show
>some objective evidence, to strongly support a claim that a compiler is
>not an implementation of a language that is a member of the languages
>called Prolog.

Well, one particularly strong piece of completely objective evidence is
that the intersection of the set of legal Turbo Prolog programs and the
set of legal Prolog programs is empty.

There are lots of other pieces of evidence which may not be completely
objective but which are nevertheless real -- I listed some of those
in the feature comparison table.

>> Turbo Prolog and Prolog are both logic programming languages.
>> Fortran and C are both imperative languages.
>
>This is my point! PD Prolog and the familiy of Prolog dialects share
>enough distingishing features, IMHO, that I'm happy to call PDC Prolog
>a member of that family.

But the name of the family is "logic programming", not "Prolog".
"Prolog" is the name of a particular language and it's dialects,
and Turbo Prolog is no closer to Prolog than Fortran is to C.

>The question of which language to use and what to call it seems pretty
>silly to me, when there're so many bigger issues to worry about.

I think the question of which language to use can make a lot of
difference, but yes I certainly agree that the question of what to
call it is not a big issue. (Usenet bandwidth is not proportional
to importance ;-)

Richard A. O'Keefe

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>You're assuming that everyone wants an ISO Prolog.

No, fjh explicitly denied that. In fact, he said people wanted Turbo
Prolog *because* it wasn't ISO Prolog.

>A lot of people just
>want a development tool. Visual Prolog looks like it has excellent
>Windows support, in the sense that it uses an IDE with a form designer,
>toolbar and menu support, etc.

Once again I would like to point out that LPA WinProlog has *superb*
integration with the Win32 environment.

>NO, I strongly disagree here. C and Fortran appear to me to differ more
>than Visual Prolog differs from standard Prolog.

Hmm. Fortran 90 lacks C pointer arithmetic. C89 lacks Fortran 90
string handling (I'm talking about the supplementary standard for
variable length strings), array arithmetic, module system, and overloading.
In other respects, Fortran and C are pretty darned close. It is, for
example, quite easy for Fortran and C to intercall each other without
"glue" code on most systems: scalars, arrays, records, and pointers are
close enough for a very large proportion of cases to map across quite
simply.

No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".

>The ISO Prolog committee may
>define ISO Prolog, but I don't feel they can decide what is and is not
>_Prolog_, the family of Prolog dialects.

Let's not play at Humpty-Dumpty here.
The question is "what is the POINT of calling two things by the same name?"
The answer is "we call two things by the same name when the advantages of
identifying them outweigh the disadvantages of confusing them, in the light
of the cost of finding out which one you have".
For a lot of people, the cost of finding out was the cost of buying the
product. What are the advantages of identifying them? Little or none.
Yes, Turbo/Visual/PDC Prolog *IS* a logic programming language. So is
the much better language Trilogy. If you wish to *avoid* using logic
programming languages, it is useful for you to identify Prolog, Turbo/
Visual/PDC Prolog, Trilogy, Mercury, Goedel, and many others, so it
_helps_ you to use the same name for them. (LP). Speaking as someone
who has actually tried to move substantial Prolog programs between
different dialects:

- "Prolog" unqualified is generally construed as "Clocksin &
Mellish core"

- It is fairly straightforward to move programs between C Prolog,
Quintus Prolog, Arity Prolog (up to version 4), LPA Prolog,
LPA MacProlog, Open Prolog, SICStus Prolog, ECLIPSE, NU Prolog,
IBM Prolog, Poplog provided they don't stray too far outside
the core.

- It is essentially imposssible to move between Turbo/Visual/PDC
Prolog and any of the above dialects. In fact, it is EASIER
to move between "Clocksin & Mellish" Prolog and Lisp (whether
Scheme, Common Lisp, or Interlisp) than between Prolog and
T/V/P `Prolog'.

- I will go further. I personally find it easier to translate
Fortran to C, Pascal, *and* Ada (that is, to produce all three
translations) than to translate between T/V/P `Prolog' and
"Clocksin & Mellish" Prolog. Heck, I've even found it easier
to translate Fortran to Prolog (yes, I've done that).

So for people who _do_ want to use a logic programming language,
- if they _do_ want to use one similar to the language described in the
books that talk about Prolog, it is UNhelpful to confuse T/V/P `Prolog'
with that family
- if they _don't_ want to use a member of that family, it is UNhelpful
to confuse T/V/P `Prolog' with that family.

>Visual Prolog is close enough to

>members of this family for _me_ to call it Prolog

Yes, but that tells us nothing unless you tell us what _use_ you make
of the name. Are you someone with a substantial amount of Prolog code
that you want to run on a PC? Are you someone with a substantial amount
of Turbo Prolog code that you want to run on a Mac?

>Let's call them distant cousins, and call C and Fortran completely
>different species, rather than relatives to _any_ Prolog.

fjh's point was that C and Fortran are more closely related to _each other_
than T/V/P `Prolog' is to C&M Prolog. And this is undeniably true.

>> It continues to sell because it is a useful programming language.
>> Again, your comment seems to be premised on a fundamental misunderstanding.
>> It is like asking why someone's Fortran compiler continues to sell,
>> even though it's not C. The reason is because they are different
>> languages.

>IMHO it's more likely that not enough people care about language purity.
>Hence VB, VC++, and other atrocities. Perhaps the people who sell Visual
>Prolog aren't as concerned about such things as yourself? I guess so.

Purity was never the issue. That is a straw man dressed up as a red
herring. COMPATIBILITY is the issue. I see computing as an engineering
discpline. From where I sit, the bottom line is that for any conceivable
useful Prolog program, it is cheaper to buy the most expensive PC Prolog
and do a bit of dialect conversion (for which a number of tools exist)
than to buy Turbo/Visual/PDC Prolog at *any* price and do the total
rewrite that will be called for. I don't give a crumb of reremouse
droppings for purity. I do care about whether the darned thing will
compile my programs.

>So, complain to PDC. Perhaps they'll listen and do something about it.

Unlikely. People have been complaining for about a decade.

Bengt Kleberg

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

In article <MPG.d65090ea...@news.demon.co.uk>, cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
> ..deleted

> we should
>asj why PDC Prolog (aka Visual Prolog, once aka Turbo Prolog) remains as
>non-standard as it is, and yet continues to sell.

Because the buying public (programmers) doesn't care about real Standards.
They are only interested in making money.

(real Standards => the ones that are created by more than one company).
--
Best Wishes, Bengt
--------------------------------------------------------------------
Email: Bengt....@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
the direction of that applied rotation is all downhill.'' fle...@netreach.net

James Giles

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to Richard A. O'Keefe

Richard A. O'Keefe wrote:
[...]

>
> >NO, I strongly disagree here. C and Fortran appear to me to differ more
> >than Visual Prolog differs from standard Prolog.
>
> Hmm. Fortran 90 lacks C pointer arithmetic. [...]

Of course, there are those of us who believe that pointer arithmetic is
a bad idea. Indeed, any use of pointers is a bad idea if you have an
efficient alternative available.

Pointers for which only the operations of ALLOCATE, DEALLOCATE, and
dereferencing are available are usually better than more general
pointers (Fortran ALLOCATABLE does this). Pointers for which pointer
assignment is also defined are worse, but not as bad as pointers on
which arithmetic operations are defined (Fortran POINTER sort of does
this - it ability to reference array slices is a mess). Pointers that
may only point to dynamically allocated objects (like in Pascal) are
better than pointers which can point everywhere (Fortran's pointers can
point to dynamic and TARGET objects - so it's sort of midway between
constrained and unlimited).

Whatever pointers you have, you should use as limited a subset of their
capabilities as you can get by with. This makes your program more
robust, and possibly faster.

--
J. Giles
Ricercar Software

Cyber Surfer

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

With a mighty <5dlsq9$e...@mulga.cs.mu.OZ.AU>,
f...@mundook.cs.mu.OZ.AU wibbled into the void...

> I don't actually know a lot of details about Prolog II and Prolog II,
> but from what little I have heard, I'd call them Prolog.

And they are incompatible with what many call Prolog. This is because
of the differences in syntax and semantics. I'm not sure what it is that
makes PD Prolog not "Prolog", while you accept Prolog II and Prolog III.



> >> No, I'm certainly _not_ assuming that. You must have misunderstood
> >> something.
> >
> >I wonder what that might have been.
>
> Well, I didn't say anything about what people _want_. I was talking
> about what is or is not Prolog, not about whether people want it.

That's what I thought you meant. I therefore assume that I've understood
you correctly. if I have misunderstood something, then you've yet to give
me any idea what that might be. Could you please explain?



> >If you can explain to me at what
> >point a language ceases to be Prolog, then I'd greatly appreciate it.
> >I've been puzzled by this question for years.
>
> Well, obviously it's a fuzzy border. You could certainly image a lot
> of borderline cases. But Visual Prolog is clearly on the other side of
> the border, IMHO.

What is it that is missing from Visual Prolog? While I'm aware of the
differences, I don't see anything that stops Visual Prolog from being a
member of the Prolog family of languages. It may well fail _your_
definition, of course, so you'll have to explain why this should matter
to anyone (or indeed, everyone) looking for a Prolog.



> >How did you quantify the language differences?
>
> Using the best tool for reasoning with fuzzy logic known to date --
> a human brain ;-)

Ah, a purely subjective argument? Ok, I guess this has been a complete
waste of time.

> It's not _purely_ subjective, but yes there are subjective aspects.

That's good enough for most people.

> Well, one particularly strong piece of completely objective evidence is
> that the intersection of the set of legal Turbo Prolog programs and the
> set of legal Prolog programs is empty.

"Legal"? Sure, Visual Prolog isn't ISO Prolog. So what? Does that mean
that it isn't a member of the family of languages called Prolog?



> But the name of the family is "logic programming", not "Prolog".
> "Prolog" is the name of a particular language and it's dialects,
> and Turbo Prolog is no closer to Prolog than Fortran is to C.

I didn't think that I was talking about "logic programming", but about
the family of languages called "Prolog". PDC Prolog is a lot closer to
"Prolog" than imperative languages like Fortran and C. Your argument is
loaded with subjective statements, as is mine. I therefore conclude that
we shall never agree on this, and that we should stop wasting our time.



> >The question of which language to use and what to call it seems pretty
> >silly to me, when there're so many bigger issues to worry about.
>
> I think the question of which language to use can make a lot of
> difference, but yes I certainly agree that the question of what to
> call it is not a big issue. (Usenet bandwidth is not proportional
> to importance ;-)

The reason that I say that the question of which language to use is silly
is that IMHO people use the tools they do _because they can_. The
suitability of those tools to the problem is general irrelevant, esp when
compared to the necessity of getting the problem solved. The result is
often poor, but it would be a whole lot worse if there was no solution at
all. This is my own experience, but perhaps yours is different.

If you have can give PDC a good reason to change the name of their
product, please do so. Otherwise, this is just hot air. They can call it
Prolog because they can, just as someone may call a spade a shovel.

Cyber Surfer

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

With a mighty <5dmb0s$2p5$1...@goanna.cs.rmit.edu.au>,
o...@goanna.cs.rmit.edu.au wibbled into the void...

> No, fjh explicitly denied that. In fact, he said people wanted Turbo
> Prolog *because* it wasn't ISO Prolog.

I'm refering to the (apparent) assumption that conforming to a standard
is required before a product may be called "Prolog". Perhaps this
assumption is incorrect, in which case I trust that Fergus will say so.



> Once again I would like to point out that LPA WinProlog has *superb*
> integration with the Win32 environment.

The same may be true of a great many systems, e.g. VB, but that does't
make them Prolog, nor does it exclude other systems. I like LPA Prolog,
and it would probably be my own choice, if I were to use Prolog. However,
that may well depend on factors which have nothing to do with Prolog.



> No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".

Are you agreeing with me, that the differences between Fortran and C are
greater than the differences between a PDC Prolog and...what? We should
really be talking about specific implementations, since PDC Prolog is not
a standard.

> - It is essentially imposssible to move between Turbo/Visual/PDC
> Prolog and any of the above dialects.

This is the assumption that I'm questioning. Not every programmer will
wish to move existing code from one Prolog to another, nor is the fact
that this may be hard proof that a particular language is not a dialect
of a family of languages.

If this were actually the case, the we could claim that newLisp was _not_
Lisp, because it isn't compatible with any other Lisp dialect, like CL or
Scheme.

Some programmes will be very happy to choose a single product and then
stick with it. I agree that choosing PD Prolog will then tie you to that
product. However, I know that a large number of developers don't let such
details stop them.

Even if this were not so, would it mean that PDC Prolog is not "Prolog"?
I don't think so. If you applied the same argument to VB or VC++, in a
room full of VB/VC++ programmers, you'd probably be laughed out the door.
At best, you might get a lot of blank looks.

I've made this point in another post, but here it is again. People use
the tools they do _because they can_, and details like language purity
and compatibility with other tools are mere luxuries. If programmers
using Prolog tend to enjoy such things more than programmers using
VB/VC++, then I'm pleased, as this is as it _should_ be.

Alas, most of us live in a truely _ugly_ world of software development.
This is the world that Visual Prolog is marketed at. It would be easy to
just blame the marketing folk for such abuses, but I doubt it's that
simple. In any case, few of these people will even understand your
concerns, never mind share them. I expect that few of _them_ will take
any interest in Prolog, so I wonder just who PDC's customers are? Perhaps
a minority of Prolog programmers who're prepared to accept a few quirks?

As I've said in an earlier post, this has puzzled me for years.

Cyber Surfer

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

With a mighty <5dmpjg$f38$1...@euas20.eua.ericsson.se>,
kon...@eua.ericsson.se wibbled into the void...

> Because the buying public (programmers) doesn't care about real Standards.
> They are only interested in making money.

This appears to be the case. There's certainly _more_ interest in making
money than following standards, and this is reasonable. If a company
can't stay in business, their choice of language may soon be acedemic.



> (real Standards => the ones that are created by more than one company).

I guess it'll be a while before we see ISO Erlang? ;-)

William Clodius

unread,
Feb 10, 1997, 3:00:00 AM2/10/97
to

Cyber Surfer wrote:
>
> With a mighty <5dmb0s$2p5$1...@goanna.cs.rmit.edu.au>,
> o...@goanna.cs.rmit.edu.au wibbled into the void...
>
> <snip>

>
> > No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".
>
> Are you agreeing with me, that the differences between Fortran and C are
> greater than the differences between a PDC Prolog and...what? We should
> really be talking about specific implementations, since PDC Prolog is not
> a standard.

No! Read the O'Keefe's sentence again (and its accompanying text which
you omitted). He is saying that the differences between Fortran and C
are far less than the differences between PDC prolog and any other
Prolog dialect with which he is familiar. He subsequently does cite
specific implementations, in a good deal of detail, i.e.

> - "Prolog" unqualified is generally construed as "Clocksin &
> Mellish core"
>
> - It is fairly straightforward to move programs between C Prolog,
> Quintus Prolog, Arity Prolog (up to version 4), LPA Prolog,
> LPA MacProlog, Open Prolog, SICStus Prolog, ECLIPSE, NU Prolog,
> IBM Prolog, Poplog provided they don't stray too far outside
> the core.
>
> - It is essentially imposssible to move between Turbo/Visual/PDC
> Prolog and any of the above dialects. In fact, it is EASIER
> to move between "Clocksin & Mellish" Prolog and Lisp (whether
> Scheme, Common Lisp, or Interlisp) than between Prolog and
> T/V/P `Prolog'.
>
> - I will go further. I personally find it easier to translate
> Fortran to C, Pascal, *and* Ada (that is, to produce all three
> translations) than to translate between T/V/P `Prolog' and
> "Clocksin & Mellish" Prolog. Heck, I've even found it easier
> to translate Fortran to Prolog (yes, I've done that).

Consider the last two points. He has found in practice that the best
known members of the language family termed Lisp are closer in semantics
to most languages thought of as Prolog than is the semantics of the
language T/V/P `Prolog'. He has even found a subset of the Fortran
language with closer semantics to that of the familly of languages most
often thought of as Prolog than the language T/V/P `Prolog'. Taken
literally that means he would rather consider Fortran to be a dialect of
Prolog than consider T/V/P 'Prolog' to be a dialect of Prolog.

> <snip>


> > - It is essentially imposssible to move between Turbo/Visual/PDC
> > Prolog and any of the above dialects.
>

> This is the assumption that I'm questioning. Not every programmer will
> wish to move existing code from one Prolog to another, nor is the fact
> that this may be hard proof that a particular language is not a dialect
> of a family of languages.

> <snip>

The above is incongruous. The statement

"Not every programmer will wish to move existing code from one Prolog to
another, nor is the fact that this may be hard proof that a particular

language is not a dialect of a family of languages,"

does NOT question the "assumption"

"It is essentially imposssible to move between Turbo/Visual/PDC Prolog

and any of the above dialects,"

First, O'Keefe's statement is not an "assumption" it is a statement of a
fact based on extensive experience. Second, your statement does not
question the content of his statement it ignores that content. To
question O'Keefe's statement you would have to say that you (or others
that you know of) have tried the translation of T/V/P Prolog to other
dialects of Prolog, and have not found it to be as difficult as he
claims. (As near as I can tell you have not said that at any point.) If
your statement questions anything, it is his and Fergus's contention
that the only objective criteria for deciding whether two languages are
related is the relative degree of ease of translating code from one
language to another. However, unless you can propose a specific
alternative to that criteria (and I have not seen such alternative
mentioned in this tread), then your question is rhetorical and should be
dismissed.

(Note the statement "Not every programmer will wish to move existing
code from one Prolog to another" does not question any of their
assumptions or statements. They agree with that statement. They would
probably phrase it more clearly as "Not every programmer will wish to
move existing code from Turbo/Visual/PDC Prolog to another language
calling itself Prolog or from another language calling itself Prolog to
Turbo/Visual/PDC Prolog" and go on to dismiss that statement as
irrelevant to their argument. Their argument is that for programmers not
interested in such porting the question as to whether two language are
related is relatively unimportant and only for that subset that wants to
perform such a translation is the question of significance. (This subset
however often includes those who want to use code from a textbook as a
means of learning a language.) Further, if programmers not interested in
porting such code have an abstract interest in the relatedness of two
languages, they will find the judgements of those that have ported code
to be more usefull than any other criteria that Fergus or O'Keefe (or
myself) are aware of.)

> <snip>


> Even if this were not so, would it mean that PDC Prolog is not "Prolog"?
> I don't think so. If you applied the same argument to VB or VC++, in a
> room full of VB/VC++ programmers, you'd probably be laughed out the door.
> At best, you might get a lot of blank looks.

Irrelevant. Fergus and O'Keefe would argue that they are not discussing
whether VB or VC++ are not Basic or C++ respectively. They are saying
that T/V/P Prolog is not Prolog. They have in fact consistently argued
that by their criteria VB is a dialect of Basic and VC++ is a dialect of
C++, because it is possible to use them to write code that is very
easily ported to other dialects of Basic or C++ respectively. (Whether
or not such portable code is often written in practice is irrelevant to
their case.) They argue that it is NOT possible AT ALL to write ANY code
in T/V/P Prolog that is easilly portable to other Prologs.

> <snip> I expect that few of _them_ will take


> any interest in Prolog, so I wonder just who PDC's customers are? Perhaps
> a minority of Prolog programmers who're prepared to accept a few quirks?

As I understand it, Fergus and O'Keefe take strong exception to the
qualifier "few quirks". That would imply that it is possible to work
around the language differences. They consistently argue that in its
very fundamentals T/V/P Prolog differs from that of the other Prologs.
They have argued that those fundamental differences are larger than the
fundamental differences between Fortran and C, between Lisp and Scheme,
indeed between Lisp and the other Prologs. While the comparisons have
not come up I suspect that they would argue that the differences between
Haskell and Lisp, between Dylan and Haskell, even ANSI-ISO Basic and
VC++ are all small compared to the differences between T/V/P Prolog and
other Prologs.

Fergus Henderson

unread,
Feb 10, 1997, 3:00:00 AM2/10/97