Re: feature incompatibilities

["Daniel Yokomiso" <address@hidden>]

----- Original Message -----
From: "Michael Vanier" <mvanier@cs.caltech.edu>
To: <ll1-discuss@ai.mit.edu>
Sent: Monday, March 31, 2003 9:22 PM
Subject: feature incompatibilities


>
> It occurs to me that a lot of the current landscape of programming
> languages is determined by which language features don't play well
> together.  I can think of several of these incompatibilities:
>
> -- explicit pointer arithmetic and garbage collection
>
> -- strong static typing and reflection
>
> -- static typing and dynamic typing
>
> -- imperative programming and implicit lazy evaluation
>
> None of these is absolute.  For instance, there are (conservative) GCs for
> C/C++, java has strong(ish) static typing but also has reflection, Dylan,
> Curl and Common Lisp combine (to some extent) static and dynamic typing
> (and reflection), Haskell uses monads to get the effect of imperative
> programming, etc.  However, it seems like it's very hard if not impossible
> to have such feature pairs together in one language without compromising
> one or the other of the pair.  For instance, conservative GC is not
> guaranteed to be reliable.
>
> I think a lot of us dream of creating one language that could do
everything
> well, but I think the incompatibilities I listed above suggest that such a
> dream is misguided.  Can anyone think of other incompatibilities of this
> kind?  Any other opinions?
>
> Mike

Hi,

    We can use some constructs to go around some of these incompatibilities.
If we use CPS it's possible to define a reflection syntax based on
continuations on an "extended" type environment. Something like this:

with_any :: a -> b -> IO ()
with_any any \n -> show (n * n)


    "with_any" could try to check if a can be used as a b, converting it if
possible, otherwise raising an error. A similar function "with_function ::
String -> (a -> b) -> a -> b" that takes strings and try to get a function
with this name and match it against a type signature is possible. Using a
more conventional approach we can use option types instead of cps.
    Lazy evaluation is very hard to mix with imperative programming, but
lazy lists can be substituted by iterators (Sather-like) using a very simple
syntax (it's a snippet from my language, eon):


fibs is
   0 :: (1 :: (fibs zip-with (fibs tail) `+))
end

:: head tail : a -> (a Iterator) -> (a Iterator) is
   yield head ;
   loop
       yield tail !
   end
end

zip-with left right function : (a Iterator) -> (b Iterator) -> (a -> b ->
c) -> (c Iterator) is
   loop
       yield function (left !) (right !)
   end
end
tail iterator : (a Iterator) -> (a Iterator) is
    let ignored := iterator ! in
        iterator
    end
end


    Other features, like gc and pointer arithmetic, are almost incompatible.
Pointer arithmetic may corrupt memory locations and subvert the information
needed by the garbage collector. The same thing goes on static vs. dynamic
typing. It's not possible to write a Scheme-like apply function in Haskell,
because such function, while useful, subvert the type-system.
    An incompatible pair of features seems to be algebraic data-types and OO
inheritance. Algebraic pattern-matching exposes the data-type's structure,
while an OO type-system should enforce implementation hiding. We can get
around this by defining explicit deconstructors, so we can match objects
without knowing their structure:

sum list = list match {
    case List(head, tail) -> head + tail.sum
    case List() -> 0
}
abstract class
t(T){ 
    abstract match(T, List(T));
    match() {if size = 0 then () else null}
}
class LinkedList(T) <: List(T) {
    ...
    match(T, List(T)) {if size > 0 then return head, tail else null}
    ...
}
class ArrayedList(T) <: List(T) {
    ...
    match(T, List(T)) {if size > 0 then return at(0), slice(1,size) else null}
    ...
}


    But this seems to be a hack to me. Another possible incompatibility lies in multi-methods vs. "independent" modules. As multi-methods live in a gl
obal n
amespace, clashes are inevitable, so two "correct" modules compiled
separated may give ambiguity errors when used together.

    Best regards,
    Daniel Yokomiso.

"Civilisation advances by extending the number of important operations we
can perform without thinking."
 - Alfred North Whitehead


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.465 / Virus Database: 263 - Release Date: 26/3/2003