On Mon, 2007-05-07 at 10:32 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> > Which would you remove? Look in config/flx_data.py.
> >
> > Users can always obey the convention of names like
> >
> > Fred // starts with upper case
> > fred_nurk // embedded _
> >
> > which should reduce conflicts.
> >
>
> 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.
> 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
> 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;
> 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?)
> 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.
Regmatch/reglex are possible but not entirely simple.
Typematch could probably be replaced by match right now,
since types already use the same syntax as expressions.
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.
> 4. "isinf" and "NaN" should be removed, and replaced with a function /
> constant.
Then you can't match on them.
> 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.
incomplete is a qualified for types:
incomplete type myvoid = "void";
tells Felix 'myvoid' isn't a first class type, but ptr[myvoid] is.
Necessary for C binding, eg:
incomplete type X = "struct X";
where X isn't known.
> 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.
> 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 .. :)
Functor isn't implemented, but it needs to be reserved.
> 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.
cproc -- GENERATES a C proc
cclass -- binds to an existing C++ class (doesn't generate it)
In particular, given a C function .. there are several things
we could do with it (after C parsing it):
1. emit declaration
2. emit definition
3. make Felix binding (emit nothing)
4 = 1+binding
5 = 2+binding
6 = translate definition to Felix
A systematic way of specifying what you want to do with some
given C code would be cool. All the above assume we can
parse the C code (using CIL).
It's messy: Felix doesn't just bind to external C libraries,
it can also embed C, and it can generate C++ from Felix
code too.
in addition .. we can *export* Felix functions, which means
to generate a C wrapper -- similar to cfun/cproc, except the
latter are restricted to actually generating C-like functions
with the given interface (that is, no thread_frame, no gc,
no display (environment)).
It's going to get worse before it gets better.. we also have
callback ..
... :)
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
