skaller wrote: > On Mon, 2007-05-07 at 10:32 -0700, Erick Tryzelaar wrote: >> What would that be equivalent to in the current syntax? > > huh? That is current syntax, I'm just suggesting how to avoid > clashes with keywords.
Oh, duh, of course. >> Here's my list of things we could change: >> >> 1. There's a lot of code commenting keywords that we could do away with, >> like "comment", "todo", and "publish", although I think publish is >> supposed to be like python docstrings. If that is the case, I'd prefer >> it to be named just "docstring" as publish is a much more common >> function name. > > > Originally i wanted to give Felix some builtin Literate Programming > features -- I still do. But it is harder than I thought. > > Add ticket: review commenting style http://code.felix-lang.org/ticket/7 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? >> 2. I'm not sure if this is LALR, but it'd be nice if we just had one >> terminator for all of our "endcase", "endif", and "endmatch" constructs. >> What if we just replaced them all with "end"? > > That's LALR(1), no worries. The endmatch, endif, etc etc are > deliberate so you have balanced distinct pairs: > > match -- endmatch > if .. endif > > This makes debugging and error detection easier. But it > is inconsistent with, for example: > > proc f() { .. } > > using { } .. instead of > > proc f() begin ... end; 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. 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;". >> I do like "do"-"done", and >> I'd like to raise that up to roughly equal "begin"-"end" from ocaml. > > The difference is do/done doesn't introduce a scope, whereas > begin/end does (in Ocaml). > > begin/end are stolen by STL .. I'd like to steal them back > by replacing the begin()/end() methods of containers with > some other names. (start/finish?) 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; But it's not too terribly important to me. It just feels like it'd be more efficient though I bet it doesn't matter. >> 3. It'd be nice if pattern matching with the keyword "match" could take >> over for "regmatch" and "typematch". I'm sure that would take some >> effort though. > > [snip] > > 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? >> 4. "isinf" and "NaN" should be removed, and replaced with a function / >> constant. > > Then you can't match on them. You could always do: match 1.0f with | ?x when x == inf[float] => .... | ?x when x == -inf[float] => ... endmatch; Of course you couldn't use the range literals, which would be sad. Felix can't use a constant as a constructor, can it? >> 5. I'm not sure what "compound", "fork", "halt", "incomplete" and "loop" do. > > compound, fork are unused (fork is obviously for forking .. :) > > halt does what it says .. it halts the program. Shouldn't fork and halt be implemented as a function or a service call? >> 6. Typeclass "virtual" really should be removed and replaced with just >> the function definition :) If we ever do traditional class inheritance >> though, we can add it back. > > No, because a typeclass can have 'nonvirtual' functions too. > However the terminology is wrong if we unify classes/typeclasses/ > modules .. in fact a Felix virtual function is like a template > whose instance is a specialisation. You're right. I just thought of another reason why we need to mark a function specially for typeclasses. How can we say this function is overridable, but here's a default implementation? >> 7. I don't think "functor" and "inherit" are implemented yet. They could >> be removed, and another check later could error out if you're using a >> reserved word like these. > > Inherit is used a lot! It's used in modules and typeclasses .. :) Whoops, of course. > Functor isn't implemented, but it needs to be reserved. 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. Of course could always implement functors as arguments to a modules, like: module Foo (x:module_interface) { typedef t = x.t; ... } >> 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. ------------------------------------------------------------------------- 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
