Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

tef: May 30, 2004; -> some l-system crap ->

Look Around You posted:

Yeah I'm basically retarded and thought things through like not at all and ended up making an rear end out of myself posting like an idiot at 2 am.

it's ok I do that too :3:

thing is it pretty much the norm to go into a new thing looking for reasons to hate it.

# ? Jan 28, 2012 14:24

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 00:38

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Look Around You posted:

Yeah I'm basically retarded and thought things through like not at all and ended up making an rear end out of myself posting like an idiot at 2 am.

Don't feel too bad, shrughes is basically a jerk. It's kind of his thing.

# ? Jan 29, 2012 02:59

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Scaramouche posted:

Don't feel too bad, shrughes is basically a jerk. It's kind of his thing.

Yeah, but rust legitimately owns, often for exactly the reasons that were criticized. (Immutable variables own).

# ? Jan 29, 2012 03:12

bobthecheese: Jun 7, 2006; Although I've never met Martha Stewart, I'll probably never birth her child.

Scaramouche posted:

Don't feel too bad, shrughes is basically a jerk. It's kind of his thing.

You say that like it's not pretty much everyone's thing here :spergin:

# ? Jan 29, 2012 03:12

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

The1ManMoshPit posted:

Somebody's never included <Windows.h> and had to deal with nonsense error messages while trying to compile calls to std::max and std::min, or while trying to declare enum Distance { NEAR, FAR }; only to find they have been boned by all the windows #defines.

Xlib has the same thing. It has #define None 0, which breaks LLVM and Qt and countless other things which do:

code:

namespace llvm {
  class None {
  };
};

As such, KDE has an entire header file, fixx11.h.

# ? Jan 29, 2012 03:58

Look Around You: Jan 19, 2009

Scaramouche posted:

Don't feel too bad, shrughes is basically a jerk. It's kind of his thing.

I don't feel bad really (and I don't hold it against him), I just feel dumb because I posted a kneejerk reaction of something without taking much time to figure out reasons behind it. Maybe part of it was I wasn't able to get a feel for the goals and stuff of the language right away, but that's not really an excuse for me posting retarded poo poo, that's just me not taking the time to comprehend something and then spouting poo poo off about ideas that I only half understood.

# ? Jan 29, 2012 06:05

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

There are a lot of interesting ideas in Rust. That's what you would hope to see from an acknowledged research project. It's hard to criticize anything about it, because they haven't really committed to anything about it, and might not for many years to come. I might point out that this also doubles as a reason not to get unduly unexcited about it, but after all, this is the internet.

# ? Jan 29, 2012 06:23

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Look Around You posted:

I don't feel bad really (and I don't hold it against him), I just feel dumb because I posted a kneejerk reaction of something without taking much time to figure out reasons behind it. Maybe part of it was I wasn't able to get a feel for the goals and stuff of the language right away, but that's not really an excuse for me posting retarded poo poo, that's just me not taking the time to comprehend something and then spouting poo poo off about ideas that I only half understood.

I think your core argument was "this language looks like C++, Perl and LISP hosed and C++ drank throughout the pregnancy." It might've looked better if the dude who was writing code for the standard libraries used variables that were longer than two characters and maybe threw in some whitespace, but yeah, that is some ugly code.

# ? Jan 29, 2012 15:10

Zombywuf: Mar 29, 2008

shrughes posted:

Advanced programming languages are advanced. All these features are reasonable.

I'd heard some good things about rust, but these complaints are all perfectly reasonable. These "features" are terrible. Also your markup of the parent post is terrible. You are terrible.

quote:

quote:
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.

This lets you write blocks that return nil without having to write an extra nil expression. Also this helps catch type errors, for example if one block was written to return nil while another does not. If you didn't have this feature then every if/then/else block would need extra nil statements, or a special case in the language. Do you notice how this feature does no harm to the user? And how you're bitching about it?

So you get wildly different behaviour from a fleck of fly poo poo in your code? Different things though look different. If you want your function to return nil put a special return nil keyword at the end of it, not ;. ; at the end of a line has a meaning in a huge number of languages, using the same syntax to make a thing that looks like it fulfils the same function but actually does something different is a very bad thing. What's next, + and - being defined as the malloc and free operators?

