On Thu, 2007-05-10 at 16:38 -0700, Erick Tryzelaar wrote:
> However, things really break down when you have a very large block of
> code. For instance, if you go to the very end of the file, you see:
>
> ...
> 2263 def clone_attribute_value(...)
> ...
> 2274 end
> 2275 end
> 2276 end
>
> And it's really hard to see what's going on. you have to dig a bit to
> see that the end on 2275 matches with "272 class Base" and the end on
> 2276 matches with "6 module ActiveRecord".
You just don't want to look at my Ocaml code then, particularly
the flx_lookup.ml module... the same problem exists (and it's
made much worse by multiple files wrapped by interscript).
The problem in Ocaml is that it is hard to factor nested matches,
because you lose context. So often even when i do factor code
into a subroutine .. it is still nested so it can access
abbreviations are parameters: when i globalise the code I have
to pass all the parameters and redefine the abbreviations.
The best solution to this is probably a folding editor .. Vim 7
supports folds, but using them sucks (it needs commands, it should
be done by the mouse .. )
> This we know exactly where things come from, but it's very noisy. What
> about optionally named ends?
If you have optional named ends, they should do multiple
endings I think. So you can do
module Act
class Base
def clone
stuff
end Act
The problem with this is that it isn't LALR(1). Endings can't
be optional. They're either required or disallowed:
let .. in .. // no end
match .. endmatch // an end
> >> .. heh .. and in these cases Felix uses { } .. so actually
> >> Felix has it backwards. The long constructions don't get terminated
> >> with heavy terminators as they should, whereas the light ones do
> >> when they shouldn't.
> >
> > Indeed that's funny.
>
> This is an excellent point. I think even if we don't shorten down
> endmatch and etc, then we should at least switch to using "endmodule",
> "endclass", and etc. We should try to be consistent.
The problem is, languages are inherently quirky. If you want
to be consistent, you'd get rid of infix operators. In fact
postfix is the best:
x y +
especially for category theory, where the posifix notation is
more or less mandatory (but is only used by a few theorists).
-- w --> . -- o --> . -- r --> . -- d -->
that function is spelled
d r o w
in prefix notation .. REALLY bad.
--
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
