On Oct 8, 3:26 pm, "John Thingstad" <jpth> wrote:
> På Wed, 08 Oct 2008 15:12:04 +0200, skrev Pascal Costanza <p>:
>>
>>
>>
>
> Or more succinctly "Are functions first order objects?"

On Oct 8, 3:26 pm, "John Thingstad" <jpth> wrote:
> På Wed, 08 Oct 2008 15:12:04 +0200, skrev Pascal Costanza <p>:
>>
>>
>>
>
> Or more succinctly "Are functions first order objects?"
What functions? There are only facts and rules. Or rules only if you
take facts as rules without a body.
Why not:
(defrule related (Relation X Y)
(Relation X Y))

>(related Father john X)
tim
>(related GrandFather john X)
Marc

>
> --------------
> John Thingstad- Hide quoted text -
>
> - Show quoted text -
[..]

On Oct 8, 3:30 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Slobodan Blazeski <slobodanblaze> writes:
>>
>>
> If it has sexps and macros (in addition to first order functions), you
> could call it a lisp.
It's already based on sexps and it has first order Rules, functions do
not exist.
So if it has macros it still be lisp regardless that it works via
unification.
; Providing that deffact is not defined and we only have defrule with
syntax
; (defrule rule-name (arguments) body)
(defmacro deffact (Name &rest Args)
`(defrule ,Name (,@Args) t))
[..]

On Oct 8, 3:12 pm, Pascal Costanza <p> wrote:
> Slobodan Blazeski wrote:
>>
>>
>> Can you treat programs as data?
What do you have in mind ? Give me an example.
[..]

Slobodan Blazeski wrote:
[..]
> marc
>
> (defrule GrandFather (X Y)
> (father X Z)
> (father Z y))
>
> (GrandFather john X)
> marc
>
> Is the new language lisp or prolog?

This is a very vague question and is very hard to answer. The problem is
that there is no strict definition what is required to consider a
language an instance of the Lisp family. There are some elements that
many people seem to agree on are strictly necessary, but there are other
elements which are not so clear.

For example, it has been debated before whether Scheme is actually a
Lisp or not. (Some say it isn't.) On the other hand, some consider Dylan
an acceptable representative of the Lisp family, although it doesn't
even have an s-expression-based surface syntax.

Such questions are very similar to questions like: Is a chair with three
legs still a chair? What about a chair with two legs? Is the importance
in the function of the chair ("if you can sit on it, it's a chair"), or
is the importance of certain aspects of its appearance ("normally four
legs").

There are philosophical questions behind this: Do you believe in
idealized definitions of entities or concepts, of which concrete
entities are just flawed instances? Or do you believe that the
categories we use are just social constructs that we happen to agree on
for some possibly accidental reasons? Or do you have any other of the
possible views on epistemology? Depending on your view, you will have
different opinions in such matters.


Pascal

Slobodan Blazeski <slobodan.blazeski> writes:

> On Oct 8, 3:30 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> It's already based on sexps and it has first order Rules, functions do
> not exist.
> So if it has macros it still be lisp regardless that it works via
> unification.
> ; Providing that deffact is not defined and we only have defrule with
> syntax
> ; (defrule rule-name (arguments) body)
> (defmacro deffact (Name &rest Args)
> `(defrule ,Name (,@Args) t))

