Theory #51 (superior(?) programming languages)
Cyber Surfer
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
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
> 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
Ken Tilton (ti...@bway.net) wrote:
> why don't we appeal to the hacker in Bill Gates and ask him to do a
> great thing (newsgroup project) and all sign it.
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
> 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").
Samuel S. Paik
>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
>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
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
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
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
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]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW1Ug-7D5rvPAe0Dy8QWlBwdoMp8sHWFACGdNTzwJ9mF7CkTQ=s40-c)
Michael Sperber [Mr. Preprocessor]
>>>>> "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
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
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?
>
> 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
> 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
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
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
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
[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
> : 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
> 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
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
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
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
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
>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
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
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
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
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
* 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
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
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
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
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
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
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:
>
> : >"non-standard". I think that was a little unfair.
>
> : 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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
Cyber Surfer wrote:
>
> With a mighty <5dmb0s$2p5$1...@goanna.cs.rmit.edu.au>,
> o...@goanna.cs.rmit.edu.au wibbled into the void...
>
>
> > No such parallels can be found between Prolog and "Turbo/Visual/PDC `Prolog'".
>
> 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
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>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.
Could you elaborate?
>I'm not sure what it is that
>makes PD Prolog not "Prolog", while you accept Prolog II and Prolog III.
Well, I thought that Prolog II and Prolog III were backwards compatible
with Prolog, just adding some additional features. I could well be
wrong about that, though. If that's not the case, then I'd need to
know more about them before I could decide whether it is reasonable
to call them Prolog.
>> 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.
Then why did you say that I was assuming that people wanted ISO Prolog?
I didn't say anything of the sort.
>> 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?
arg, functor, and '=..'; call; assert/retract of code; DCGs;
term_expansion; user-defined operators; dynamic typing / polymorphism;
polymorphic modes; if-then-else; garbage collection (well, maybe that's
an implementation feature, not a language features); exception
handling; and I'm sure the list goes on.
>> 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.
I mean "legal" in the sense of "accepted by the compiler",
not "conforming to the standard".
>So what?
So that means that there are *no* programs that will work under both
Turbo Prolog and Prolog.
>Does that mean
>that it isn't a member of the family of languages called Prolog?
Yes, unless there is some strong evidence to the contrary,
I would take "empty intersection" as prima facie evidence
that two languages/dialects are in fact different languages
rather than different dialects.
>> 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.
I'm not denying that! Yes, PDC Prolog is closer to Prolog than Fortran
is to Prolog. But, PDC Prolog is further away from Prolog than Fortran
is away from C, and Fortran and C are different languages, therefore PDC
Prolog and Prolog are different languages.
Fergus Henderson
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>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.
That assumption is incorrect.
>> - 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.
What Richard wrote above is true, whether you question it or not.
>Not every programmer will
>wish to move existing code from one Prolog to another,
Sure.
>nor is the fact
>that this may be hard proof that a particular language is not a dialect
>of a family of languages.
It may not be "hard proof", but I think it constitutes very strong
prima facie evidence, and in the absence of any strong evidence to the
contrary, I think you should conclude that they are different languages,
not dialects.
>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.
As Richard said, language purity is a red herring.
Sure, people use what they can. Good on them!
I'm not arguing that people should use ISO Prolog.
(They should use Mercury! Mercury is far from standard Prolog -- but
it doesn't claim to be Prolog, instead it claims to be better than Prolog.)
The question is not about whether computer languages should be "pure" --
it's English we're arguing about. it's about whether English words
should be subject to Humpty-Dumpty abuse.
Zvi Lamm
Cyber Surfer (cyber_...@wildcard.demon.co.uk) wrote:
: 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:
: >
: > 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.
Question is how many people use it to achieve the taks Prolog is supposed
to be good at. Since Turbo Prolog wasn't Prolog it failed in tasks witch
are pretty simple to do in any "real" Prolog. The thing is that since
Turbo Prolog wasn't Prolog, the name only serves as an easy marketting
tag. I don't think language laws are so important as to raise issues of
Truth In Advertising here, but I do think that you may fall into
unexpected black holes of coding and uncalled for work - if you try to
use Turbo Prolog for regular Prolog tasks.
Same thing about any implimentation that is far enough from the base
language as to cripple it.
As opposed to Visual Basic (also featured in this thread), Turbo Prolog
didn't only enhance the language (by adding compilation, PC stuff etc.)
but also cut down features. This can cause an innocent programmer some
distress....
These issues tend to boil down to religious wars. These wars are cool in
their own right - but let's not forget that language standards are here
to help us a programmers choose a right tool, and protect our investment
both in tools and in training.
--
Ehud Lamm msl...@pluto.mscc.huji.ac.il
Zvi Lamm
: >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?
One more thing to note about this. I think no one trys VB because he/she
is looking for a Basic Compiler for Windows. We use it (and *I* do
myself) because it is a language suitable for writing code for Windows,
and Windows applications (Office etc.).
Basic is not something any software developer I know of, is looking for.
Prolog is. The feeatures lacking in Trubo (PDC) Prolog make its use for
Prolog tasks hard.
Since Basic lacks any unique feature that would cause you to try
programming in it (aside from ease of use, which I also would dispute),
calling something Basic doesn't cause too many programmers to use it - in
order to achieve *with ease* certain defined tasks.
This is the kind problems that arise when you try to use Trubo Prolog
for Prolog tasks.
--
Ehud Lamm msl...@pluto.mscc.huji.ac.il
Cyber Surfer
With a mighty <5dnr2u$j...@mulga.cs.mu.OZ.AU>,
f...@murlibobo.cs.mu.OZ.AU wibbled into the void...
> >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.
>
> I'm not denying that! Yes, PDC Prolog is closer to Prolog than Fortran
> is to Prolog. But, PDC Prolog is further away from Prolog than Fortran
> is away from C, and Fortran and C are different languages, therefore PDC
> Prolog and Prolog are different languages.
Ok, I'll take your word for it. I guess PDC are misleading everyone about
the nature of PDC Prolog. If names mean nothing, which appears to be the
case, then none of this matters. If the name _does_ mean something, and
if this makes a difference, then PDC are undermining the value of the
name, and should be stopped. Is the name "Prolog" trademarked?
Y'see, I'm not disagreeing with you. What I'm doing is trying to
understand how this can matter, when PDC can commit such abuse. My guess
is that there are simply too many people who couldn't give a toss about
it. Considering how many people think that C++ is a "Good idea", I don't
think that this is our biggest problem.
Thanks.
Cyber Surfer
With a mighty <32FF6A...@lanl.gov>,
wclo...@lanl.gov wibbled into the void...
> (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.)
I have no problem with that. That just leaves the issue of PDC calling
their product Prolog...If this issue is so important, I wonder what's
being done about it? Does anyone care about this enough to do something,
has it be tried, and did the attempt fail or is it still occuring?
Cyber Surfer
With a mighty <5do13l$h...@news.huji.ac.il>,
msl...@pluto.mscc.huji.ac.il wibbled into the void...
> As opposed to Visual Basic (also featured in this thread), Turbo Prolog
> didn't only enhance the language (by adding compilation, PC stuff etc.)
> but also cut down features. This can cause an innocent programmer some
> distress....
VB also cut out valuable features. I miss using an interactive Basic.
I also loath the curruption of the language, with the misuse of names
like DIM. That's a good enough reason for me to hate it.
> These issues tend to boil down to religious wars. These wars are cool in
> their own right - but let's not forget that language standards are here
> to help us a programmers choose a right tool, and protect our investment
> both in tools and in training.
It's too bad that so many programmers don't even know what these
standards are, never mind care about them. I'd love to boycott VB and
Visual Prolog, but I'm unlikely to use either of them anyway. I advise
others not to use them, of course.
Unfortunately, it's often productivity that counts, not language
standards, or consistancy with historical usuage. So it goes.
Fergus Henderson
William Clodius <wclo...@lanl.gov> wrote lots that I agree with,
and a one small thing I would like to clarify:
>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.
That last sentence is probably overstating things slightly.
It is _possible_ to write code in Turbo/Visual/PDC Prolog that is
"easily" portable to other Prolog's, though porting would certainly not
trivial (the effort would consist mostly of deleting type declarations,
perhaps using some different predicate names, etc.).
It is the reverse direction that is the real problem.
So to summarize: no T/V/P Prolog applications would be trivially
portable to Prolog; most T/V/P Prolog applications not be easily
portable to Prolog; no Prolog programs would be easily portable to
T/V/P Prolog; and most Prolog applications would in fact be _very_
difficult to port to T/V/P Prolog.
Paul Prescod
In article <5dh1bk$ljr$1...@rtl.cygnus.com>,
Per Bothner <bot...@cygnus.com> wrote:
>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.
There is another one called "UnCommon Lisp."
Paul Prescod
Richard A. O'Keefe
This might be relevant to the argument if Scheme were called
"Turbo Common Lisp". But it is not. There is nothing about
the _name_ "Scheme" that suggests or is intended to suggest
that Scheme is a subset of Common Lisp. (In strict point of
fact, there _is_ a Scheme/CL compatibility package that lets
a great many Scheme programs run unchanged in CL. I think it's
in the Lisp F.A.Q. periodic posting.)
What does Scheme have that Common Lisp lacks?
- strict distinction between false (#F) and empty list ()
- the numeric tower is slightly different
- call-with-current-continuation
- hygienic macros
My Scheme code avoids hygienic macros because they weren't there
when I started using Scheme and I still don't fully understand them.
However, free source code for implementations is available and
could readily be added to CL.
Some of the Scheme systems available to me only support call/cc for
escapes. That _can_ be translated easily to CL. This is all I use
call/cc for.
Scheme's numeric tower is very very nice, but the permissions in the
standard and RnRS mean that I cannot *rely* on it being there. What
I _can_ rely on is, for practical purposes, a subset of CL.
The only real _nuisance_ when doing a dialect conversion from Scheme
to CL is the #f/() distinction, and in practice it's a minor problem.
(It is _not_ a minor problem going the other way, because it is easy
to ignore a distinction than to introduce one.)
I expect to *routinely* port R4RS Scheme code that I have written to
other Lisps with only minor effort. In fact, I quite often write
code in Scheme at home and port it to Xlisp-Stat (CLish) and GCL.
To give an example, consider computing the distance between two
vectors.
(define (vector-distance V1 V2)
(let ((N (vector-length V1)))
(do ((I 0 (+ I 1))
(S 0 (+ S (expt (- (vector-ref V1 I) (vector-ref V2 I)) 2)) ))
((= I N) (sqrt S))) ))
In order to run that under Common Lisp, I don't need to change anything.
I just add the following definitions:
(defmacro define (Name &rest Value)
(if (listp Name)
`(defun ,(car Name) ,(cdr Name) ,@Value)
`(setq ,Name ,(car Value))))
(defmacro vector-ref (Vec Inx)
`(aref ,Vec ,Inx))
(defun vector-length (V)
(length (the vector V)))
Of course these definitions don't get rewritten every time. They go in
a Scheme support library.
So, we find that
(1) The *name* Scheme does not make any false claims about compatibility
with other Lisps.
(2) Nevertheless, there *is* a substantial amount of overlap between
Scheme and Common Lisp, to the point where it is possible to write
substantial amounts of code that will run *without change* under
both. (This will mean a support library on each side, but the _same_
support libraries will serve for many programs.)
In contrast,
(1) The *name* "Turbo Prolog" falsely suggests (to people who have
previously learned about "Prolog" but not "Turbo Prolog") just
another C&M Prolog dialect.
(2) *NO* C&M Prolog code can run under "Turbo Prolog" without a
substantial amount of additional program-specific text AND a
number of apparently pointless changes.
Any pundit sitting in an armchair can say "it looks like Prolog to _me_".
But any poor bugger with 50 000 lines of code to port will in all seriousness
find it easier to port C&M Prolog to Scheme than to "Turbo Prolog". (Yes,
I know Scheme is not a logic programming language. That's the _point_.)
>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.
Most systems used to claim they were "Clocksin-and-Mellish" compatible,
or "Edinburgh compatible". This meant a Scheme-sized common subset.
Then they started saying "Quintus compatible". Nowadays they are
saying "ISO compatible". I personally was involved in writing a
Prolog dialect converter (shades of TRANSOR!) and can testify that
syntax was *by far* the least important factor in moving code between
Prolog systems.
>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?
We do not expect Modula 2 and Modula 3 to be dialects of the same language,
still less do we expect them to be compatible with the original Modula.
PL/1, PL/11, PL/360, and PL/516 have very little in common.
(Of course, APL\1130, APL\370, APL/700, and APL2 _do_ have a lot in common.)
Experience with other languages teaches that
"Foobar M" and "Foobar N"
where M and N are different numbers, not being year-of-standardisation
numbers, are languages that are probably quite different. Prolog II and
Prolog III were "marketed" as _different_ from C&M Prolog.
I have not had a chance to try Prolog III. I *believe* that it would
be straightforward to translate "Clocksin & Mellish" Prolog to Prolog III
mechanically, but not the reverse. If this is true, then Prolog III is a
borderline case: a reasonable argument could be made either way.
Waffling on about purity of essence can last forever.
Consider the engineering question:
- you have a substantial body of code.
- you have the alternative of purchasing an implementation of "language X"
for $PX or an implementation of "language Y" for $PY.
- if you go with language X, you will have to do a certain amount of
conversion. This will cost you $CX.
- if you go with language Y, you will have to do a certain amount of
conversion. This will cost you $CY.
- If $PX + $CX < $PY + $CY,
it is rational to go with language X *whatever* it is called.
- The cost of conversion is affected by the availability of conversion
tools. I am aware of conversion tools between C Prolog, Arity Prolog,
LPA Prolog, and IBM Prolog on the one hand and Quintus Prolog on the
other. (Quintus and SICStus are close enough that the same converter
would do for SICStus Prolog.) Some of these converters preserve
comments, so one maintains the converted code. Such tools dramatically
lower the $CX price.
- If $CX is low (by which I mean dominated by the usual costs of adapting
to a different operating system) it is reasonable to regard language X
as a dialect of the language you are currently using. If $CY is high,
it is reasonable to regard language Y as a different language.
By this criterion, I believe that anyone who has actually _tried_ it
will agree that LPA Prolog and SICStus Prolog are dialects, but LPA
WinProlog and Visual Prolog (although they run on the same machine)
are different languages.
Other people may prefer other criteria, but for people who are considering
_buying_ a compiler, I believe this to be the most useful criterion.
>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.
When it costs too much to convert code that is unarguably Prolog to
the language in question.
>I've been puzzled by this question for years.
Come come. Philosophers have puzzled over the question of identity
for MILLENIA (remember the boat?). Requiring your interlocutor to
solve the problem is a very shabby debating trick.
Let me rephrase what I said above, because it looks as though I think
I've solved it. I don't know when a language ceases to *BE* Prolog,
and what's more I don't CARE. I should have written:
it ceases to be USEFUL to call a language Prolog
when the cost of converting programs everyone agrees
to be Prolog (as described in Clocksin & Mellish, Sterling
& Shapiro, or the ISO standard) becomes too high.
What's "too high"? Well, operationally, the cost is too high when it
is cheaper to buy a rival product. If a programmer is A$50k/year plus
overheads, buying *any* commercial PC product will be cheaper than
converting a non-trivial Prolog program to Turbo Prolog. (For students,
there is a good C&M-compatible *free* Prolog for PCs, so we get the same
answer for students as for commercial software developers.) It's
certainly too high when it is cheaper to develop your own interpreter
than to convert, and I've known of that happening too.
>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.
I don't know how fjh quantifies, but
- time &
- money
look pretty good to me. I can convert several hundred lines of Fortran
code to C by hand per day. It takes me much longer to convert Prolog to
Turbo Prolog. One important reason is that the Fortran->C translation
is *local*, while the Prolog->Turbo Prolog translation is NOT.
Another important reason is that all the major features of Fortran have
direct analogues in C, whereas several of the major semantic features of
Prolog have no direct analogue in Turbo Prolog. Of course, while I _can_
convert Fortran to C, I don't. I just call Fortran from C and vice versa,
sharing _unmodified_ data structures. Indeed, I can translate Fortran to
C mechanically using the free "f2c" program.
In fact, Fortran and C could be fantastically different, and the existence
of f2c would still mean that *operationally*, Fortran and C could be
considered syntactic dialects of the same language, because the cost of
converting ($CX) is so low.
In the same way, the cost of converting *my* Scheme code to Common Lisp
is so low that *for my operational purposes* Scheme _is_ a subset of CL.
(I have to work harder to maintain compatibility with different Scheme
systems.)
>> 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,
HAVE YOU EVER TRIED TO CONVERT A SUBSTANTIAL PROGRAM IN EITHER DIRECTION?
Or supervised someone else making the attempt? I have been paid to write
and maintain "Prolog". I have been paid to maintain "Turbo Prolog". The
only thing that will convince anyone on this subject is the pain of actually
trying to _act_ on the assumption that they are the "same" language.
Now fjh is invovled in building a logic programming language called Mercury,
which has a type system similar to but very much better than Turbo's, and
a "mode" system similar to but very much better than Turbo's. Mercury is
in fact much more compatible with "Prolog" than Turbo Prolog is (if you
erase the declarations from the Mercury compiler, you have a Prolog program,
which is how they bootstrapped). The group he's in are thoroughly aware of
Turbo Prolog. I think he knows what he's talking about.
>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.
Yes, but the *NAME* of that family is "logic programming languages".
You are like someone saying, well, "so-and-so is black, so it's ok
to call him OJ Simpson."
>It may be an illegitimate child
No. I am sure Fjh would agree that Turbo Prolog is a perfectly
legitimate and honourable member of the family called "logic programming
languages". Just as Trilogy and Geodel are.
>but I don't
>feel that this is important.
Feelings schmeelings. What matters is how names lead people to ACT.
And if you adopt a name which leads people to ACT on the assumption
that Turbo Prolog is usefully similar to the language described in
books like "Programming in Prolog", "The Art of Prolog", "The Craft
of Prolog", &c, then you are deceiving them. *Operationally*, it is
so costly to convert that people who are actually interseted in
*running* programs instead of just talking about them do not obtain
any value by calling "Turbo Prolog" Prolog.
>My question still remains: who will stop PDC from calling their product
>Prolog? Nobody, I suspect.
But this is a question about POWER. That is a very different question
from "is it USEFUL to call the product Prolog."
>IMHO the only
>issue is whether or not a tool can do what is claimed for it or not,
As long as you appreciate that "claims" include expectations deliberately
created by marketing, whether or not those claims are stated baldly, then
we are in complete agreement. I have personally spoken with a number of
people who bought Turbo Prolog _because the advertisements brought about
in them the belief that it was close enough to C&M Prolog for their
purposes_ (even though the advertisements did not explicitly say so in
as many words) and felt angry at having been cheated when they found it
was not so. At the price they paid, they did not feel it worth taking
legal action, but they had considered it.
Nothing in this posting should be construed as stating or implying that
PDC or Borland *intended* to deceive anyone at all or in any way acted
unethically. Clearly, reasonable people _can_ disagree about whether it
is a "Prolog" or not. My point is not what PDC or Borland did, but what
_some_ customers felt.
Richard A. O'Keefe
cyber_...@nospam.wildcard.demon.co.uk (Cyber Surfer) writes:
>> 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.
Micro-Prolog ran on Z80-class machines. The syntax was Lispish, and the
data structures were a bit Lispier than "Edinburgh" Prologs. Perhaps if
Micro-Prolog can be said to have failed, it may have been the Lispy
syntax. Micro-Prolog was originally developed for Z80-class machines,
in which area it had few if any competitors. Prolog programmers were
prepared to put up with a strange syntax if it meant they could do work
on small machines. My then supervisor Alan Bundy was very happy with it,
I recall. When larger "micros" became common, so did competitors on the
same machines, and those competitors could offer "compatible" syntax.
Expert Systems Ltd Prolog, ALS Prolog, &c. Indeed, LPA themselves were
prompt to bring out an "Edinburgh-compatible" Prolog. To this day, the
_people_ who were responsible for Micro-Prolog are still in business
selling good Prolog systems. And LPA went on do develop "added value"
products such as APES and FLEX, and found compatibility with "Edinburgh"
Prolog to be advantageous to themselves, because it meant that they could
sell the "added value" products to customers running other vendor's
Prolog systems on machines to which LPA Prolog had not yet been ported.
I don't see Micro-Prolog as having _failed_ in any way. It just came to
the end of its useful life and was replaced by new products from the same
company. LPA started earlier than Quintus and are still in the Prolog
business. If that's failure, give me some of it!
>> 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.
Then why do you keep on yelling that it is so a Prolog?
>I wonder if a "Visual Scheme" might be better?
The snazzy Scheme system from Rice looks to me pretty "visual".
>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.
Yow. "String handling" is the _last_ thing you should think of
in connection with compilers.
I'm supervising a student compiler project this year, for a language
in the same general class of langauges as Matlab. Prolog (or better
yet, Mercury) would be IDEAL for this. Lisp or Scheme would be lovely.
But they have to know C for the run time system of the language, so
the whole thing is going to be in C. I was even advised against asking
them to use Noweb. "They haven't time to learn a new language." *Sigh*
Cyber Surfer
With a mighty <5dr973$7a5$1...@goanna.cs.rmit.edu.au>,
o...@goanna.cs.rmit.edu.au wibbled into the void...
> I don't see Micro-Prolog as having _failed_ in any way. It just came to
> the end of its useful life and was replaced by new products from the same
> company. LPA started earlier than Quintus and are still in the Prolog
> business. If that's failure, give me some of it!
This matches what I've read about Micro-Prolog, in various places,
but you've given me some more details. Thanks.
> Then why do you keep on yelling that it is so a Prolog?
I'm just not convinced that incompatibilty with members of a family is
the same as not being a member of that family. Perhaps I've used too
many languages where this is so, and that Prolog is somehow unique, in
that it's possible to have members which are syntactically and
semantically incompatible, and yet one apparent member is still not a
"true" member, for something reason that nobody can adequately explain
to me.
> >I wonder if a "Visual Scheme" might be better?
>
> The snazzy Scheme system from Rice looks to me pretty "visual".
I've not seen it, but as I understand it,. Scheme systems usually use
_text_ for the source code. If you're not sure what I mean, then I'd
the comp.lang.visual FAQ (most people don't, unfortunately). I'd be
interested in _any_ Scheme for Windows, of course.
If you _do_ know what I mean by "visual", then I'd be very interested
to know how a Scheme system might visually represent (and presumably
edit) source code. I'd be even more interested in _using_ such a
system, but so far, very few general purpose visual languages are
available for the platform I'm cursed to use. The good news is that
I'm currently playing a Windows version of Prograph, and it reminds me
a lof of Lisp and various functional languages, with OOP features.
> Yow. "String handling" is the _last_ thing you should think of
> in connection with compilers.
Perhaps. However, this was the approach used in an excellent article
in Byte, on parsers. It used Prolog, BTW, showing how you can parse a
"string" (e.g. a file) into a tree, and then turn the tree back into a
string. That could (crudely) describe a great many compilers!
> I'm supervising a student compiler project this year, for a language
> in the same general class of langauges as Matlab. Prolog (or better
> yet, Mercury) would be IDEAL for this. Lisp or Scheme would be lovely.
I agree. My current favourite choice would by Haskell, but Prolog
would make writing a backtracking parser just as easy.
> But they have to know C for the run time system of the language, so
> the whole thing is going to be in C. I was even advised against asking
> them to use Noweb. "They haven't time to learn a new language." *Sigh*
I like writing simple compilers in Lisp. The only problem is that they
produce C source code, and I _hate_ doing that. It's bad enough just
coding in C, but when I code in Lisp at the same time, it lets me see
the contrast even more clearly.
Frank A. Adrian
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote in article
<MPG.d6a3cd7...@news.demon.co.uk>...
> ... That just leaves the issue of PDC calling
> their product Prolog...If this issue is so important, I wonder what's
> being done about it? Does anyone care about this enough to do something,
> has it be tried, and did the attempt fail or is it still occuring?
There's really not much to be done. Prolog was not trademarked or
copywrited when
it was created. As far as legalities go, you can't get them for not
complying with a
standard (or even coming close). As far as I know (note: I am NOT a
lawyer) I could
put a Lisp interpreter in a box, call it Fortran-99 and legally sell it
(this may not be the
way to achieve a high customer satisfaction rating, though). As long as I
don't make
stupid and false claims like:
Compiles ANSI standard FORTRAN!
or:
Makes your DO loops run in 0 time!
that are provably false, I cannot even be sued for false advertising. In
fact, it would be
even harder for a "technically savvy" user of an "advanced programming
language" to
claim that he didn't know he would be raped - I mean such people would do
some
due diligence reasearch on the product before buying it, wouldn't they?
So basically, even though you can make intellectual and moral claims that a
company
that diverges from so many other standards SHOULD do the user community the
service of changing the language name, you can make no legal clame that
they MUST
do so.
I guess that leaves only one course of action, the one that probably should
have been
pointed to earlier in this debate - if it isn't Prolog and you want Prolog,
don't buy it, make
sure people who ask you don't buy it, and don't associate with the type of
person who
would buy it...
Frank A. Adrian
fra...@europa.com
Cyber Surfer
With a mighty <5dokd3$add$1...@goanna.cs.rmit.edu.au>,
o...@goanna.cs.rmit.edu.au wibbled into the void...
> This might be relevant to the argument if Scheme were called
> "Turbo Common Lisp". But it is not. There is nothing about
> the _name_ "Scheme" that suggests or is intended to suggest
> that Scheme is a subset of Common Lisp. (In strict point of
> fact, there _is_ a Scheme/CL compatibility package that lets
> a great many Scheme programs run unchanged in CL. I think it's
> in the Lisp F.A.Q. periodic posting.)
I didn't suggest that Scheme was a subset of CL. Why are you so
concerned about code compatibility? Not everyone feels this is
so important. Perhaps this is the problem...
> (1) The *name* Scheme does not make any false claims about compatibility
> with other Lisps.
I only mentioned Scheme because I think of it as a dialect of Lisp.
I may be mistaken, of course.
> (2) Nevertheless, there *is* a substantial amount of overlap between
> Scheme and Common Lisp, to the point where it is possible to write
> substantial amounts of code that will run *without change* under
> both. (This will mean a support library on each side, but the _same_
> support libraries will serve for many programs.)
This is irrelevant. Since was exact code compatibility necessary
in order for two languages to be members of the same family? My point
was that if this were so, then Scheme would not be a member of the
Lisp family.
Whatever you or I may feel is reasonable to call "Prolog" or "Lisp",
there's nothing to stop anyone (e.g. MS, PDC, etc) from "abusing" a
name, which may indeed be what they're doing. The real question might
not be "Wat does a name refer to?", or even "Who defines what a name
refers to?", but "Why do so few people care?"
Not that these questions actally matter. You, Fergus, myself, PDC, or
anyone else can call something whatever like, _because we can_. The
only thing that might stop us would be a trademark. Is "Prolog"
trademarked, and if so, why has it failed to stop PDC from abusing the
name? Why have the problems that you've described not stopped PDC
Prolog from being a commercial success? If code compatibility was so
important, then I'd have expected PDC Prolog to die by now.
From what I know of VB, and how it gets used, code compatibility isn't
_begin_ to be an issue. Perhaps it's the same with Visual Prolog. This
appears to be what the "Visual" part of the name implies, as it's a
common characteristic with other development tools with "Visual" as
part of the name. If you don't like what these products stand for,
then I can sympathise.
However, there's nothing that has so far stopped these products from
being sold and used in sufficient numbers for them to succeed. It's
true that Borland gave up on Turbo Prolog, but the product itself has
not yet died. In an ideal world, this would not be possible. However,
this is a far from ideal world...
Cyber Surfer
With a mighty <01bc191c$a11a5f10$e871df26@truth>,
frank_...@firstdatabank.com wibbled into the void...
> I guess that leaves only one course of action, the one that probably should
> have been
> pointed to earlier in this debate - if it isn't Prolog and you want Prolog,
> don't buy it, make
> sure people who ask you don't buy it, and don't associate with the type of
> person who
> would buy it...
Excellent advise. Not always practical, but that's a different kind of
problem. I wonder if some of the alternatives to Visual Prolog are as
good at supporting Windows development? Imagine a developer who is
more concerned about _that_ than issues like code compatibility?
I know these people exist, tho I don't know any that wish to use
Prolog.
This makes me wonder just what kind of develper uses PDC Prolog.
If Richard is right, then they're probably not Prolog programmers at
all, but some lower form of life that is either unable to distinguish
between Prolog and PDC Prolog, or just unconcerned by the differences.
Bengt Kleberg
In article <MPG.d6bc2cea...@news.demon.co.uk>, cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
...deleted
>I'm just not convinced that incompatibilty with members of a family is
>the same as not being a member of that family. Perhaps I've used too
>many languages where this is so, and that Prolog is somehow unique, in
>that it's possible to have members which are syntactically and
>semantically incompatible, and yet one apparent member is still not a
>"true" member, for something reason that nobody can adequately explain
>to me.
As Mr O'Keefe (o...@goanna.cs.rmit.edu.au) has already made a very good
answer to this question re Prolog in another place I will insert it
here (if this quoute is deemed inappropriate by Mr O'Keefe I apologise,
and withdraw it):
it ceases to be USEFUL to call a language Prolog
when the cost of converting programs everyone agrees
to be Prolog (as described in Clocksin & Mellish, Sterling
& Shapiro, or the ISO standard) becomes too high.
However, I think that there are two things to distinguish between:
Families of languages (discussed by Cyber Surfer?)
Dialects of languages (discussed by Mr O'Keefe?)
A family (like the Lisp family) can contain Scheme, MacLisp, Common Lisp, xxx
A dialect of Scheme would be ELK, MacGambit, yyy
To be syntactically and semantically incompatible inside a family is ok,
almost given, since it is ideas/concepts (not implementations) that
creates the family.
But to be syntactically and semantically incompatible towards a
language, but still be a dialect, no I don't think that is possible.
So, is Prolog a language, or a family of languages?
Fergus Henderson
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>This makes me wonder just what kind of develper uses PDC Prolog.
>If Richard is right, then they're probably not Prolog programmers at
>all,
True of course, since PDC Prolog isn't Prolog...
>but some lower form of life that is either unable to distinguish
>between Prolog and PDC Prolog, or just unconcerned by the differences.
I don't think so. They're probably just people who wanted a strongly
typed logic programming language with a compiler that can generate
efficient code for PCs and which has good support for Windows.
Fergus Henderson
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>I didn't suggest that Scheme was a subset of CL. Why are you so
>concerned about code compatibility?
Have you got any better criteria for determining language and dialect
borders?
If you think Turbo Prolog is Prolog, do you have anything other than
the name including the word "Prolog" to justify this?
William Clodius
Cyber Surfer
Wake up:
Pay attention to the thread. The recent part of the thread has been,
ineffect, why is the name Turbo/Visual/PDC Prolog unacceptably
misleading.
You wrote:
>
> With a mighty <5dokd3$add$1...@goanna.cs.rmit.edu.au>,
> o...@goanna.cs.rmit.edu.au wibbled into the void...
>
> > This might be relevant to the argument if Scheme were called
> > "Turbo Common Lisp". But it is not. There is nothing about
> > the _name_ "Scheme" that suggests or is intended to suggest
> > that Scheme is a subset of Common Lisp. (In strict point of
> > fact, there _is_ a Scheme/CL compatibility package that lets
> > a great many Scheme programs run unchanged in CL. I think it's
> > in the Lisp F.A.Q. periodic posting.)
>
> I didn't suggest that Scheme was a subset of CL. Why are you so
> concerned about code compatibility? Not everyone feels this is
> so important. Perhaps this is the problem...
>
Richard O'Keefe is simply noting that whether or not Scheme is related
to Lisp (a topic you brought up) is irrelevant to the recent part of the
thread. Scheme (unlike T/V/P Prolog) is not falsely marketing itself. He
then goes on as to why Scheme is not false maketing as opposed to T/V/P
Prolog.
> > (1) The *name* Scheme does not make any false claims about compatibility
> > with other Lisps.
>
> I only mentioned Scheme because I think of it as a dialect of Lisp.
> I may be mistaken, of course.
This response is unnecessary given the next paragraph
>
> > (2) Nevertheless, there *is* a substantial amount of overlap between
> > Scheme and Common Lisp, to the point where it is possible to write
> > substantial amounts of code that will run *without change* under
> > both. (This will mean a support library on each side, but the _same_
> > support libraries will serve for many programs.)
which in effect says that Scheme is a near dialect of Lisp. In this and
other recent messages you seem to be responding to part of the content
of the message without taking into account its context.
>
> This is irrelevant. Since was exact code compatibility necessary
> in order for two languages to be members of the same family? My point
> was that if this were so, then Scheme would not be a member of the
> Lisp family.
Your response is irrelevant. O'Keefe has never argued that exact code
similarity is required to be in the same familly. He has argued only
that the degree of semantic similarity is the primary means by which the
relationship of languages can be judged. He is in fact agreeing with you
that Lisp and Scheme are similar. He is noting that the designers of
Scheme thought that the differences were large enough to deserve giving
it a name other than Lisp, although in comparison to the differences
between T/V/P Prolog and most other Prologs those differences are minor.
As in any categorization scheme there are levels of similarity. In
programming languages the grouping might go
dialects of a language < language familly < language group < language
category < languages as a whole
The borders can be fuzzy but the differences between Scheme and Common
Lisp are sufficiently large that I would not call Scheme and Common Lisp
dialects, but they are similar enough that I would call them members of
the same familly. Dylan is sufficiently different that I would not put
it in the same familly, but would probably put it in the same language
group. SML I would put in the same language category as Scheme, Lisp,
and Dylan, i.e., impure functional languages, but not in the same group.
I suspect that O'Keefe would put T/V/P Prolog in the same language
category (Logic programming languages) as other Prologs, but not in the
same language group, let alone family.
>
> <other irrelevancies snipped>
Richard A. O'Keefe
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>I'm just not convinced that incompatibilty with members of a family is
>the same as not being a member of that family.
Let me see if I can clarify this.
Are we agreed that Algol 60, Simula 67, Algol W, Pascal, and PL/I are
all members of an "Algol family"? (By the way, I would tend to place
Turbo Prolog in _this_ family rather than the Prolog family, but that's
not my current.) I never had the chance to _write_ any Algol W, but I
read a book full of it once. My impression is that
Algol 60 -> Algol W *usually* straightforward
Algol W -> PL/I *usually* straightforward
Pascal -> Algol W doable
Pascal -> PL/I *usually* straightforward
others -> Pascal *usually* very painful
Now there is no question of direct compatibility here. For example,
Algol 60 does *not* require declaration before use, does *not* require
procedure parameters to be declared, *does* have some hairy label stuff,
and *does* have arrays with run-time bounds. In fact, the absence of
run-time bounds from (old) Pascal (the current Pascal standard includes
them in the same way as Ada) is probably _the_ major problem in adapting.
Converting in the "usually straightforward" directions is largely
mechanical, and for the most part *local*. (There is someone in this
department who promotes PL/I at every opportunity, and when you look
at C, which is what most people are using instead, you can see why he
thinks of PL/I as a better language.)
Anyway, would anyone seriously deny that these languages are closely
related? Not me.
On the other hand, would anyone in his or her right mind tolerate
calling PL/I "Algol 64"? Or for a more apt comparison, would anyone
tolerate calling Pascal "PL/I version 2"?
The point is, the people who you have been arguing against were never
denying that there was _some_ relationship between Prolog and Turbo `Prolog',
only that in observed reality, the name did in fact suggest a _far stronger_
relationship between the two languages than actually obtains. NOBODY has
denied that Turbo Prolog is a member of the "LOGIC PROGRAMMING family"
(think: genus), only that it is a member of the "Prolog clan" (think: species,
or perhaps even subspecies).
>Perhaps I've used too
>many languages where this is so, and that Prolog is somehow unique, in
>that it's possible to have members which are syntactically and
>semantically incompatible, and yet one apparent member is still not a
>"true" member, for something reason that nobody can adequately explain
>to me.
It has been explained OVER AND OVER AND OVER.
Nobody denies that Turbo `Prolog' and Prolog are both members of *some*
family of programming languages, just as Fortran, Algol 60/W/68, Pascal,
PL/I, and Ada are all members of *some* family of programming languages.
There is a "Fortran" family of languages which are to a large extent
upwards compatible, just as there is a "Prolog" family of languages
which are largely mutually compatible. The thing is, you insist on
using "Prolog" to refer to the family of logic programming languages,
which is a lot like insisting on using "Fortran" to refer to the family
of imperative procedural programming languages. If you ordered a
"Fortran" compiler from someone, and received a Pascal compiler, you
would be seriously unhappy. In the same way, and for the same reason,
some people who ordered a "Prolog" compiler from Borland and got a
"Turbo Prolog" compiler were seriously unhappy.
The key point is the *cost* of moving between one member of a "family"
and another. You can move most Algol W programs to PL/I using _local_
transformations. You cannot move Prolog programs to Turbo Prolog using
_local_ transformations.
(For what it's worth, I expect to be able to routinely move Fortran 77 code
to Ada using _local_ transformations, except for I/O formatting. It's
"tedious rather than difficulty" to use one of my pet phrases.)
As far as I am concerned, there is no _theoretical_ point here of the
kind that Cyber Surfer is demanding. It is simply that the differences
between Turbo Prolog and Prolog have crossed the threshold where if you
have an existing body of code, it is cheaper to buy a "Professional
Prolog" from _any_ other vendor than to use a _free_ copy of Turbo Prolog.
Let's take an example from the past.
Suppose a University had a B6700, which came with a "Burroughs Algol"
compiler. Suppose they had a choice of
a. converting 100 000 lines of IBM Algol to Burroughs Algol
b. modifying the B6700 compiler to accept IBM Algol
+ writing new runtime routines for it
c. buying in an "IBM Algol" compiler + runtime for the B6700.
d. Convert to PL/I at the source end, and use PL/I on the B6700.
e. Rewrite the program from scratch.
Let's imagine that a programmer's time cost NZ$100/day.
a. I'd have started by writing a SNOBOL program to to 99% of the translation.
Estimated effort to write and test that program: 5 days.
Estimated effort to do the rest of the translation: 15 days.
(I'm including reasonably thorough testing.)
Total cost: $2000.
b. The sources of the Burroughs Extended Algol compiler were available,
and very readable. Lots of people outside Burroughs modified it.
However, the B6700 compiler was strict one pass, so handling "full"
Algol would require major changes. Lexical analysis would be easy
to change. I would estimate 60 days minimum.
Cost: $6000.
c. I never saw any such compiler for sale. The market would have been
small. The price would probably have been high.
Cost: $10 000?
d. Do 98% of the work with SNOBOL on the IBM machine.
Fix and test the translation on the IBM machine.
Test the translation again on the B6700 (different arithmetic).
Estimated cost: $3000.
Advantage: original and translation can be compared on the SAME
machine.
e. Estimated cost: $50 000.
By the cost criterion, "IBM Algol" and "Burroughs Algol" are _close_
members of the "Algol family", while PL/I is further from them both.
"Dialect" conversion is clearly the cheapest approach; very much
cheaper than a rewrite, cheaper than buying or building a compiler,
and cheaper than going via a related but different language.
_This_ is the kind of analysis I have in mind. There is nothing hidden,
esoteric, unusual, or in any way mysterious about it. Sometimes changes
in quantity _do_ amount to changes in quality, sometimes they don't.
IBM Algol and Burroughs Algol were close enough to be regarded as
dialects of a common language, because it was cheap enough to *ACT* on
that belief. Turbo `Prolog' and Prolog were *not* close enough to be
regarded as dialects of a common language, because it was *expensive*
to *ACT* on that belief.
Of *course* if you are developing new code, this criterion does not
apply, and the people who are successfully and happily using Turbo/PDC/Visual
Prolog are precisely the ones who were not trying to port existing
applications but were developing *new* DOS applications.
>> >I wonder if a "Visual Scheme" might be better?'
>>
>> The snazzy Scheme system from Rice looks to me pretty "visual".
>I've not seen it, but as I understand it,. Scheme systems usually use
>_text_ for the source code. If you're not sure what I mean, then I'd
>the comp.lang.visual FAQ (most people don't, unfortunately). I'd be
>interested in _any_ Scheme for Windows, of course.
Ah. I'm aware of visual programming languages, but since Visual C++
is nothing of the kind, I wasn't sure what you meant. Scheme systems
use _trees_ for the source code, and just how that is obtained is a
matter of indifference. The Scheme from Rice _does_ work on Windows,
and it has the graphics toolkit from which a visual Scheme-based
language might be built.
>> Yow. "String handling" is the _last_ thing you should think of
>> in connection with compilers.
>Perhaps. However, this was the approach used in an excellent article
>in Byte, on parsers. It used Prolog, BTW, showing how you can parse a
>"string" (e.g. a file) into a tree, and then turn the tree back into a
>string. That could (crudely) describe a great many compilers!
But the guts of what happens in a modern compiler concerns the manipulation
of graphs and sets. Your goal is to get _away_ from strings as fast as
possible and _stay_ away from them as long as possible.
Cyber Surfer
With a mighty <5dvdn9$4...@mulga.cs.mu.OZ.AU>,
f...@murlibobo.cs.mu.OZ.AU wibbled into the void...
> cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>
> >This makes me wonder just what kind of develper uses PDC Prolog.
> >If Richard is right, then they're probably not Prolog programmers at
> >all,
>
> True of course, since PDC Prolog isn't Prolog...
And I repeat: tell this to PDC. They're confusing the hell out of me.
> >but some lower form of life that is either unable to distinguish
> >between Prolog and PDC Prolog, or just unconcerned by the differences.
>
> I don't think so. They're probably just people who wanted a strongly
> typed logic programming language with a compiler that can generate
> efficient code for PCs and which has good support for Windows.
I agree. This is what "unconcerned by the differences" refered to.
The result is that some people will call this language Prolog, which
appears to be what PDC are doing.
It makes no difference. If it did, perhaps accusing MS of being an
"evil empire" would stop people from buying their software. I suspect
that it has no such effect, but I could be wrong. However, MS _appear_
to be growing, in spite of their apparent failings. If a vendor like
PDC can call their product Prolog, who cares whether it's what you,
Richard, myself, or anyone else might call Prolog? Just try stopping
them, and I'll wish you luck. You may need it.
On the other hand, if you don't wish to do anything about it, why
worry about it? Just remove entry for PDC Prolog from the
comp.lang.prolog FAQ, and replace with an entry that states that PDC
Prolog is not Prolog. At the very least, it should note that PC Prolog
is not Prolog, rather than merely strongly typed.
Cyber Surfer
With a mighty <5dvdt2$4...@mulga.cs.mu.OZ.AU>,
f...@murlibobo.cs.mu.OZ.AU wibbled into the void...
> If you think Turbo Prolog is Prolog, do you have anything other than
> the name including the word "Prolog" to justify this?
How about the various entries in the comp.lang.prolog FAQ?
Even the FAQ implies that PDC Prolog is a Prolog system.
As I've pointed out to Richard several times, incompatible
is not always a problem.
Here's just one of the comp.lang.prolog FAQ entries:
PDC Prolog runs on IBM PCs (DOS, OS/2, Windows and SCO Unix). Formerly
known as Turbo Prolog from Borland. Includes a native code compiler
but is incompatible with most other prologs. Its variables are
strongly typed, unlike most other prologs. For more information, write
Prolog Development Center, 568 14th Street, Atlanta, GA 30318, call
800-762-2710, (404-873-1366), fax 404-872-5243 or email
pdc-r...@pdc.dk (general information), sa...@pdc.dk (sales),
sup...@pdc.dk (tech support). European customers may write to Prolog
Development Center, A/S, H.J. Holst Vej 5A, DK-2605 Broendby, Denmark,
call +45 36 72 10 22, or fax +45 36 72 02 69. Reviewed in AI Expert
January 1991. Other email addresses include 753C...@compuserve.com.
To subscribe to the PD...@nic.surfnet.nl mailing list, a discussion
list for PDC Prolog users, send mail to LIST...@nic.surfnet.nl with
SUBSCRIBE PDC-L <your full name>
in the message body.
Patrick Herring
Cyber Surfer wrote:
>
> With a mighty <5dvdt2$4...@mulga.cs.mu.OZ.AU>,
> f...@murlibobo.cs.mu.OZ.AU wibbled into the void...
>
> > If you think Turbo Prolog is Prolog, do you have anything other than
> > the name including the word "Prolog" to justify this?
>
> How about the various entries in the comp.lang.prolog FAQ?
I thought the point about Turbo Prolog was that it didn't have
back-tracking, so wasn't logic-programming (although you could say that
it's just less complete than it could be though still sound). OTOH isn't
there an ANSI Prolog now so all bets are off?
yours, Patrick
________________________________________________________
Patrick Herring at work, herr...@rlsclare.agw.bt.co.uk
"Occam's razor is so sharp, I bought the whole argument"
Cyber Surfer
With a mighty <3304DD...@rlsclare.agw.bt.co.uk>,
herr...@rlsclare.agw.bt.co.uk wibbled into the void...
> I thought the point about Turbo Prolog was that it didn't have
> back-tracking, so wasn't logic-programming (although you could say that
> it's just less complete than it could be though still sound). OTOH isn't
> there an ANSI Prolog now so all bets are off?
I wouldn't know about ANSI Prolog, but I recall something about an ISO
Prolog. I'm sure Richard O'Keefe knows more about it, as I also recall
that he used to be on the committee. Unless I'm misremembering
something, he may be able to tell you something about it.
Fergus Henderson
Patrick Herring <herr...@rlsclare.agw.bt.co.uk> writes:
>I thought the point about Turbo Prolog was that it didn't have
>back-tracking, so wasn't logic-programming
No, Turbo Prolog does have backtracking.
Cyber Surfer
With a mighty <5du6i2$clq$1...@goanna.cs.rmit.edu.au>,
o...@goanna.cs.rmit.edu.au wibbled into the void...
> Now there is no question of direct compatibility here.
I didn't say there was, nor did I say there should be.
> Anyway, would anyone seriously deny that these languages are closely
> related? Not me.
We're _agreeing_ about this.
> The point is, the people who you have been arguing against were never
> denying that there was _some_ relationship between Prolog and Turbo `Prolog',
> only that in observed reality, the name did in fact suggest a _far stronger_
> relationship between the two languages than actually obtains. NOBODY has
> denied that Turbo Prolog is a member of the "LOGIC PROGRAMMING family"
> (think: genus), only that it is a member of the "Prolog clan" (think: species,
> or perhaps even subspecies).
That's exactly what I've been saying all along. The confusion may have
come from the use of a name to refer to both a language and a language
family. This is a common practice. Even the name "Pascal" is assumed
to refer to a single language, when it is in fact a family of dialects
that more or less share a common subset. This appears to be how the
name Prolog is used in the Prolog FAQ.
> Nobody denies that Turbo `Prolog' and Prolog are both members of *some*
> family of programming languages, just as Fortran, Algol 60/W/68, Pascal,
> PL/I, and Ada are all members of *some* family of programming languages.
Check the Prolog FAQ, as it includes PDC Prolog without suggesting
that PDC Prolog is _not_ Prolog. It merely makes a reference to the
typing used in PDC Prolog.
> The key point is the *cost* of moving between one member of a "family"
> and another. You can move most Algol W programs to PL/I using _local_
> transformations. You cannot move Prolog programs to Turbo Prolog using
> _local_ transformations.
I don't see how the cost of moving code from one language or language
dialect to another defines what is or is not Prolog. The cost may be
significant to programmers wishing to avoid dependancies on one
implementation, but if that was enough for a language definition, then
we might just as easily say that VC++ is not C++, simply because most
code written with VC++ will be substantially non-standard. The sad
truth is not that very few programmers using VC++ will care, even if
they do understand what you're saying.
Richard, you seem to be missing an important point here, dispite
the number of times I've made it, which is that not all programmers
will need to move code from one compiler to another. For a platform
like Windows, there may even be more important issues, like what kind
of OS support is provided, how well the IDE supports ActiveX
tools, etc.
> As far as I am concerned, there is no _theoretical_ point here of the
> kind that Cyber Surfer is demanding. It is simply that the differences
> between Turbo Prolog and Prolog have crossed the threshold where if you
> have an existing body of code, it is cheaper to buy a "Professional
> Prolog" from _any_ other vendor than to use a _free_ copy of Turbo Prolog.
Unless that "Professional Prolog" fails to support some important
platform dependant feature that you need. This is just one reason why
VC++ is more popular for Windows development than, say GNU C++. It's
not because of any failing of the compiler itself to support the
language - it just doesn't provide all the extras that allows it to
compete in terms of rapid Windows development. There's nothing unique
about Prolog that makes it an exception to this, apart from the fact
that most Windows developers probably don't even know that Prolog
exists, never mind that compilers are available for Windows.
I think that we agree on a lot of things discussed here, but we may
disagree about the significance of code compatibility. If you can't
afford more than one compiler, if you need to add all that cosmetic
GUI features to your apps, and if you have to get it done _yesterday_,
then code compatibility be as critical. It might not even be your
problem! I know this is an unprofessional attitude, but it can be
found here and there. It could be the price of the high demand for
productive programmers, or the poor understanding that some managers
have for development issues.
All I know is that I've yet to find a good argument against a Windows
developer using PDC Prolog, instead of a more standard Prolog. This is
why I mentioned VC++ vs GNU C++ above. If porting code was more
important than using platform dependant features, then I wouldn't
hesitate to choose GNU C++.
This should tell you a lot about the state of Windows software...
Richard A. O'Keefe
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>With a mighty <3304DD...@rlsclare.agw.bt.co.uk>,
>herr...@rlsclare.agw.bt.co.uk wibbled into the void...
Does the verb "to wibble" have any definite meaning?
It _looks_ pretty offensive.
>I wouldn't know about ANSI Prolog, but I recall something about an ISO
>Prolog. I'm sure Richard O'Keefe knows more about it, as I also recall
>that he used to be on the committee. Unless I'm misremembering
>something, he may be able to tell you something about it.
(a) There is indeed an ISO Prolog standard.
(b) I have never been on the committee. I was at one time invited to
take part, but RMIT refused to donate any of my time without
reimbursement.
(c) I have tried to be to ISO Prolog what Noam Chomsky has been to
United States government.
(d) The result is actually better than I ever dared to hope.
(e) It _should_ have been a lot better and five years earlier.
I actually tried to drum up interest in a Prolog standard before the
BSI got into the act. My reason was that there were companies that
would not buy any computer language system that didn't have a standard,
and my experience of trying to port Prolog code between allegedly
compatible systems.
Who cares about compatibility? Well, if you are trying to sell a
Fortran compiler to someone who _already_ has Fortran code they want
to run, you aren't going to make the sale if you are too incompatible
with what they think Fortran is. (And this means that you have to be
compatible with extensions to and misreadings of the standard as well
as the standard.) If you are trying to sell a C++ compiler to me, it
had better be able to compile the STL.
So the people selling compilers for established languages care because
their customers care. I don't care whether Visual Basic is Visual or
Olfactory, nor whether it's Basic or Swahili, because I haven't got any
Basic code that I want to port, and if I want to interface to Windows,
I'll use LPA WinProlog, or a C++ compiler. I _do_ care whether Visual
C++ is compatible with other C++ systems because I have C++ code that
I'd like to use.
Cyber Surfer
With a mighty <5e8omr$cv1$1...@goanna.cs.rmit.edu.au>,
o...@goanna.cs.rmit.edu.au wibbled into the void...
> So the people selling compilers for established languages care because
> their customers care. I don't care whether Visual Basic is Visual or
> Olfactory, nor whether it's Basic or Swahili, because I haven't got any
> Basic code that I want to port, and if I want to interface to Windows,
> I'll use LPA WinProlog, or a C++ compiler. I _do_ care whether Visual
> C++ is compatible with other C++ systems because I have C++ code that
> I'd like to use.
I didn't say that nobody cares about code compatibility. I've ported
enough C code from one compiler to another to appreciate this. I'm
just pointing out that not everyone will have this appreciation. For
example, a large number of Windows programmers will be locked into a
single compiler, even if they do use C++.
Just a brief look at the features that VC++ adds to C++ should
convince you that at the very least MS are happy to extend the
language in dumb ways. I doubt that many VC++ users are resisting
these features, either. Not that this should matter to anyone...
I feel the same way that you do (or close enough) about language
standards. I'm merely saying that not everyone shares these feelings.
Everything else is just a detail. That may be why so many developers
either don't care, or can't afford to care. When your code is platform
dependant, and most of the support is for a single compiler, what
choice is there?
That doesn't explain PDC Prolog, of course. How does it continue to
sell? I seem to recall PDC claiming that they over 300K installations.
Presumably these people aren't that worried about compatibility with
ISO Prolog. I guess that they're not porting much code.
I doubt that we have much more to say about this. In fact, we've
probably been repeating ourselves for some time now...
Richard A. O'Keefe
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>Richard, you seem to be missing an important point here, dispite
>the number of times I've made it, which is that not all programmers
>will need to move code from one compiler to another.
No, I have *NOT* missed this point.
The point is that your point is quite irrelevant.
For the people who *don't* care about compatibility,
the names don't matter either.
All you are saying, in effect, is that there are
people who are simply not relevant to this argument.
>For a platform
>like Windows, there may even be more important issues, like what kind
>of OS support is provided, how well the IDE supports ActiveX
>tools, etc.
Yes. Of course. Everrybody agrees with that.
And if _platform_ compatibility for new code is more important
to you than anything else, you DO care whether the thing is
called "Windows <something>" and you DON'T care whether the thing
is called "<platform> Prolog".
Indeed, I must thank you for the opportunity to reinforce my point
using your example. If OS support, ActiveX, &c is important to you,
then you will feel VERY unhappy if you buy "Windows Snatchum" and
find that it is a Snatchum system that is perfectly compatible with
"Macintosh Snatchum" but has no Windows support at all.
A product name should not falsely imply fitness for use on a particular
platform.
- people who don't _care_ about the platform don't _care_ about
that part of the name; people who _do_ care should not be deceived.
A product name should not falsely imply membership in a family of
compatible systems (be it programming language processors, terminal
emulators, Web browsers, or whatever).
- people who don't _care_ about compatibility with other members
of the family don't _care_ about that part of the name, people
who _do_ care should not be deceived.
Your argument basically boils down to "because there are people who
don't care, it is perfectly ok if the people who _do_ care are deceived."
>> As far as I am concerned, there is no _theoretical_ point here of the
>> kind that Cyber Surfer is demanding. It is simply that the differences
>> between Turbo Prolog and Prolog have crossed the threshold where if you
>> have an existing body of code, it is cheaper to buy a "Professional
>> Prolog" from _any_ other vendor than to use a _free_ copy of Turbo Prolog.
>Unless that "Professional Prolog" fails to support some important
>platform dependant feature that you need.
But with respect to modern Prolog systems running under Windows,
THERE IS NO SUCH FEATURE. Some features are supported directly,
other features through the foreign interface. Let me say this
plainly with respect to the one modern Prolog system for Windows (Win32)
that I have looked at:
there is *NO* feature of Windows that can be accessed from C
that cannot be accessed from LPA WinProlog.
In the same way, there is *NO* feature of UNIX that cannot be conveniently
accessed from a good modern UNIX Prolog.
In 1989, when I was using a PC to do some writing, I had a C compiler
and LPA Prolog for DOS. I found it easier to do DOS stuff from LPA Prolog
than from C, and I was then an experienced C programmer. LPA are smart
enough to know when they have a selling-point worth preserving! So are
the other surviving Prolog-for-PC vendors.
You know, I get the overwhelming impression that CyberSurver has never
actually _used_ a modern PC Prolog.
>I think that we agree on a lot of things discussed here, but we may
>disagree about the significance of code compatibility.
I have never suggested in any way shape or form that compatibility is
important to _everyone_, although I would point out that one _does_
care about compatibility between release N and release N+1 of one's
dominatrix. (Anyone who has used Turbo Pascal for a while knows what
I am talking about.) What I _have_ argued is that the people who _do_
care about compatibility ought not to be deceived just because there
are some people who don't.
>All I know is that I've yet to find a good argument against a Windows
>developer using PDC Prolog, instead of a more standard Prolog.
Hasn't everyone in this thread explicitly said that a PC developer
might very well find PDC Prolog to be the right tool? I know _I_ have.
I'm pretty sure Fergus Henderson did. *Nobody* has been saying that
PDC Prolog is *useless*, only that it shouldn't have been called Prolog.
I _have_ argued that a Windows developer would be just as well served
by "a more standard Prolog" like LPA WinProlog. There is nothing in
the _incompatibilities_ of PDC Prolog that in any way make it _better_
than "more standard Prolog". And of course, if you use any of the
Windows-integration features of LPA Prolog, you are promptly locked into
the Windows platform.
However, I note that
- the R system is available for UNIX, Windows, and Macintosh
- the Xlisp-Stat system is available for UNIX, Windows, and Macintosh
- the Scheme system from Rice is available for UNIX and Windows (I
don't know about Macintosh)
- Mosaic and Netscape are available for UNIX, Windows, and Macintosh
- Java is available for UNIX, Windows, and Macintosh
- there are a couple of C windowing libraries that offer cross-
platform compatibility; I've got one of them that I paid for
- GNAT (the Ada compiler from ACT) is available for UNIX, Macintosh,
and Windows, and there are full POSIX bindings and full Windows
bindings (I _believe_ there are full Toolbox/OS bindings for the Mac)
- VisualWorks is cross-platform
...
It's amazing just how much of a program _can_ be cross-platform if you
want it to be.
Richard A. O'Keefe
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>How about the various entries in the comp.lang.prolog FAQ?
Who you think think _writes_ the FAQ entries?
If someone wants to advertise their system in the FAQ, they send in
an entry, and it goes in. The implication that PDC Prolog is a
"prolog" is once again due solely to PDC, _not_ to the maintainer
of the FAQ.
>As I've pointed out to Richard several times, incompatible
>is not always a problem.
Did you think Richard didn't notice?
Let's take another language, just to cool things down a bit.
If I am writing code for R, which I currently am, I don't _care_
whether it will run under S or not, because I haven't got S and
can't afford it. But since the only description of the language
that I have is the S textbook, I _do_ care that the R system is
compatible with the S textbook, and will until the R textbook
comes out.
If you have old code for language X,
compatibility with X _implementations_ is extremely important.
If you are writing new code, but all the good textbooks are for
language X (not ```dialect' Y),
compatibility with X _reference material_ is extremely important.
If you are writing new code,
and there is enough good reference material for the new system,
but language X programmers are easier to find
than dialect Y programmers, or you are a language X programmer
yourself,
compatibility with language X _programmers_ is extremely important.
If you are writing new code,
and there is enough good reference material for the new system,
and you have no programmers who know language X better than
dialect Y,
then you can ignore compatibility. Maybe.
Note that I am not saying that compatibility is of *overriding*
importance. If I wanted to write top-speed reliable numerics
code, I would give very serious consideration to SISAL and NESL,
though they aren't _and do not pretend to be_ compatible with
anything else. I am aware of their good performance, clarity,
and productivity advantages, and will cheerfully pay the
"incompatibility price", namely the weeks of playing with these
languages it would take me to become _good_ at them and used to
the implementations.
But you must remember that when PDC Prolog came out,
- there _was_ old code for Prolog (the public domain Prolog library,
plus a lot of other stuff then held at the Stanford repository)
- there were several Prolog textbooks but NO Turbo Prolog books
(and the Turbo Prolog manual was seriously defective).
In fact I _still_ haven't seen any good Turbo Prolog books.
- there were _no_ programmers used to Turbo Prolog and there _were_
quite a few used to "Edinburgh Prolog"
- there were several other _good_ Prologs for the PC that _were_
compatible with other Prologs and _did_ offer reasonable integration
with DOS, from LPA, Expert Systems, ALS, and others.
The chief advantage of Turbo Prolog was that it was "logic programming
for Pascal programmers", i.e. for people who _didn't_ have a background
in Prolog and how to do things in Prolog. For people who _did_ have a
background in Prolog, it was an extremely frustrating language, because
the obvious way to do things seldom if ever worked.
On the other hand, there was Trilogy, which was also a logic programming
language with an interesting type system that offered good DOS integration.
(In my view, Trilogy had _better_ DOS support than the first marketed
version of Turbo Prolog, and if only Trilogy had had Borland money behind
it things might be very different today.) Trilogy even managed to be a
_better_ (= purer) logic programming language in some ways than Prolog.
(Shades of Mercury...) At the time, my view was that anyone who wanted
a typed logic programming language would be mad to use Turbo Prolog when
Trilogy was available. I _wish_ Trilogy was still being developed and
marketed. It deserved to succeed. Why not? Marketing. It's conceivable
that Voda's honesty in _not_ calling his product "Tri-Prolog" contributed
to its demise.
I think CyberSurfer has misunderstood the nature of my argument.
My argument goes like this:
- people infer compatiblity from names
- compatibility often _does_ matter
- people who _don't_ care about compatibility
have no reason to care about names
- therefore names should not falsely imply a degree of compatibility
that does not exist
*ALL* language is contextual; *ALL* linguistic implications are defeasible.
The degree to which the name of a new product will suggest compatibility
with old ones depends on the degree to which similarity of name has been
correlated with compatibility of product in the past. For Fortran, COBOL,
and Ada, this correlation has been very high. For BASIC this correlation
has been very low. I didn't expect "SC-BASIC", which I picked up for my
Macintosh, to be very compatible with anything else much, and by Jove it
isn't. (Although it looks to me as though Crimson are trying to build a
Macintosh clone of Visual Basic. Maybe it _will_ be compatible by the
time they start selling their product.) At the time PDC Prolog was
introduced,
- there was a "de facto standard" (Clocksin & Mellish)
- other "Prolog" systems on the market largely conformed to it
- there was an official Prolog standard under development
all of which meant that Prolog was closer to the Fortran sort of
correlation than the BASIC sort.
I did post a reply to another of Cyber Surfer's messages, which reply
seems to have been lost. In that reply I said that I *had* taken legal
advice about whether anything could be done and the answer was no.
Had anyone ever written to Borland asking if their product was C&M
compatible, or "Edinburgh" compatible, and had Borland ever written
back saying yes, _then_ the purchaser would have had a legal remedy,
but since Borland never made any explicit false claim, no remedy exists.
Richard A. O'Keefe
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>That doesn't explain PDC Prolog, of course. How does it continue to
>sell? I seem to recall PDC claiming that they over 300K installations.
>Presumably these people aren't that worried about compatibility with
>ISO Prolog. I guess that they're not porting much code.
(a) Ever heard the term "shelfware"?
I know of several copies of Turbo Prolog that became instant shelfware.
It would be very interesting to see a table of programming language
systems sold with the proportion of each that ever saw serious use.
(b) Can you say whether this figure includes sales under Borland, or
whether it is only sales since the split? If the latter, it's
amazing, and they should be congratulated. If it's the former,
bear in mind the price. Many Prolog systems were priced so that
only people who were already committed to using the language
bought them. Turbo Prolog was priced so that Americans could by
a copy with lunch money. That has to make a difference.
(c) Do they have 300K _installations_, or have they made 300K _sales_?
Given the number of revisions that Turbo/PDC/Visual Prolog has
gone through (driven in no small part by the number of revisions
that DOS/Windows has gone through), it is easily imaginable that
300K _sales_ could correspond to only 100K satisfied customers
(which would still be impressive).
(d) It is rubbish to say that PDC Prolog users are not porting code.
Turbo Prolog came out before Windows. People used it to write
DOS programs. Then Windows 3.1 came out. Moving from DOS to
Windows 3.1 was *porting*. Then Windows NT and Windows 95 came
out, and again that move was *porting*. (I imagine CyberSurfer
has been around long enough to remember some of the problems
with porting C or C++ code from Win16 to Win32, and he may even
be aware of some of the nastier differences between Windows 95
and Windows NT. I sometimes read out some of these differences
to colleagues, who fall about laughing, think for a bit, and
then look shocked.)
(e) In fact, for people who bought PDC Prolog back in the old DOS days
and are still using it, compatiblity _is_ an issue. They are
sticking with PDC Prolog instead of switching to LPA WinProlog
precisely *because* compatibility is important to them. They
have to port to a different operating system, and don't want to
change languages at the same time. In the same way, a lot of
people upgraded from Borland Pascal to Delphi, instead of
switching to say Prospero Pascal (which is compatible with the
Pascal Extended standard and is said to offer very good Windows
interfacing), precisely because compatibility _is_ an issue for
them now, although it wasn't when they bought Turbo Pascal years
ago. If compatibility _wasn't_ an issue, PDC would sell few
upgrades.
If the only thing that mattered was Windows integration, you'd
have a lot of people leaping from VC++ to Delphi or vice versa.
Clearly, compatibility with the source code they _now_ have _is_
a major issue for many Windows developers. If you are starting
to write new code, you don't _care_ that Delphi is not compatible
with the VC++ dialect of C++, so you can make your decision based
on other features. Once you _have_ some Delphi code, you will
want to upgrade to the next release of Delphi, rather than switch
to VC++ (similar in many ways though the two languages are).