On Sun, 2006-09-10 at 14:55 -0400, Peter Tanski wrote:
> On Sep 10, 2006, at 11:54 AM, skaller wrote:
> instance CppContainer (Vector T) {
> }
>
> -- the parenthesised form is both readable and kindable (Vector has
> kind (* -> *), T has kind *)
No, what I mean is syntactically kindable, that is,
not dependent on lookup.
This is important because some expressions such as
2
are both executable AND types, so at present the kind
must be encoded in the grammar. Also note that in:
var x = int(2.3);
the RHS looks like an executable expression, and IS an
executable expression, but the kinding is wrong for 'int',
when enables a special translator rule:
var x = _ctor_int(2.3);
to 'fixup' the kinding. Kinding by lookup is a severe NONO
in many systems: C/C++ used this and it creates an absolutely
unmitigated disaster of extreme proportions: one has to
SLAM the morons on the ANSI C committee that allowed
typedef names to be used as keywords: such ignorance
of parsing is inexcusable on a so-call panel of experts.
In C++, templates blow this out of the water:
X::t
is not of known kind in a template and you CANNOT look
it up if X is a parameter, so a kinding operator
typename X::T
had to be introduced .. and then
templatename X::Y
since templates can also be passed as parameters,
just to *allow* parsing.
In Felix, there is no problem parsing between types
and expressions: the syntax is (deliberately) identical.
Also since Felix allows overloading, there would be
a VERY hard problem to resolve:
f: TYPE -> int -> int
f: int -> int -> int
f 1 2 // ambiguous!
We'd be relying on impossible kind inference here,
because '1' is both a type and an int. That's why
Felix uses
f[int] 2
syntax: the brackets are needed here to distinguish the
optional type term from the executable expression:
the point is we cannot even use simple lookup to do
kinding: it's bad enough you can't do typing without
overload resolution.
It's probably possible to make 'expression' transparent,
but at present Felix internally represents types and expressions
with distinct terms, even if the concrete syntax fails to make
a distinction, and the translation is driven by the grammar,
and usually done in the parser.
The problem really is that whilst I think a 'universal' language
for types and all higher order kinds is possible, executable
code is too quirky, especially in a language like Felix designed
to be reasonably familiar to todays programmers.
Haskell is cleaner -- but it is VERY hard to read for people
like me that aren't used to it, particularly because the
types and expressions are kinded by lookup -- it looks
good but it is very hard to read until you're used to not
getting the visual kinding clues.
[The same argument applies to type inference .. it looks
cute but to work with the insanely bad errors todays inferencers
produce needs a whole new programming style]
--
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
