·······················@gmail.com 寫道：
> Actually this depends on the compiler.
>
> Free Pascal compiler is very capable of cross-compiling easely, so no
> Virtual Machine is needed for bootstraping.
No , no needed. Nor is Warren's Abstract Machine needed for building
prolog. An elegant example is seen in Paul Graham's out standing book
<<On Lisp>> ( http://www.paulgraham.com/lib/paulgraham/onlisp.pdf).
>
> You just need to implement a new Runtime library for the new target,
Yes, as John Doty said : "Somehow you need to get down to the
hardware, so somebody needs to code up some way to generate
machine code for the machine in question ."
And this "somehow" needs not to be C/C++. For pascal , it can be
pascal . For prolog , it should be possible to be prolog.
> cross-compile the compiler for the target and that's it =)
>
> Now the newly produced compiler can compile itself and other pascal
> projects.
On 1 May 2006 16:11:02 -0700
··········@bbs.ee.ncu.edu.tw wrote:
> And this "somehow" needs not to be C/C++. For pascal , it can be
> pascal . For prolog , it should be possible to be prolog.
>
Umn, why? At the machine layer there's not gonna be much
difference, so once someone goes thru the trouble in C, there's
not much real value in "pure" X, Y or Z.
Dhu
--
???????????????????????????????????????
Open Systems Integration
Contact Fubar the Hack: fubar AT neotext.ca
Area code seven eight zero, Exchange four six six, Local zero one zero nine
Highland terms, Canadian workmanship.
All persons named herein are purely fictional victims
of the Canidian Bagle Breeder's Association.
Save the Bagle!
Sun Dhu
???????????????????????????????????????
Duncan Patton <········@neotext.ca> writes:
> On 1 May 2006 16:11:02 -0700
> ··········@bbs.ee.ncu.edu.tw wrote:
>
>> And this "somehow" needs not to be C/C++. For pascal , it can be
>> pascal . For prolog , it should be possible to be prolog.
>>
>
> Umn, why? At the machine layer there's not gonna be much
> difference, so once someone goes thru the trouble in C, there's
> not much real value in "pure" X, Y or Z.
I was hoping to stay out of this, especially since it is crossposted.
I don't know particulars about prolog-in-prolog implementation (we
do have a prolog, very fast, implemented in Allegro CL, but that's
another story). But though Prolog may not have special needs not
easily satisfied by C, Lisp, and especially Common Lisp, certainly
does. I wrote about it many years ago on c.l.l and I present it
here for your consideration. It should answer your question "why?"
(as in "why bother implementing language-X in language-X?").
http://groups.google.com/group/comp.lang.lisp/msg/96d32a463068044e
You can look at the whole thread by selecting the "show options"
link and selecting "View Thread".
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Mon, 01 May 2006 23:46:54 -0700
Duane Rettig <·····@franz.com> wrote:
> Duncan Patton <········@neotext.ca> writes:
>
> > On 1 May 2006 16:11:02 -0700
> > ··········@bbs.ee.ncu.edu.tw wrote:
> >
> >> And this "somehow" needs not to be C/C++. For pascal , it can be
> >> pascal . For prolog , it should be possible to be prolog.
> >>
> >
> > Umn, why? At the machine layer there's not gonna be much
> > difference, so once someone goes thru the trouble in C, there's
> > not much real value in "pure" X, Y or Z.
>
> I was hoping to stay out of this, especially since it is crossposted.
> I don't know particulars about prolog-in-prolog implementation (we
> do have a prolog, very fast, implemented in Allegro CL, but that's
> another story). But though Prolog may not have special needs not
> easily satisfied by C, Lisp, and especially Common Lisp, certainly
> does. I wrote about it many years ago on c.l.l and I present it
> here for your consideration. It should answer your question "why?"
> (as in "why bother implementing language-X in language-X?").
>
Thanks. The question wasn't entirely rhetorical. There's another
answer that you might be aware of. I read/hear an anecdote of
John McCarthy's once (can't find it now) where he recalled one
of the comments brought up in his original lisp dissertation(?).
Somebody stood up and said, "Yah, but I could have done that
all in assembler". McCarthy says he came up with the _right_
answer some hours too late: "Yah, but you didn't."
Dhu (I probably got some of it wrong... would be nearly thirty ybp I read it).
> http://groups.google.com/group/comp.lang.lisp/msg/96d32a463068044e
>
> You can look at the whole thread by selecting the "show options"
> link and selecting "View Thread".
>
> --
> Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
> 555 12th St., Suite 1450 http://www.555citycenter.com/
> Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
--
???????????????????????????????????????
Open Systems Integration
Contact Fubar the Hack: fubar AT neotext.ca
Area code seven eight zero, Exchange four six six, Local zero one zero nine
Highland terms, Canadian workmanship.
All persons named herein are purely fictional victims
of the Canidian Bagle Breeder's Association.
Save the Bagle!
Sun Dhu
???????????????????????????????????????
Duncan Patton <········@neotext.ca> writes:
> On Mon, 01 May 2006 23:46:54 -0700
> Duane Rettig <·····@franz.com> wrote:
>
>> Duncan Patton <········@neotext.ca> writes:
>>
>> > On 1 May 2006 16:11:02 -0700
>> > ··········@bbs.ee.ncu.edu.tw wrote:
>> >
>> >> And this "somehow" needs not to be C/C++. For pascal , it can be
>> >> pascal . For prolog , it should be possible to be prolog.
>> >>
>> >
>> > Umn, why? At the machine layer there's not gonna be much
>> > difference, so once someone goes thru the trouble in C, there's
>> > not much real value in "pure" X, Y or Z.
>>
>> I was hoping to stay out of this, especially since it is crossposted.
>> I don't know particulars about prolog-in-prolog implementation (we
>> do have a prolog, very fast, implemented in Allegro CL, but that's
>> another story). But though Prolog may not have special needs not
>> easily satisfied by C, Lisp, and especially Common Lisp, certainly
>> does. I wrote about it many years ago on c.l.l and I present it
>> here for your consideration. It should answer your question "why?"
>> (as in "why bother implementing language-X in language-X?").
>>
>
> Thanks. The question wasn't entirely rhetorical.
That's why I answered it. I didn't view it as rhetorical at all.
> There's another
> answer that you might be aware of. I read/hear an anecdote of
> John McCarthy's once (can't find it now) where he recalled one
> of the comments brought up in his original lisp dissertation(?).
> Somebody stood up and said, "Yah, but I could have done that
> all in assembler". McCarthy says he came up with the _right_
> answer some hours too late: "Yah, but you didn't."
Don't remember seeing that, but it was likely just before the guy
actually implemented it...
The present attitude/memory of McCarthy, according to many of the recent
talks he's given at "ILC" (International Lisp Conference) events is that
he had originally intended Lisp not to be implemented at all; he thought
of it more as a mathematical calculus rather than a programming language
per se.
And yes, over the years, Lisp has been implemented in many different
languages. But that it it turing complete should be proof enough that
it can generate the streams of bits that make up a compiled program,
native or byte in nature. And once one writes a native assembler in
Lisp for the target architecture, it actually becomes more maintainable
than relying on underlying languages over which one has little or no
control, since the process is controlled all the way down to the bit
level, without the need for a linker, by the lisp itself.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> I don't know particulars about prolog-in-prolog implementation (we
> do have a prolog, very fast, implemented in Allegro CL
Since you deem it worth mentioning ... what is "very fast" ?
Cheers
Bart Demoen
Bart Demoen <···@cs.kuleuven.be> writes:
> Duane Rettig wrote:
>
>> I don't know particulars about prolog-in-prolog implementation (we
>> do have a prolog, very fast, implemented in Allegro CL
>
> Since you deem it worth mentioning ... what is "very fast" ?
I asked our prolog expert, and he said that there are things that we
optimize and things that we don't - it is perhaps a few tens of percent
faster than SWI Prolog on the "Zebra Puzzle", and there are probably
things that SWI Prolog does faster than ours.
My main reason for mentioning it was to tie the more general topic
of the thread with its title, and to note that Lisp is good for
implementing other languages efficiently as well as itself - a
revolutionary concept in a C-centered society where the concept is
that C is the only language that gets down to the metal...
You can try benchmarks yourself by getting the Trial Version of Allegro CL
(http://www.franz.com/downloads)
and trying it yourself. The zebra benchmark is at the end of the prolog
documentation:
http://www.franz.com/support/documentation/8.0/doc/prolog.html
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Mon, 08 May 2006 15:13:25 -0700, Duane Rettig <·····@franz.com>
wrote:
>Bart Demoen <···@cs.kuleuven.be> writes:
>
>> Duane Rettig wrote:
>>
>>> I don't know particulars about prolog-in-prolog implementation (we
>>> do have a prolog, very fast, implemented in Allegro CL
>>
>> Since you deem it worth mentioning ... what is "very fast" ?
>
>I asked our prolog expert, and he said that there are things that we
>optimize and things that we don't - it is perhaps a few tens of percent
>faster than SWI Prolog on the "Zebra Puzzle", and there are probably
>things that SWI Prolog does faster than ours.
>
>My main reason for mentioning it was to tie the more general topic
>of the thread with its title, and to note that Lisp is good for
>implementing other languages efficiently as well as itself - a
>revolutionary concept in a C-centered society where the concept is
>that C is the only language that gets down to the metal...
If we talk about ancient history, I remember huge algebraic
manipulation system named Forprep/Almap implemented in Fotran IV,
Fortran IV implemenetd in Fortran IV and system for industrial control
with a lot of interfacing to bare metal implemented in Fortran IV by
using COMMON and EQUIVALENCE in very creative way. I also remember
Prolog implemented in Fortran IV....
But then, so what?... Who cares?... Both are dead corpses.
A.L.
From: Pierpaolo BERNARDI
Subject: Re: Why Not Prolog in Prolog ?
Date:
Message-ID: <op.s9dfvdpwxbm8ci@eraora>
On Tue, 09 May 2006 00:13:25 +0200, Duane Rettig <·····@franz.com> wrote:
> Bart Demoen <···@cs.kuleuven.be> writes:
>
>> Duane Rettig wrote:
>>
>>> I don't know particulars about prolog-in-prolog implementation (we
>>> do have a prolog, very fast, implemented in Allegro CL
>>
>> Since you deem it worth mentioning ... what is "very fast" ?
>
> I asked our prolog expert, and he said that there are things that we
> optimize and things that we don't - it is perhaps a few tens of percent
> faster than SWI Prolog on the "Zebra Puzzle", and there are probably
> things that SWI Prolog does faster than ours.
I can confirm it's slightly faster than swi on a predicate
taken from a program of mine:
3 ?- time((ohm:fa_rete([1,2,3,4,5,6,7,8,9,10],A,B),fail)).
% 13,246,792 inferences, 6.23 CPU in 7.19 seconds (87% CPU, 2124799 Lips)
CL-USER(47): (time (?- (fa-rete (1 2 3 4 5 6 7 8 9 10) ?a ?b) (fail)))
No.
; cpu time (non-gc) 5,581 msec user, 16 msec system
; cpu time (gc) 716 msec user, 0 msec system
; cpu time (total) 6,297 msec user, 16 msec system
; real time 8,265 msec
; space allocation:
; 10,197 cons cells, 277,056,448 other bytes, 0 static bytes
The predicate tested is:
fa_rete(L,R,V) :-
append(L1,L2,L),
L1 \= [],
L2 \= [],
fa_rete(L1,R1,V1),
fa_rete(L2,R2,V2),
( R = ser(R1,R2),
V is V1+V2
; R = par(R1,R2),
V is (V1*V2)/(V1+V2)
).
fa_rete([Q],Q,Q).
(<-- (fa-rete ?l ?r ?v)
(append ?l1 ?l2 ?l)
(not (= ?l1 ()))
(not (= ?l2 ()))
(fa-rete ?l1 ?r1 ?v1)
(fa-rete ?l2 ?r2 ?v2)
(or (and (= ?r (ser ?r1 ?r2))
(is ?v (+ ?v1 ?v2)))
(and (= ?r (par ?r1 ?r2))
(is ?v (/ (+ (/ ?v1) (/ ?v2)))))))
(<- (fa-rete (?q) ?q ?q))
> My main reason for mentioning it was to tie the more general topic
> of the thread with its title, and to note that Lisp is good for
> implementing other languages efficiently as well as itself - a
> revolutionary concept in a C-centered society where the concept is
> that C is the only language that gets down to the metal...
I tested this predicate when your prolog was announced and I found
it was about half the speed of swi. The timings above, made today,
are with an up to date acl 7.0 trial on windows/x86, and latest swi.
Nice job (I know other prologs are much faster than swi, but still).
P.
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
From: Pierpaolo BERNARDI
Subject: Re: Why Not Prolog in Prolog ?
Date:
Message-ID: <op.s9dgs1apxbm8ci@eraora>
On Thu, 11 May 2006 07:22:47 +0200, Pierpaolo BERNARDI <·········@secondbox.net> wrote:
> On Tue, 09 May 2006 00:13:25 +0200, Duane Rettig <·····@franz.com> wrote:
>
>> Bart Demoen <···@cs.kuleuven.be> writes:
>>
>>> Duane Rettig wrote:
>>>
>>>> I don't know particulars about prolog-in-prolog implementation (we
>>>> do have a prolog, very fast, implemented in Allegro CL
>>>
>>> Since you deem it worth mentioning ... what is "very fast" ?
>>
>> I asked our prolog expert, and he said that there are things that we
>> optimize and things that we don't - it is perhaps a few tens of percent
>> faster than SWI Prolog on the "Zebra Puzzle", and there are probably
>> things that SWI Prolog does faster than ours.
>
> I can confirm it's slightly faster than swi on a predicate
> taken from a program of mine:
oops. I used floats for swi and rationals for franz.
And I looked at total time for franz instead or real time...
Anyway, using floats in both cases makes the two use about the same time:
5 ?- time((ohm:fa_rete([1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0],A,B),fail)).
% 13,246,754 inferences, 6.11 CPU in 7.03 seconds (87% CPU, 2168267 Lips)
CL-USER(51): (time (?- (fa-rete (1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0) ?a ?b) (fail)))
No.
; cpu time (non-gc) 4,454 msec user, 16 msec system
; cpu time (gc) 874 msec user, 0 msec system
; cpu time (total) 5,328 msec user, 16 msec system
; real time 7,437 msec
; space allocation:
; 10,191 cons cells, 313,925,120 other bytes, 0 static bytes
Cheers
P.
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php