On Sat, 2007-03-24 at 21:19 -0700, Erick Tryzelaar wrote:
> Playing around with the parser for the first time, and I got some
> comments. First, I parse should return an opt instead of an anonymous
> union. See here, on line 52:
>
> http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_0070.html
>
> 51: match z with
> 52: | case 0 => { print "Error"; }
> 53: | case 1 (?i) => { print i; }
> 54: endmatch;
>
> I think it would be a little more consistent if it used the option type.
There's actually a 'reason' it doesn't, and the same reason indicates
lists should actually be defined by an anonymous union too.
The 'reason' is that 'pure' algebraic types have a definite
representation, whereas semi-nominal types -- things with
named fields/constructors -- are accessed by field/constructor
names, and it isn't so clear how to 'access' these names from C.
Nominal types like 'opt' or a 'struct' are even worse.
If you take struct's for an example: they're not just
tuples with aliases for the tuple index numbers,
they're specific types. But there's no easy way for us
to represent those type names at the moment.
Whereas canonical names for canonical data structures make
more sense -- that is, 'numbers' are a universal thing,
so numbered fields/constructors are easier to canonicalise.
This is actually a design *flaw* in Ocaml, that option
is a pervasives functor, instead of a structurally typed
type.
Nominal typing typically fails to support non-invasive
subtyping.
So some optimisations in line for Felix might be:
change the order of struct elements to take size/alignment
into account. But don't do it for tuples, in case
we want to have tuple subtyping .. no fear for struct
subtyping, since the types are nominal they can't
be subtyped non-invasively (eg, by declared inheritance
would be needed).
The same could apply to variants, and probably will:
I plan to pack variants into pointers if there are few
enough of them. This representation would not work
with anonymous unions which also supported subtyping.
Anyhow, this is a long complicated explanation of why
it isn't done that way. A simpler explanation is that
you'd have to 'lookup' the type in the library
from inside the compiler.
In fact, the compiler already does this in a number of cases
and it is very annoying and fragile. EG: type of '1L' is
'long' but which index is that? Similarly in the Why code,
the functions 'land', 'lor' etc are looked up.
Which is why you get nasty diagnostics when these types are
not found .. which occurs when you write pure Felix without
any standard library.
A big advantage of algebraic types is that 'bool' is NOT looked
up usually, because it is just
`BTYP_sum [`BTYP_tuple []; `BTYP_tuple []]
that is, it isn't nominal, but formed entirely from type
constructors. The type
`BTYP_sum [`BTYP_void; t]
is in fact a better representation of opt[t] than the one
in the library -- because the compiler doesn't have to do
any lookup to find it.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