quote:

quote:
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).

You think global constants shouldn't have their types explicitly declared? No. Rust is for writing correct programs, not wrong programs.

That syntax appears to declare the type twice on the same line. Why is the type declared twice on the same line?

quote:

quote:
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)

You're seriously bitching because they chose a different syntax instead of the keyword you might choose. Don't they have tuple types? They would have tuple types. This is probably consistent with that, the way they are in most functional languages. If you think this looks like a lisp-ish construction you need to learn Lisp and you also need to learn some other languages, because it is an obvious non-lisp construction.

What is the type of ()?

quote:

quote:
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?).

fmt can't be a plain function obviously because then it couldn't be statically typed, it would be a variadic function which is bad. Also you get the usual crap with the need for va_list versions of all your functions.

whoooosh

That is the sound this question made as it flew over your head. Why should the consumer of fmt have to know about what type system features had to be worked around in order to declare it?

quote:

quote:
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.

You're saying that as if silently falling through would be a good thing. Which it is not. Crashing the program there is basically the only thing to do. In our C++ code every switch statement has a default case that calls a function unreachable() which prints a backtrace and crashes.

Why is failing to compile with a type error not an option?

quote:

quote:
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

This is a good thing. It's called an advanced type system.

It's called a butt ugly syntax for a type system.

quote:

quote:
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.

Yes it does.

How do you load data into a texture buffer?

# ? Jan 30, 2012 14:35

leterip: Aug 25, 2004

Whenever I see ~/fn~ I think

It's so unique :allears:

# ? Jan 30, 2012 15:16

Shady Amish Terror: Oct 11, 2007; I'm not Amish by choice. 8(

While I'm disappointed that I ran out of money before completing college, and that I'm now stuck eternally in service industry hell, I was never a great programmer. It's nice to be able to look at this thread occasionally and feel better that some of you might be alive today because you never had to encounter or attempt to fix my code.

A good example was a short in-class project where we had to write some simple code in the fewest lines possible. I beat the instructor's ~30-line example by something like six lines... by concatenating as many variable definitions as I knew how and using a loop iterator variable as data AND in a separate break condition within the loop. This was in freshman year, and pretty much set the tone of my programming since.

Shady Amish Terror fucked around with this message at 16:40 on Jan 30, 2012

# ? Jan 30, 2012 16:36

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Shady Amish Terror posted:

A good example was a short in-class project where we had to write some simple code in the fewest lines possible. I beat the instructor's ~30-line example by something like six lines... by concatenating as many variable definitions as I knew how and using a loop iterator variable as data AND in a separate break condition within the loop. This was in freshman year, and pretty much set the tone of my programming since.

These sorts of challenges are fun and give a clear definition of the goal to enable competitiveness. It's a great thing to clear your mind with after spending six hours staring into the abyss wondering why the hell these backtraces don't make any goddamn sense what the hell gdb what is wrong with you.

Of course, the trouble happens when some confuse work with play.

# ? Jan 30, 2012 17:34

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Zombywuf posted:

So you get wildly different behaviour from a fleck of fly poo poo in your code? Different things though look different. If you want your function to return nil put a special return nil keyword at the end of it, not ;. ; at the end of a line has a meaning in a huge number of languages, using the same syntax to make a thing that looks like it fulfils the same function but actually does something different is a very bad thing. What's next, + and - being defined as the malloc and free operators?

you can explicitly return nil if you want (ret ()

quote:

That syntax appears to declare the type twice on the same line. Why is the type declared twice on the same line?

there's no type coercion between integer types in rust, 5u != 5. nor does uint == uint8, uint16 or uint32.

quote:

What is the type of ()?

nil.

quote:

Why is failing to compile with a type error not an option?

because patterns are not required to be exhaustive. this is like asking why asserts can't be staticaly checked.

# ? Jan 30, 2012 20:21

taqueso: Mar 8, 2004

All this talk got me to check out rust. It actually looks pretty cool and I am trying to hold off judgement on things like ~/fn~. It seems silly to say "That isn't what I'm used to" or "That looks weird/awkward" without giving myself a chance to try it in practice. I'm excited about getting some rust code to run on a microcontroller, but so far I have only built x86 executables. I was glad to see C linking info right in the tutorial and I'm hoping the LLVM backend means it won't be to hard to get Thumb output (I've only used gnu tools to target ARM in the past).

