On Mon, 2007-05-07 at 16:14 -0700, Erick Tryzelaar wrote:
> What about reducing all that down to one keyword "lit", and then you'd
> do "lit comment = 'foo'"? Have you looked into how haskell does their
> embedded LaTeX?
We should treat the LP as a DSSL.
At the moment 'publish' is a user defined statement ..
However user syntax isn't strong enough to support, for example,
annotation of function parameters. Even doxygen can do that.
> True on both points. I've never really had trouble finding the matching
> start and stop tokens. Ruby uses "end" for it's closing token for
> everything pretty successfully. It also sure would be nice to reclaim
> the {} tokens as well.
Felix uses the {} purely to make it easier on the C++ programmer's eye.
> On a side note, one thing I've also always wanted was to standardize
> proc and fun so that it'd be like "proc f () = { .. }" and add support
> for "proc (x:int) = print x;".
Consider
fun f(x:int) = 1;
Looks ok .. but the problem is then
fun f(x:int) = { 1 };
fun f(x:int) = { return 1; };
Remember { 1 } and { return 1; } are expressions of type unit -> int.
So here:
f: int -> (unit -> int)
which isn't what you expected. More sense would be
let f = lam (x:int) => 1 endlam
which is what Ocaml does:
let f = function x -> 1 in ..
let f = fun x -> 1 in ..
and of course in Felix:
fun f: int -> int =
| ?x = 1
;
similar to Haskell (the | is mandatory).
> The only reason why I want something like this is so that you can have
> multi-statement pattern matches, like this:
>
> val x =
> match 5 with
> | 5 => "five"
> | 6 => do
> print "hello"; endl;
> return "six";
> done
> | _ => "foo"
> endmatch
> ;
>
> It always feels a little ugly having to wrap things in anonymous functions:
>
> val x =
> match 6 with
> | 5 => "five"
> | 6 => {
> print "hello"; endl;
> return "five";
> } ()
> | _ => "foo"
> endmatch;
Ouch .. of course that is technically illegal (side effect in
expression) but similar legal code exists eg:
{
val five = "five";
return five;
} ()
which is indeed ugly ..;( Ouch. Normally you can elide
the closing () in a statement but this is inside an expression.
> > There's a case for a hybrid though:
> >
> > typecase int with
> > | int => 1
> > | long => 2
> > ...
> >
> > i.e. matching a type but returning an executable expression.
> > This is a kind of type driven conditional compilation.
>
> Couldn't this still be done with the "match int with" syntax, with
> enough hand waving at the problem?
Can't see how: the compiler has to know what kind the argument is,
and lookup isn't a solution, contrarily the kind directs the lookup.
You could have
match[texpr] with | int => 1 ...
though :)
> You could always do:
>
> match 1.0f with
> | ?x when x == inf[float] => ....
> | ?x when x == -inf[float] => ...
> endmatch;
yes but not:
| 0 .. inf => ...
which you can do now (at least i think you can :)
> Of course you couldn't use the range literals, which would be sad. Felix
> can't use a constant as a constructor, can it?
No, not at the moment. But you can use a constructor with no arguments
as a constant .. :)
And you could *upgade* constants to constructors, eg by
match x with
| `1 => ..
| `(22+99) =>
if you want to waste the ` character on that.
> Shouldn't fork and halt be implemented as a function or a service call?
Halt is an intrinsic with the property that the compiler knows
control cannot flow through it. svc is assumed to return.
Of course it can be renamed _halt.
> Now that dypgen can use variants I guess it isn't such a big deal to
> have this reserved in the parser instead of later on in the pipeline.
dypgen still needs more work. It bugged out because it defines 'merge'
and the parser user code opens List (which contains 'merge' function).
> Of
> course could always implement functors as arguments to a modules, like:
>
> module Foo (x:module_interface) {
> typedef t = x.t;
> ...
> }
Good idea. What's an interface? Hmm .. how about a typeclass?
module Foo[t with Eq[t]] { f(x:t) .... }
Implementation ..
f[t with Eq[t]] (x:t) ..
Oh wait .. that should work right now! Or close to it.
Hmm.. or:
module Foo (X) { typedef t = X::t; }
Something I've been thinking of is 'typesafe' macros aka templates.
They're just C++ templates, that is, they bind to the
context of use.
We do sort of have this with 'reduce .. ' but only
for expressions. There's no 'reduce' for statements.
>
> >> 8. We have a lot of c wrapping keywords, "cclass", "cfun", "cparse",
> >> "cproc", "cstruct", and "ctypes". Perhaps we could replace all of these
> >> with just a prefix keyword like "cwrap" which you could use like "cwrap
> >> class", "cwrap fun" and etc. I'm not crazy about that particular name
> >> though.
> >
> > extern "C"?
> >
> > I agree completely on this idea. It's a mess. However they're NOT
> > all C wrapping functions.
> >
> > [snip]
>
> That's a lot to consider! I'm not sure how we could simplify that.
So do i.
There are other stuff like this, for example product types:
kind product field typing
tuple anon pos structural
record anon named structural
struct named named nominal
new named anon nominal
The last one is a nominally typed tuple ..
type x = new ...
should do that now, the abstract/private type thingo.
It would be better if all types were structural and have named
fields, positional is a just 'name is an integer' and nominal
typing is made with a binder like 'new'. That would factor
the possibilities.
Class and struct should merge, smly cclass and cstruct ..
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
