Re: "dict"ionary typing?

Richard,

I'm afraid that is *my *misguided remark you quote in your email, rather
than Carlo's. I am most certainly out of my depth and I apologize if I
departed from the proper subject matter of the thread. That being said, I
*was* (within the limits of my ability) trying to think through the
semantics of functional syntax in this context. In particular, I wanted to
clarify what it is I/we want out of a functional syntax that gets expanded
to standard Prolog. Carlo, Michael, and yourself all seemed to be in accord
in this matter, and I too find it appealing.

What I was trying to suggest -- albeit with too much verbiage, too little
clarity, and, doubtless, too many errors -- was that Russell's concept of a
"descriptive function" might be a good fit here. To recap, '*father of x' *is
a *"*descriptive function" because it's meaning is an object, *y*, that
bears the relation 'father of' to *x*. Russell thought of mathematical
functions like '*sin x'* as a special case of descriptive functions.  In a
particular case, a descriptive function can be substituted for the value
that satisfies the implicit variable.  So, if I understand correctly, "the
father of Enoch slew Able" can be replaced with "there is something
*y*which is the father of Enoch and y slew Able"  i.e.,
'slew(father_of(enoch), able)' is equivalent to 'father_of(enoch, Y),
slew(Y, able)'. That seemed to agree with the approach you, Carlo, and
Michael had taken.

In this case, a the functional syntax is just shorthand for a shared
variable, which seems to me to leave the semantics quite clear (but I may
misunderstand the point here).

If you would be willing to oblige, I could use some clarification on your
remark about the relation between a "declaration based preprocessor" and
unadulterated runtime semantics. Supposing we have (using Ciao notation,
but we could use Michael's or Carlo's)

father_of(enoch, cain).
brother_of(able, cain).
uncle_of(Y, X) :- brother_of( ~father_of(Y),  X).

And the last clause gets expanded to

uncle_of(Y, X) :- father_of(Y, Z), brother_of(Y, X).

Is this for some reason detrimental to the runtime semantics in a way that
it wouldn't be if `father_of/2` were declared as you suggested?

father_of(enoch) -> cain :- true.

Or does the difficulty only arise when the [Guard] part of your example
comes into play?





On Sun, Dec 8, 2013 at 6:41 PM, Richard A. O'Keefe <[email protected]>wrote:

>
> On 7/12/2013, at 10:59 AM, Carlo Capelli wrote:
> > Insofar as functions are just ordered pairs of elements belonging to
> > certain domains, that is, insofar as they are thought of extensionally
> the
> > common representation,
>
> But this thread is not about extensionally defined mathematical
> functions, but about *computational* functions, indeed about
> using functional *syntax* for things that are not mathematical
> functions at all.
>
> What I am seeing here is depressingly common in programming.
> There's keenness to embrace a syntax, and bickering over the
> details of the syntax, and if we are very lucky indeed, after
> it is implemented, someone will try to figure out a semantics
> for it.
>
> We see things like XML where the definition of XML tangles up
> two different ideas of what a document _means_, the original
> RDF specification which was _meant_ to define RDF in terms of
> the _abstract_ syntax of XML but got the concrete syntax by
> mistake, and we saw it over and over and over in AI where
> someone would propose a new knowledge representation language
> but forget to say what it meant.
>
> There are clearly plenty of people who would like to have
> functional notation in Prolog, but can we get some discussion
> of how the *semantics* is supposed to work, in detail?
>
> The point of my declaration-based preprocessor was to
> ensure that the "functional" notation didn't have _any_
> consequences for the run time semantics, but I never wrote
> anything about it or released it because it wasn't clear
> to me that I had achieved my goal.
>
> With hindsight, I wish that instead of
>
>         Head = Expr [:- Guard]
>
> I had used Erlang-like
>
>         Head -> Expr [:- Guard]
>
> to make it clear that the semantics of (=)/2 was *not* supposed
> to be affected.
>
> Why do we want the semantics of (=)/2 to be unaffected?
> Well, do *you* want to work out the full details of the
> interaction between functional notation and CHR?
>
> Neither did I.
>
> (Functions in dicts have crossed my complexity threshold.)
>
>
-------------- next part --------------
HTML attachment scrubbed and removed