# ? Jan 30, 2012 23:03

Zombywuf: Mar 29, 2008

the talent deficit posted:

you can explicitly return nil if you want (ret ()

What you're saying here is that ; is a synonym for ret ();. This has a pleasing symmetry but has no place in a language.

quote:

there's no type coercion between integer types in rust, 5u != 5. nor does uint == uint8, uint16 or uint32.

So why can the type of the variable being assigned to be inferred?

quote:

nil.

Well that's a silly name for a type that appears to be a unit.

quote:

because patterns are not required to be exhaustive. this is like asking why asserts can't be staticaly checked.

That I think wins the thread for most tautologist answer.

# ? Jan 30, 2012 23:54

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Zombywuf posted:

So why can the type of the variable being assigned to be inferred?

it's inferred from usage. globals are accessible from outside the compilation scope, and must be explicitly defined

quote:

That I think wins the thread for most tautologist answer.

you're going to have to explain how a compiler can infer whether input will lie in a specified domain

# ? Jan 31, 2012 00:54

1337JiveTurkey: Feb 17, 2005

Zombywuf posted:

What you're saying here is that ; is a synonym for ret ();. This has a pleasing symmetry but has no place in a language.

The semicolon's not a synonym; it's the empty statement afterwards that's a synonym for ret (). The semicolon's just acting as a Pascal-style statement separator rather than a C-style statement terminator. For a language which doesn't require semicolons as terminators, it's a lot more sensible to treat them as separators when they are used.

# ? Jan 31, 2012 01:32

tef: May 30, 2004; -> some l-system crap ->

Zombywuf posted:

I'd heard some good things about rust, but these complaints are all perfectly reasonable. These "features" are terrible. Also your markup of the parent post is terrible. You are terrible.

We're all terrible.

Rust is 0.1 - much of the effort put into it is to see if certain language features can work together to build robust code. The syntax especially is being worked out as they write more and more code in it - the language has changed considerably (from what I have noticed) as they have gotten to the fully bootstrapped stage.

If you want to talk about issues in the language, the developers are fairly active on irc and answered a whole bunch of my stupid questions eventually - they will probably be more qualified to answer your questions than anyone here.

quote:

So you get wildly different behaviour from a fleck of fly poo poo in your code?

I can't justify the whole {foo;} {foo} thing. I find that weird.

quote:

That syntax appears to declare the type twice on the same line. Why is the type declared twice on the same line?

As for 5u - I would imagine that type inference would let you drop the variable type and infer it from the literal type. I am guessing that the example is more explicit on purpose.

quote:

Why should the consumer of fmt have to know about what type system features had to be worked around in order to declare it?

As for why 'fmt' can't look like a function - it is because the way in which fmt's argument types are interpreted are dependent on the first argument - functions in rust do not work that way.

To quote you earlier 'Different things though look different.' - although a more expressive type system would eliminate the need for such 'hacks', the design choice seemed to be macros over varargs and allowing varags to be implemented using them.

quote:

It's called a butt ugly syntax for a type system.

To quote you earlier 'Different things though look different.' - Each of those pointer types have different behaviours and costs attached - most notably unique pointers are the only ones allowed to be passed between processes iirc.

quote:

How do you load data into a texture buffer?

As for loading a texture into a buffer, one would assume that they create a mutable buffer, as opposed the default immutable buffer. I thought the clue would be in the whole 'by default' implying an option otherwise.

quote:

Why is failing to compile with a type error not an option?

rust aims for highly robust programs - it is more conservative about what programs it accepts than many other languages.

really I don't want to defend rust here but only to say that it hasn't been properly introduced. if you're curious about it I would highly recommend the faq and the design docs over what has been poorly explained here. I think rust deserves a fair trial*.

even so I still don't get the whole magic semicolon thing

* rob pike has somewhat angry words about this http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html - to some extent it is right, but at other times it can be a failure to communicate the design constraints of the language.

tef fucked around with this message at 02:03 on Jan 31, 2012

# ? Jan 31, 2012 01:56

Opinion Haver: Apr 9, 2007

I see.

# ? Jan 31, 2012 01:59

zeekner: Jul 14, 2007

yaoi prophet posted:

I see.

ArchLinux? I haven't installed it in a while, but the installer was pretty barebones for such a nice customizable distro.

# ? Jan 31, 2012 02:37

Opinion Haver: Apr 9, 2007

Geekner posted:

ArchLinux? I haven't installed it in a while, but the installer was pretty barebones for such a nice customizable distro.

Debian testing. I wound up just picking 'standard system' since I'm pretty sure the top one installs X and poo poo and this was going to be a dev VM.

# ? Jan 31, 2012 02:42

shrughes: Oct 11, 2008; (call/cc call/cc)

yaoi prophet posted:

Debian testing. I wound up just picking 'standard system' since I'm pretty sure the top one installs X and poo poo and this was going to be a dev VM.

X is still useful, you know.

# ? Jan 31, 2012 03:16

ijustam: Jun 20, 2005

Geekner posted:

ArchLinux? I haven't installed it in a while, but the installer was pretty barebones for such a nice customizable distro.

That's some hardcore barebones.

# ? Jan 31, 2012 04:00

Look Around You: Jan 19, 2009

tef posted:

We're all terrible.

Rust is 0.1 - much of the effort put into it is to see if certain language features can work together to build robust code. The syntax especially is being worked out as they write more and more code in it - the language has changed considerably (from what I have noticed) as they have gotten to the fully bootstrapped stage.

If you want to talk about issues in the language, the developers are fairly active on irc and answered a whole bunch of my stupid questions eventually - they will probably be more qualified to answer your questions than anyone here.

[...]

really I don't want to defend rust here but only to say that it hasn't been properly introduced. if you're curious about it I would highly recommend the faq and the design docs over what has been poorly explained here. I think rust deserves a fair trial*.

even so I still don't get the whole magic semicolon thing

* rob pike has somewhat angry words about this http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html - to some extent it is right, but at other times it can be a failure to communicate the design constraints of the language.

Basically yeah, I didn't try it and was talking about impressions I got from the documentation. Interestingly enough, while I was writing that post I was compiling the Rust compiler/toolsuite. I still haven't gotten around to trying it yet but it does look interesting. It certainly wasn't fair of me to pass judgement without trying it.

That said I still have some confusion about the ; thing and the () for nil thing, but overall they're pretty minor. (the problem I have with () for nil is that in rust specifically tuples need to have arity strictly greater than 1, so an empty tuple for nil doesn't really make much sense to me.)