What does that mean?
You said it had only defrule.
How do you expression ` and , in terms of rules?

You're saying that it as sexps.
What are the rules that you can apply on sexps?
Anything useful inside macros to build further rules?

On Oct 8, 4:35 pm, Pascal Costanza <p> wrote:
[..]
> is the importance of certain aspects of its appearance ("normally four
> legs").
>
> There are philosophical questions behind this: Do you believe in
> idealized definitions of entities or concepts, of which concrete
> entities are just flawed instances? Or do you believe that the
> categories we use are just social constructs that we happen to agree on
> for some possibly accidental reasons? Or do you have any other of the
> possible views on epistemology? Depending on your view, you will have
> different opinions in such matters.
Yeah, that's why I asked for an opinion. As for myself I wouldn't call
it a lisp. Maybe some lisp cousin but definately not lisp.

thanks to everybody for their thoughts

bobi
[..]

Slobodan Blazeski wrote:
> On Oct 8, 3:26 pm, "John Thingstad" <jpth> wrote:
>>
> On Oct 8, 3:26 pm, "John Thingstad" <jpth> wrote:
>> What functions? There are only facts and rules. Or rules only if you
> take facts as rules without a body.
> Why not:
> (defrule related (Relation X Y)
> (Relation X Y))

Omigod, you are serious? About Prolog?!!!! Have you ever programmed
Prolog in anger? I think if you had picked C you would have a better
chance of making the case (but still would fall short). But unification???

I think the closest you could get would be to add lispy qualities to
prolog (macros, first-order rules closing over facts -- which would be
cool because it would make prolog even more impossible to code and I did
not think that was possible) but with an ineluctable paradigm like
unification it can never be anything other than prolog. I would accept
it being called Prolisp for taking the trouble to copy all the right
features, but that's as close as it can get.

my2,kxo

On Oct 8, 4:41 pm, Kenny <kentil> wrote:
[..]
>>
>>
>
> Omigod, you are serious? About Prolog?!!!! Have you ever programmed
> Prolog in anger? I think if you had picked C you would have a better
> chance of making the case (but still would fall short). But unification???
Alone, I would always pick lisp. But what if you don't have to choose.
Use unification for whatever it does best. Let it take care of
relations of non-table databases.
(mapcar #'Grandfather '(X Y tim) '(john Z ron)) . Dispatch via
pattern matching whenever you feel its appropriate.
(method fib (#'negative-p) (error "Positive numbers only"))
(method fib (1) 0)
(method fib (N) (+ (fib (1- N)) (fib (- N 2))))
You need arrrays ops containers. Use the apl/j/k subsystem.
(+ (vector 1 2 3) 1) => (vector 2 3 4)
You want to project, no problem just fix the argument you want.
And finally mix and match all the above as you please without leaving
the comfort of s-expressions and our beloved lisp.

One language to rule them all :)

cheers
bobi
[..]

På Wed, 08 Oct 2008 16:41:04 +0200, skrev Kenny <kentilton>:

>
> Omigod, you are serious? About Prolog?!!!! Have you ever programmed
> Prolog in anger? I think if you had picked C you would have a better
> chance of making the case (but still would fall short). But
> unification???
>
> I think the closest you could get would be to add lispy qualities to
> prolog (macros, first-order rules closing over facts -- which would be
> cool because it would make prolog even more impossible to code and I did
> not think that was possible) but with an ineluctable paradigm like
> unification it can never be anything other than prolog. I would accept
> it being called Prolisp for taking the trouble to copy all the right
> features, but that's as close as it can get.
>
> my2,kxo

In all fairness Prolog is not impossible to program, just difficult to
learn. Kinda like putting your head in a food processor and pressing
blend.. Still after a couple a years people have been known to do useful
things with it.

--------------
John Thingstad

>>>What functions? There are only facts and rules. Or rules only if you
>>>take facts as rules without a body.
>>>Why not:
>>>(defrule related (Relation X Y)
>>> (Relation X Y))
>>
>>Omigod, you are serious? About Prolog?!!!! Have you ever programmed
>>Prolog in anger? I think if you had picked C you would have a better
>>chance of making the case (but still would fall short). But unification???
>
> Alone, I would always pick lisp. But what if you don't have to choose.

I would think, "Omigod! I have been time-transported back to early 2008
when I was using Franz's nice co-mingling of CL with Norvig's
Prolog-In-Lisp!!!!!"

You may be amused to learn I did in fact generate Prolog rules
programmatically /and/ tune the resulting larger scripts by de-duping
and re-ordering programmatically -- the larger scripts got generated
piecemeal and assembled into a larger form in no particular order, which
led to some howlers efficiency-wise--all by treating the Prolog as data.

Costanza will be along shortly to show how that can be done with after
methods in CLOS, but I do not mind learning new tools....hell, I am the
Mongo of technology: "No, no, no. Don't give him a tool he does not
know. It only makes him code faster."

hth,kt

John Thingstad wrote:
> På Wed, 08 Oct 2008 16:41:04 +0200, skrev Kenny <kentilton>:
>>
> In all fairness Prolog is not impossible to program, just difficult to
> learn. Kinda like putting your head in a food processor and pressing
> blend.. Still after a couple a years people have been known to do
> useful things with it.

No, I went pretty far with it. You can just look at the prolog classics
and see the language is unprogrammable. The key is how hard it is to do
the simple stuff. Occam's razor applies: why kill yourself doing
everything with unification when multi-paradigm languages are around?

Anyone productive I am sure has Greenspunned procedural forms out of
Prolog, which only proves my point.

my2,kzo

On Oct 8, 11:02 am, Kenny <kentil> wrote:

> I am not having any problems with CL, so I do not look around much.

Have you seen this?

http://groups.google.com/group/cloju...9d1489c167ca67

(Not that you need it, I've heard there is a similar library for CL.)

Pascal J. Bourguignon wrote:
> D Herring <dherring> writes:
>
>> I still think the inability to *purely* (i.e. without
>> function trampolines or reader macros) rename (or alias) a symbol is a
>> defect in CL.
>
> (define-symbol-macro new-name old-name)
>
> (let ((old-name 42))
> new-name)
>
> --> 42

Thanks Pascal. I'll need to reevaluate my thoughts on this topic.

- Daniel

On Tue, 07 Oct 2008 23:27:06 -0700, Scott Burson wrote:

> On Oct 7, 9:02 pm, D Herring <dherr> wrote:
>
> Thanks for the plug!! BTW I am diligently working on the 1.2 release of
> FSet, which along with (koff koff) bug fixes and some new features will
> finally have a proper tutorial.
>
> Also -- your first sentence risks being misinterpreted as suggesting
> that FSet was in some way inspired by Clojure, which is not the case.
> FSet was very much inspired by Refine (hmm, I see there's no Wikipedia
> page on Refine... must remedy that) which was in turn inspired by SetL.
>
> -- Scott



I have watched fset with some interest. Two things that Rich always
highlights about clojure is the large amount of structure "changed"
collections share, and the shallowness of the implementation trees to
ensure fast lookups (O(log32N) for vectors).

How do you think fset compares?

Matt

On Oct 8, 10:42 pm, Matthew D Swank <akopagmanepos>
wrote:
> I have watched fset with some interest.  Two things that Rich always
> highlights about clojure is the large amount of structure "changed"
> collections share, and the shallowness of the implementation trees to
> ensure fast lookups (O(log32N) for vectors).
>
> How do you think fset compares?

I haven't looked closely at Clojure yet, but I can offer the
following.

First off, I would point out that it doesn't really make sense to
supply the base of the logarithm in "O(log n)". Changing the base of
the logarithm simply changes the value by a constant factor, and big-O
notation ignores constant factors. Still, I do understand what he's
saying -- he's using very wide nodes to keep the trees shallow, which
does reduce the cost of indexing by a constant factor compared to
simple binary trees.

Second, obviously that improvement applies only to sequence indexing;
it doesn't help access to the setlike types (sets, maps, and bags).
For the latter, you would still have to do a binary search on the root
node to figure out which subnode to look at, etc., and the comparison
time swamps the time to dereference a pointer. So for the setlike
types, you may as well use a binary tree.

Third, FSet takes a different approach to reducing the tree depth vis-
a-vis simple, homogeneous binary trees. While my nodes are binary, I
use a heterogeneous structure where the leaves are short vectors
(whose length is bounded to 8 normally). So, if D is the depth of a
simple binary tree, the depth of the same tree in Clojure is going to
be about D/5, and in FSet it will be about D-3 (well, between D-2 and
D-3). But I really do this to save space, not so much to save time.

Fourth, I think that random access into a sequence is not that common
a use case (though it does arise, obviously). Iterating over it is
probably more common. I put a fair amount of work into fast iterators
for FSet that give amortized constant time access to each element.

Fifth, I would be concerned that using very wide nodes might make
updates of small collections a lot more expensive. This would be
interesting to measure. Maybe it's not a big deal.

And finally, I expect FSet could be improved further. For instance, I
have seen a paper claiming that functional red/black trees have better
rebalancing performance than the weight-balanced trees I used. (Of
course, rebalancing is an issue only in update, not in access.)

-- Scott