English Falcon docs

[Aule]

At various places we have "method overloading" when I think that the
example given is what in English jargon (GB and US) is termed "method
overriding"

In general, I think we use:

override - same param signature, alternate implementation across
classes or instances
overload - alternate param signatures in same object or class(es)

Example languages with documentation to confirm this: C#

I don't see a Falcon example of a strategy for providing overloaded
methods to an object (prototype) or to a class - that would make an
excellent demo example of leveraging functional to achieve an oop
feature.

[Paul Nema]

Your assertion on the definition of method overriding and overloading are correct.  I'll take a look through the current documents and make the appropriate changes.  Thanks for bringing this to our attention.

[Giancarlo Niccolai]

On 25 Ott, 23:42, Aule <grshipl...@gmail.com> wrote:
> At various places we have "method overloading" when I think that the
> example given is what in English jargon (GB and US) is termed "method
> overriding"
>

Thanks for the pointer; I think that Paul will take good care of the
fix.

>
> Example languages with documentation to confirm this: C#
>
> I don't see a Falcon example of a strategy for providing overloaded
> methods to an object (prototype) or to a class - that would make an
> excellent demo example of leveraging functional to achieve an oop
> feature.

I don't really understand this assertion. One characteristic of
functional programming is that of allowing arbitrary composition of
parameters, excluding particular constructs with fixed prototypes (cfr
LISP).

Falcon doesn't support "overloading" because it doesn't support method/
function signatures. It doesn't support signatures because it supports
arbitrary parameter composition, which is one of the things that makes
Falcon suitable for functional programming.

For example, you can compose a typical functional construct, as
"filter" with a method, to get pair members of a list:

class Pairer
counter = 0

function dofilter()
return ((++self.counter) % 2) == 0
end
end

l = filter( Pairer().dofilter, .[ 'a' 'b' 'c' 'd' 'e' 'f' ] )
inspect(l)

or set a functional construct as a part of a class method, like

class XFilter
elements = .[ 'a' 'b' 'c' 'd' 'e' 'f' ]
filterme = .[ filter .[ { o, elem => elem in o.elements} self ] ]
end

inspect( XFilter().filterme( .['a','z','c','v' ] ) )

Those operations are not possible (or not so easily composed) when
method signature distinguish different versions of a function. I can't
see how that would make Falcon more functional than this...

[Giancarlo Niccolai]

> Those operations are not possible (or not so easily composed) when
> method signature distinguish different versions of a function. I can't
> see how that would make Falcon more functional than this...

I forgot to underline a fact that may not be evident: in the case of
Pairer.dofilter(), when applied to filter, it works as it ignores a
parameter it receives. In the case of XFilter.filterme, it works as it
passes a parameter it doesn't declare to the inner codeblock. So, you
have two examples where method signatures would be in the way, and
would actually prevent this to work (unless tricked around).

[Robert Shiplett]

G

teh "example" idea for a structure mimicing overloaded slots

I think it is just my English

It is that MORE RESTRICTED feature of 'overloading' that is sometimes useful.

It is sometimes useful in logic programming to have that restriction
on 'signature'

A switch statement can be viewed in this way - or Falcon 'select'

In smallltalk such useful restrictions are sometimes implemented using
"double dispatch"

For example, in Oz it is one such 'restricted' paradigm

The example was not about extending Falcon, but showing the strength of Falcon

This is why I propose appraaoching logic programming with limited,
restricted features:
i) datalog-like behavior
2) ICON-like "data-backtracking" based on Succeed | Fail
3) Erlang-like restricted LP

Even falcon SELECT may permit imitating typed-LP as found in Mercury
and VP at pdc.dk

R

[Giancarlo Niccolai]

Il giorno 26/ott/09, alle ore 15:43, Robert Shiplett ha scritto:

>
> G
>
> teh "example" idea for a structure mimicing overloaded slots
>
> I think it is just my English
>
> It is that MORE RESTRICTED feature of 'overloading' that is
> sometimes useful.
>
> It is sometimes useful in logic programming to have that restriction
> on 'signature'
>
> A switch statement can be viewed in this way - or Falcon 'select'
>
> In smallltalk such useful restrictions are sometimes implemented using
> "double dispatch"
>
> For example, in Oz it is one such 'restricted' paradigm
>
> The example was not about extending Falcon, but showing the strength
> of Falcon
>
> This is why I propose appraaoching logic programming with limited,
> restricted features:
> i) datalog-like behavior
> 2) ICON-like "data-backtracking" based on Succeed | Fail
> 3) Erlang-like restricted LP
>
> Even falcon SELECT may permit imitating typed-LP as found in Mercury
> and VP at pdc.dk
>
> R
>

I was discussing about this topic with my fellows on the IRC channel
earlier today.

For sure, we don't need a "full logic programming paradigm", or in
other words, a logic programming that takes care of every aspects of
the language.

For example, as we got list-processing oriented functional
programming, we may well discard that part of logic programming used
to deal with lists (head/tail) a la Prolog.

Many logic programming languages were "pure", or, in NEED to solve any
problem via logic programming. Of course, this is not our aim. We want
an inference engine to solve rules (e.g. constraint programming, but
not just that), i.e. to solve PROBLEMS, not to DEAL WITH STRUCTURES.

We pretty know how to deal with structures in more efficient and not
less elegant ways than logic programming did.

So, as non-overloading non-signature method/functions is already a
part of the programming language specifications (and an important
part, that plays a role in what you can do with it), we can't use
normal functions to implement logic programming schemes that require
predicate prototyping.

Choices are mainly 3:
1) using function (actually, callables) for rules, and drop parameter
prototyping.
2) Introduce a new "rule" construct & keyword, where definition
signature plays a role.
3) Go for an hybrid solution, as, for example, a VM assisted library
based inference engine.

For example, tabular programming, with the plugs we're gonna add to
enable fuzzy logic flow control, uses this approach: data structures
are seen by the language as "other things" (tables are classes, and
rows are arrays), but special management of those object in the VM
allow to integrate the language flow with the specialized data
structure beyond the limit of pure library solutions. In the case of
tables, arrays coming from tables get properties reflected as table
columns, and get their size fixed and bound to the table order. Table
operations, as find, are integrated in the VM loop and could be
suspended and coroutine-swapped, or receive and fulfill pending
messages (message programming), for example.

So, although tables "seem" just classes, and "are" just classes at
language level. special care in the VM/meta language level allow to
use them beyond their library side aspect, reaching and integrating
other elements of the language.

So, solution 3, providing i.e. a Rule() class that would be specially
treated by the language, still being mainly a "class", can be a valid
solution as the other 2.

Now that we know what we can do, let's find the best way to do it.

Giancarlo.