# ? Jan 31, 2012 05:15

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

the talent deficit posted:

you're going to have to explain how a compiler can infer whether input will lie in a specified domain

Rust is statically typed, so the compiler already knows the full input domain, and whether there are any unmatched portions of it for any given alt expression.

# ? Jan 31, 2012 07:19

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Janin posted:

Rust is statically typed, so the compiler already knows the full input domain, and whether there are any unmatched portions of it for any given alt expression.

no it doesn't. tell me how to statically check this:

code:

fn main(args: [str]) { 
  alt args[1] {
    "janin" { io::println("you're an idiot") }
    "zombywuf" { io::println("so are you") }
  }
}

Look Around You posted:

That said I still have some confusion about the ; thing and the () for nil thing, but overall they're pretty minor. (the problem I have with () for nil is that in rust specifically tuples need to have arity strictly greater than 1, so an empty tuple for nil doesn't really make much sense to me.)

the semi colon performs two functions in rust. one is as a statement terminator:

code:

fn() -> () { };
let x = foo();

the other, less obvious use, is as a sort of expression concatenation operator:

code:

{
  foo();
  bar();
  baz()
}

{ foo(); bar(); baz() }

in blocks (the things in braces) that have no explicit ret, the last expression (baz() in the preceding example) is implicitly converted to a ret statement. this is useful for things like alt blocks, if blocks, etc.

a valid criticism would be that two similar but different bits of syntax use the same glyph, but i think that is probably because the rust developers saw the criticism erlang got for it's varied expression terminators and chose to hew as close as possible to algolish languages.

