bobthecheese fucked around with this message at 15:33 on Jan 25, 2012

Beef fucked around with this message at 18:59 on Jan 27, 2012

NewEmailAddressAllowed = Customer.NewEmailPassesDuplicationRules(EMailField, ThisCustomer.CustomerID, false);

if (NewEmailAddressAllowed || !emailisvalid)
{
   EMailField = ThisCustomer.EMail ; // reset their e-mail, but then update their account with other changes below
}

Hibame fucked around with this message at 08:52 on Jan 28, 2012

• Semicolons are required(except when they're not!) -- by this I mean apparently there is a semantic difference between if true { 5 } and if true { 5; }. They are both expressions; the first version returns 5, while the second returns nil. Apparently someone decided that the presence or absence of a line terminator should decide whether or not the block returns a value or nil.
  
  
• I can't tell if it's always like this or not but apparently local variables get type inference, but "global" constants don't, and thus are declared like this: const repeat: uint = 5u;. Maybe I'm dumb but this syntax is pretty unintuitive (especially with syntax highlighting as on their site). *
  
  
• Nil is not written as nil; instead it is written as (). This works in a lisp-ish language but there's not even a concept of parenthesized lists in this language so it looks extremely out of place (I guess they wanted to simplify their grammar for functions without arguments maybe)
  
  
• Macros/macro functions are specifically set off by a #. Example: std::io::println(#fmt("%s is %d", "the answer", 42));. This has potential but still strikes me as a bit awkward and unnecessarily leaking implementation details into code (why can't fmt just look like a plain function?).
  
  
• An alt construct that implements pattern matching. Cryptic syntax included: 2 | 3 means 2 or 3 (makes sense), 4 to 10 (also is ok), _ is "default" (this is alright I guess but it looks like line noise). Also apparently an alt block that fails won't silently fall through. Instead it is designed to "blow up" according to the tutorial.
  
  
• 3 types of pointers and 3 types of closures, all identified with different sigils (@/fn@ is a "boxed" pointer/closure; ~/fn~ is a "unique" pointer/closure (only one owner/reference allowed); */fn are "normal" pointers/closures
  
  
• Strutures and vectors (their array types) are unique and immutable by default, which does not make much sense in a language trying to appeal as a systems-ish language.
  

/*
Function: merge_sort

Merge sort. Returns a new vector containing the sorted list.

Has worst case O(n log n) performance, best case O(n), but
is not space efficient. This is a stable sort.
*/
fn merge_sort<T: copy>(le: lteq<T>, v: [const T]) -> [T] {
    fn merge<T: copy>(le: lteq<T>, a: [T], b: [T]) -> [T] {
        let rs: [T] = [];
        let a_len: uint = len::<T>(a);
        let a_ix: uint = 0u;
        let b_len: uint = len::<T>(b);
        let b_ix: uint = 0u;
        while a_ix < a_len && b_ix < b_len {
            if le(a[a_ix], b[b_ix]) {
                rs += [a[a_ix]];
                a_ix += 1u;
            } else { rs += [b[b_ix]]; b_ix += 1u; }
        }
        rs += slice::<T>(a, a_ix, a_len);
        rs += slice::<T>(b, b_ix, b_len);
        ret rs;
    }
    let v_len: uint = len::<T>(v);
    if v_len == 0u { ret []; }
    if v_len == 1u { ret [v[0]]; }
    let mid: uint = v_len / 2u;
    let a: [T] = slice::<T>(v, 0u, mid);
    let b: [T] = slice::<T>(v, mid, v_len);
    ret merge::<T>(le, merge_sort::<T>(le, a), merge_sort::<T>(le, b));
}

Look Around You fucked around with this message at 14:24 on Jan 28, 2012

• Semicolons are required(except when they're not!) -- by this I mean apparently there is a semantic difference between if true { 5 } and if true { 5; }. They are both expressions; the first version returns 5, while the second returns nil. Apparently someone decided that the presence or absence of a line terminator should decide whether or not the block returns a value or nil.

• I can't tell if it's always like this or not but apparently local variables get type inference, but "global" constants don't, and thus are declared like this: const repeat: uint = 5u;. Maybe I'm dumb but this syntax is pretty unintuitive (especially with syntax highlighting as on their site). *

• Nil is not written as nil; instead it is written as (). This works in a lisp-ish language but there's not even a concept of parenthesized lists in this language so it looks extremely out of place (I guess they wanted to simplify their grammar for functions without arguments maybe)

• Macros/macro functions are specifically set off by a #. Example: std::io::println(#fmt("%s is %d", "the answer", 42));. This has potential but still strikes me as a bit awkward and unnecessarily leaking implementation details into code (why can't fmt just look like a plain function?).

• An alt construct that implements pattern matching. Cryptic syntax included: 2 | 3 means 2 or 3 (makes sense), 4 to 10 (also is ok), _ is "default" (this is alright I guess but it looks like line noise). Also apparently an alt block that fails won't silently fall through. Instead it is designed to "blow up" according to the tutorial.

• 3 types of pointers and 3 types of closures, all identified with different sigils (@/fn@ is a "boxed" pointer/closure; ~/fn~ is a "unique" pointer/closure (only one owner/reference allowed); */fn are "normal" pointers/closures

• Strutures and vectors (their array types) are unique and immutable by default, which does not make much sense in a language trying to appeal as a systems-ish language.
  

Look Around You fucked around with this message at 14:21 on Jan 28, 2012