[Felix-language] RFC: get rid of semicolons?

Sat, 09 Sep 2006 21:51:00 -0700

What's the opinion of 'getting rid' of semicolons?

As one who, as a beginning C++ programmer, discovered the bad error message g++ returns if you forget the trailing semicolon off of a class declaration, you definitely have my vote (on the general issue).

The effect will basically be: you can leave
semicolons off the end of statements, provided
the next statement starts with a keyword, OR,
the statement has an explicit terminator:

val x = 1
var y = 2;
x = y;
f x
fun g(){}

whilst x < y do
  var x = 1
  val y = 2;
  x = y
done
if x > y do f x done

In effect, the ; is like a leadin keyword:

val x = 1
var y = 2
; x = y
; f x
fun g(){}

except you don't need it at the start.

I think that would be confusing--even to programmers.  Either define instances that never require semicolons (and stick with them) or keep semicolons.  Imagine trying to (a) create error messages or (b) read error messages related to the lack of a semicolon as an explicit terminator on a statement that needed it.  

Semicolons can still be used of course.

Although this isn't "layout" based parsing,
it may appeal to some people. A side-effect is
reduced ability to catch errors, since the extra
redundancy of the ; helps with that.

Sounds o.k. to me.  It may even make it easier to port programs between CR+LF and LF systems.

Some syntax changes will be required, for example

fun f()="" require fred

would now be ambiguous, since it could mean either

fun f()="" require fred; // or
fun f()=""; require fred;

I'm thinking

we require fred

for the global version :)

Personally I would use layout for the first version:  For example:

fun f() = "" 
require 
fred
OR

fun f() = ""
require fred

A couple of other places will be affected, not sure how:
the most worrying is | which somehow becomes ambiguous.

Why is '|' ambiguous?  For general match and case expressions, data constructors, etc. the general rule seems to be:
(1) layout:

fun f(x:u):int =
   match x with
   | Empty => 0
   | Cons (_,?tail) => 1 + f tail
   endmatch
;

(2) context:

union X = | a | b | c

There is a slightly different way to view this.
When you write:

x = 1; f x; endl; y = 2

this can be viewed as a *single* statement,
consisting of expressions combined with the
n-ary chained ; operator (effectively left
associative binary operator).

If you keep semicolons at all it asking for trouble to reuse a simple semicolon similar to OCaml's sequence operator.  That is why OCaml terminates expressions with a double semicolon.  One exception: if the _expression_ blocks where this semicolon-form is used were separate and visible (demarcated by enclosing parentheses), similar to the for( i = 0; i < N; i++) syntax of C/C++...

This is a kind of weird _expression_ of type:

void * void -> void

where 'void' really means a command with side effects.
This would allow | to be used the same way:

x = 1 | y = 2 | z = 3

For the same reason you don't want to reuse a simple semicolon, you don't want to reuse the '|' (literally OR) operator from match and case blocks.  You need another sequence operator for general expressions, although I'm not sure what it should be because I am too unfamiliar with what has been used so far.  An arrow (->) won't work; Haskell uses a $ (whitespace-separated from all other tokens); Felix already uses f$ for special applications (I think)...

for parallel operations: now ; means sequential, and |
means parallel.

I don't know what you mean here.  Are you talking about ordinary operations or special operations, such as threads?  In any case reusing simple ';' and '|' are not specific enough.  I would suggest keywords such as 'par' for parallel and 'seq' for sequential.  For example:

par
proc 1
proc 2
end

seq
proc 1
proc 2
end

(if you want semicolons to separate lines instead of line endings, both should have line endings.)

Somewhat unfortunately for that idea in

match x with
| a => b
| ..

the actual operation is strictly sequential.
-------------------------------------------
BTW, I don't like match much. I think Jay's case
is cleaner:

case a => b | c => d endcase x

means the same: match is a closed term, so to use
it as a function it has to be lambda abstracted:

(fun:t1->t2 = | a=> b | c => d) x

and even that is a shortform. The main advantage
of match is that the argument type doesn't have
to be named.

Just imagine that syntax containing a series of long expressions instead of " b | c ".

Perl actually as

pat ~= arg

for a match .. interesting. (Hmm or is it arg ~= pat .. ?)

To match a pattern in a string, the syntax is:

$string =~ /pattern/

-Pete
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to