the talent deficit fucked around with this message at 08:23 on Jan 31, 2012

# ? Jan 31, 2012 08:04

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

I'm pretty sure the compiler can work out that the str type can contain more than two possible values, and thus that in the absence of a default case the code is missing something.

# ? Jan 31, 2012 08:20

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Jabor posted:

I'm pretty sure the compiler can work out that the str type can contain more than two possible values, and thus that in the absence of a default case the code is missing something.

the default case is not required, which is the point. that is a perfectly valid (and sensible) rust program.

the compiler has no idea whether that alt block will receive a valid string. it can only possibly be a runtime error.

# ? Jan 31, 2012 08:25

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Dude that was harsh, you totally called those guys out in Rust code.

# ? Jan 31, 2012 08:34

Zombywuf: Mar 29, 2008

the talent deficit posted:

no it doesn't. tell me how to statically check this:

code:

fn main(args: [str]) { 
  alt args[1] {
    "janin" { io::println("you're an idiot") }
    "zombywuf" { io::println("so are you") }
  }
}

Type error: could not infer type "janin" | "zombywuf" from str

But yeah, you had every opportunity here to provide an example showing that such an inference mechanism would involve solving the halting problem, in wich case I would only be left with the argument "Don't include unsound features in your typesafe language." Instead though, you presented a program that has an infinite number of ways of crashing at runtime as an example of Rust's safety features. Well done.

quote:

the semi colon performs two functions in rust. one is as a statement terminator:
code:
fn() -> () { };
let x = foo();
the other, less obvious use, is as a sort of expression concatenation operator:

off the top of my head all of these are better:

code:

{
  foo();
  bar();
} = baz()

{
  foo();
  bar();
  return baz();
}

returning x {
  foo();
  bar();
  x = baz();
}

You're never going to sell me on that semicolon.

# ? Jan 31, 2012 09:45

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

How about

code:

{
    foo();
    bar();
    baz();
}

Just return the last thing evaluated if there's no explicit return. Discourage people from using this implicit return outside of one-liner anonymous functions.

# ? Jan 31, 2012 09:56

Volte: Oct 4, 2004; woosh woosh

OCaml uses the semicolon for the same purpose, but it does not do anything weird with returning unit.

code:

# let a = (printf "hello "; 5;);;
hello val a : int = 5

Also, pattern matching should be exhaustive unless maybe if the return type of the match is unit, otherwise you're leaving yourself open to domain errors that could be easily detected at compile time. Can the rust alt statement return values, or do they just execute statements like a switch statement in C?

# ? Jan 31, 2012 10:08

Look Around You: Jan 19, 2009

The problem I have with "a block returns it's last value if it has no semicolon" is a couple things.
Here's an example which compiles fine and acts like you'd expect:

code:

use std;

