> On 11 Aug, 10:57, Slobodan Blazeski gmail.com>
> wrote:
>
>
>
>
>

>> On Aug 11, 11:19 am, Mark Tarver ukonline.co.uk> wrote:

>

>>> On 11 Aug, 09:56, Slobodan Blazeski gmail.com>
>>> wrote:

>

>>>> What do you need to be able to integrate Qi type system in a
>>>> language?  I'm working on my language and still haven't decided about
>>>> type  system.  I would like to have a static checks, (if they are
>>>> optional) but the best from what I found ishttp://www.cs.utexas.edu/users/boyer/ftp/diss/akers.pdfthatcomes
>>>> with a huge price of flexibility that I'm not willing to pay. I looked
>>>> at your 10 cent typechecker but the functions defined there are
>>>> simple, edis' are heavily overloaded. For example even simple + could
>>>> be called, in array style:
>>>> (+ 2 '( 1 2 3))
>>>> (3 4 5)

>

>>>> (+ '(1 2 3) '(1 2 3))
>>>> (2 4 6)

>

>>>> (+ '(1 2) '((0 1) (2 3) (4 5)))
>>>> ((1 5) (2 6) (3 7))

>

>>>> Or they could be completely redefined or even removed at
>>>> runtime.Nothing prevents user to do things like below at runtime:
>>>> (def triple (x) (* 3 x))
>>>> triple
>>>> (remove triple '(x))
>>>> t

>

>>>>  Also there is even more transformation characters that are making the
>>>> problem.
>>>> (def add (x y z) (fold + x y z))
>>>> add
>>>> (+ 2 3 _) ; creates projection
>>>> (lambda (x) (add 2 3 x))

>

>>>> Is static typechecking possible in so volatile enviroment?

>

>>>> bobi

>

>>> Yes; what you have got is severe overloading; but its not a problem.
>>> There is nothing to stop you using several rules to express the type
>>> properties of one function.  Qi will use the one that fits the
>>> individual case using backtracking if needed.

>

>>> The argument against overloading is that, if you have many overloaded
>>> functions, type checking becomes slower because there is a roughly
>>> linear depreciation in performance wrt the number of rules you use.
>>> But Qi has handled complex type systems and it does work successfully
>>> because the underlying technology is so fast in human terms that it
>>> takes quite a few rules before you really notice the lag.

>

>>> If you avoid overloading, then you can follow the Qi design of placing
>>> type information about functions on a hash table as closures.  This
>>> effectively means that there is no depreciation wrt the number of
>>> system functions that the language contains.

>

>>> Mark

>

>> Could you please enlighten me a little bit more. As per my very
>> limited exposure to Haskell and MLs type inference works because
>> functions are defined at compile time and runtime is only using them.
>> Am I right? Edi carries the whole implementation with it all the time
>> and uses it to  create all the objects at the runtime. Building and
>> removing  functions at runtime via macros (called at runtime), other
>> functions, transformers, projections,weaving them is a normal way of
>> doing business.
>> Maybe a little comparation with a baker that plans to sell some of his
>> staff at the local fare.
>> Statically typed baker will decide what products to carry and premade
>> them. That's why his staff will be faster.
>> Edi type baker will make some products but also it  will bring it's
>> bakery with it, and  cook the meals on the spot, it takes longer but
>> the food is always hot.
>> Is it what you saying that I could statically check only the
>> prefabricated functions
>> bobi- Hide quoted text -

>

>> - Show quoted text -
>> edis' are heavily overloaded

>
> Is edis your language?

>
> OK; lets take the first two examples
>
> (+ 2 '( 1 2 3))
> (3 4 5)
>
> (+ '(1 2 3) '(1 2 3))
> (2 4 6)
>
> I take it that (+ 2 2) still works!  Hence there are three signatures
> that you can put in for +.
>
> (datatype plus
>
>     ___________________________________
>     + : (number --> number --> number);
>
>     ______________________________________
>     + : (number --> [number] --> [number]);
>
>     _______________________________________
>     + : ([number] --> [number] --> [number]);)
>
> However from your examples it looks like your + is not ad hoc
> overloaded but actually works over a recursive type composed of
> numbers or lists of numbers or lists of lists of numbers etc.  So what
> you need to do in order to capture the properties of this function is
> to define that recursive type.
>

>> Or they could be completely redefined or even removed at
>> runtime.

>
> Well type checking functions that are overwritten during runtime does
> pose problems for type integrity!  However it is still possible to
> maintain type integrity with this feature provided that the new
> function maintains the same type as the old one.  In this case you
> will want to invoke the type checker dynamically at run time.

>
> Mark- Hide quoted text -
>
> - Show quoted text -