Nicolas Pouillard wrote: >> The point is the issue here isn't ambiguity of a correct >> program .. but ambiguity of an *incorrect* program. > > Ok, that's a good point, XML guys say that too. > Having a program syntactically robust and stable is a good thing. > > That's the same thing with XML, I don't care that XML data gets > generated, moved over the network and parsed at another point, but I > don't want write it by hand. > > So having a robust form to a language is a good point, but please make > it optional, non ambiguous and cheap in term of keywords. > > Example of proposition: > match ... with > ... > end of match > > Sometimes, I think that programming languages should have a "sort" of > normal form using XML or s-expression. Even in this case I would > prefer s-expressions rather than the too heavy too close XML syntax.
I agree with the sentiment, but I personally prefer "endmatch" to "end match" or "end of match". Those just feel even longer than the one without the " ". Anyway, here's an example from ruby to consider, since they use "end" for their block terminator: http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/base.rb It's quite a long file, and shows a lot of the good and bad things with how how to end a block. First we can see that short functions work really well with just an "end" with indented code: def foo(bar) bar = do_something(bar) if bar == 4 bar = 5 else bar = 6 end baz = case bar when 5 "a" when 6 "b" else "c" end bar + 1 end 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". Now if these were renamed to: ... 6 module ActiveRecord ... 272 class Base ... 2263 def clone_attribute_value(...) ... 2274 enddef 2275 endclass 2276 endmodule It would be somewhat easier to figure out what goes with what, but not exactly. I didn't look too carefully, so it's possible I missed another module and class definition. Also, enddef really is just line noise since we can clearly see the definition of the function. Say we went even more rigorous: ... 6 module ActiveRecord ... 272 class Base ... 2263 def clone_attribute_value(...) ... 2274 end clone_attribute_value 2275 end Base 2276 end ActiveRecord This we know exactly where things come from, but it's very noisy. What about optionally named ends? It could help with the documentation and type safety, but we'd only pay for the noise when we actually need it: ... 6 module ActiveRecord ... 272 class Base ... 2263 def clone_attribute_value(...) ... 2274 end 2275 end Base 2276 end ActiveRecord or in pseudo-felix: module Foo = fun foo1 () => 5; fun foo2 (x:int) = return match x with | 5 => 6 | _ => 7 end ; end; fun foo3 (...) = ... end foo3; end Foo; I'm not sure what we'd do about matches though. Felix (the compiler) has some *very* large matches. >>> It's more about closing classes, >>> modules... And here I prefer comments: >> .. 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. -e ------------------------------------------------------------------------- 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