fn main(args: [str]) {
	let s = args[1];
	let aval = alt s {
		"a" { std::io::println("aval is 1 now"); 1 }
		"b" { std::io::println("aval is 2"); 2 }
		"c" { std::io::print("aval "); std::io::println("is 3"); 3 }
		_ { std::io::println("better set it to 4"); four() }
	} ;
	std::io::println(#fmt("aval is %d after the alt", aval));
}

fn four() -> int {
	// we can comment out ret 4; and uncomment the following line
	// and still compile
	// 4
	ret 4;
}

This however is invalid:

code:

use std;

fn main(args: [str]) {
	let s = args[1];
	let aval = alt s {
		"a" { std::io::println("aval is 1 now"); 1 }
		"b" { std::io::println("aval is 2"); 2 }
		"c" { std::io::print("aval "); std::io::println("is 3"); 3 }
		_ { std::io::println("better set it to 4"); four(); }
	} ;
	std::io::println(#fmt("aval is %d after the alt", aval));
}

fn four() -> int {
	// we can comment out ret 4; and uncomment the following line
	// and still compile
	// 4
	ret 4;
}

code:

$ rustc test.rs
test.rs:9:4: 9:55 error: mismatched types: expected `int` but found `()` (types differ)
test.rs:9 		_ { std::io::println("better set it to 4"); four(); }
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous errors

So yeah I guess that's why I don't really like having a ';' be the difference between "return the value of the last expression" and "return ()/nil"

The error descriptions that the compiler generates are pretty good but that's kind of a weird, subtle bug IMO.

# ? Jan 31, 2012 13:54

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

the talent deficit posted:

no it doesn't. tell me how to statically check this:

code:

fn main(args: [str]) { 
  alt args[1] {
    "janin" { io::println("you're an idiot") }
    "zombywuf" { io::println("so are you") }
  }
}

GHC does exactly this. If there are unmatched cases, it prints them (as a warning, though, not an error). You could easily do the same thing for Rust.

I don't understand why you claim this is impossible. The compiler knows the input domain (all strings). It knows the available cases (a subset of strings). If there is no default case, then it knows the 'alt' expression is incomplete.

The error message would look something like:

code:

Warning: Pattern match(es) are non-exhaustive
  Patterns matched:
    "janin"
    "zombywuf"
  Patterns not matched:
    all others

# ? Jan 31, 2012 17:51

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Janin posted:

GHC does exactly this. If there are unmatched cases, it prints them (as a warning, though, not an error). You could easily do the same thing for Rust.

It's trivial to detect non-exhaustive patterns, I never claimed it wasn't.

I was refuting the claim that non-exhaustive patterns should be a type error and not a runtime error.

# ? Jan 31, 2012 18:42

shrughes: Oct 11, 2008; (call/cc call/cc)

It seems to me like requiring exhaustive patterns makes sense for some types but not other types. Some types are small algebraic types, with a handful of cases that can be completely enumerated. These should require all cases to be handled explicitly. There are also integer types. These should fail with a run time error when a case isn't handled. That's better than, for example, infinitely looping when an erroneous negative input is given.

# ? Jan 31, 2012 19:10

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

the talent deficit posted:

It's trivial to detect non-exhaustive patterns, I never claimed it wasn't.

I was refuting the claim that non-exhaustive patterns should be a type error and not a runtime error.

You haven't refuted anything, though.

Zombywuf originally posted that a non-exhaustive pattern should cause a compile-time error. You posted that the compiler can't do this, even though it obviously can.

shrughes posted:

It seems to me like requiring exhaustive patterns makes sense for some types but not other types. Some types are small algebraic types, with a handful of cases that can be completely enumerated. These should require all cases to be handled explicitly. There are also integer types. These should fail with a run time error when a case isn't handled. That's better than, for example, infinitely looping when an erroneous negative input is given.

all non-exhaustive patterns should be compile-time errors. If the user "knows" that the input is more restricted than the types imply, they can add a [[ _ -> BlowUp() ]] case themselves.

# ? Jan 31, 2012 22:32

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Go Twitter!

# ? Feb 1, 2012 14:57

taqueso: Mar 8, 2004

Suspicious Dish posted:

Go Twitter!

They are going to have a lot of typing to do when the number of seconds in a minute changes. (Ya, I know it is generated by a script)

taqueso fucked around with this message at 16:35 on Feb 1, 2012

# ? Feb 1, 2012 16:33

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 00:38

Dicky B: Mar 23, 2004

code:

#define IS_NON_ZERO_0  0
#define IS_NON_ZERO_1  1
#define IS_NON_ZERO_2  1
#define IS_NON_ZERO_3  1
#define IS_NON_ZERO_4  1
#define IS_NON_ZERO_5  1
#define IS_NON_ZERO_6  1
#define IS_NON_ZERO_7  1
#define IS_NON_ZERO_8  1
#define IS_NON_ZERO_9  1
#define IS_NON_ZERO_10 1
#define IS_NON_ZERO_11 1
#define IS_NON_ZERO_12 1
#define IS_NON_ZERO_13 1
#define IS_NON_ZERO_14 1
#define IS_NON_ZERO_15 1
#define IS_NON_ZERO_16 1
#define IS_NON_ZERO_17 1
#define IS_NON_ZERO_18 1
#define IS_NON_ZERO_19 1
#define IS_NON_ZERO_20 1
#define IS_NON_ZERO_21 1

#define IS_NON_ZERO(n) IS_NON_ZERO_ ## n

# ? Feb 1, 2012 18:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »