On Sun, 2006-09-10 at 21:16 -0400, Peter Tanski wrote:

> > No, what I mean is syntactically kindable, that is,
> > not dependent on lookup.
> 
> You just blew my mind.  I have been working with C, C++ and Haskell  
> so much I simply assume lookup is a normal thing;

Lookup in Felix is complicated by three factors:

(a) overloading

(b) module directives like 'open' and 'inherit'
   which construct complex environments

(c) the fact lookup isn't sequential but parallel

Point (a) is mandated by user expectations (C++ compat).

Use of namespaces and directives (b) is mandated by 
the need to keep code terse, avoid conflicts, and
resolve them when they arise.

Use of (c) is my own thing: I HATE needing forward
declarations to support recursion. So symbols
have block scope. All of them. Which means binding
can be done for any statements in any order, even
in parallel.

The only ordering is directives: the 'open'
directive is ordered: a confluent open directive
is a nightmare .. that's how it used to be though.

[The problem is that 'open name' has to lookup
'name' in the current scope, which means all the
OTHER open directives have to be considered as
having already opened their target scopes for
lookup .. but this applies recursively to
THEM as well .. the definition was that 
the set of open modules had to converge to a fixpoint,
and it was really hard to make that work .. by which
I mean I never did .. so I changed it :]

> module M:
> typeclass Serialisable[T] { }
> 
> module N:
> typeclass Serialisable[U] { }
> 
> You may resolve potential conflicts by essentially overloading the  
> typeclass name between modules.  I think this would only be a good  
> policy if you required namespace overloading for typeclass names:
> 
> fun new_function1[T, where N.Serialisable T]
> fun new_function2[T, where M.Serialisable T]

Overloading only applies to function identifiers.
Functions have 'full' names which are unique, and include
the argument type:

        f of (int)

for example. But this is 'unique within one scope'.

In your example above the notation is:

        N::Serialisable[T]
        M::Serialisable[T]

which is not overloading, but explicit qualification
of what would be ambiguous were both modules M and N open
and you only used an unqualified name.

the notation :: sucks but it is what C++ uses ;(

Operator . can't be used because of kinding issues,
the LHS could be a value, and that is a distinct kind
to a module:

        x.y

requires x to be an expression,

        x::y

requires x to be a *module expression*. Yes, Felix has support
for 'calculating' module names (but only at compile time).
That's because it USED to have functors:

        (funct t)::y

would be allowed, where funct was a module functor.


> I will note for the record that when I described the implementation  
> of typeclasses (with lists of typeclasses and their instantiated  
> types, super-types, etc.) for type-checking, this list is built  
> during parsing and is used for lookup as well.

At present it seems:

(a) typeclasses do NOT require any changes to the type system
    or runtime system .. it's entirely sugar

(b) at present, everything flows through all phases of compilation

(c) but I have not implemented any checking

(d) I haven't implemented the injection of overloads

(e) I haven't implemented instantiation

Note that (a) is because Felix is a whole program analyser.
If we had separate compilation, we'd literally have to use
vtables.

(This is worth doing .. but it is slower and harder to do
and pointless until we have separate compilation, which
may be never .. :)

> I have been eating my words while attempting a uniform syntax here  
> and I have to say that what you have created so far is quite compact  
> and powerful.  Certain combinations are simply not legible as they  
> contain a series of completely different token types:

Yes. I've added nice new features and just 'thrown in' extra
syntax as required. By Felix 2.0 we need to fix the syntax.
At present, adding even more features is a good way to get this:
you can't abstract a single case, you need many cases to see
the best patterns.

>       fun new_function[T, where CppContainer T] (x:T, y:T):T = { ... }

> Like most programming, it relies on punctuation but this is an  
> extreme form of punctuation, here.

By which you mean it is UGLY :)

> Maybe it would be easier to retain only some of the information and  
> not make it so compact; or split up the tokens in a less compact but  
> more readable way.  I am still working on it, 

Keep thinking but don't work on it TOO hard, since you're
not familiar with all the different facets of the language yet,
and neither am I .. it keeps changing and even I can't remember
everything I implemented :)

> BTW, if you use such overloading, typeclasses are not necessary, they  
> are simply convenient.

BTW, if you use C, Felix is not mandatory, just convenient .. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to