00:02 (quit) mye__: Ping timeout: 256 seconds 00:13 (quit) jonrafkind: Ping timeout: 252 seconds 00:19 (join) dented42 01:07 (quit) lem_e_tweakit: Ping timeout: 240 seconds 01:07 (quit) hash_table: Ping timeout: 240 seconds 01:07 (quit) getpwnam: Ping timeout: 240 seconds 01:07 (join) mye__ 01:11 (quit) mye_: Ping timeout: 276 seconds 01:19 (join) nilyaK 01:20 (quit) nilyaK1: Ping timeout: 246 seconds 01:38 (quit) dented42: Quit: Computer has gone to sleep. 01:40 (join) dented42 01:40 (quit) jao: Ping timeout: 246 seconds 01:40 (quit) dented42: Remote host closed the connection 01:43 (join) mye_ 01:46 (quit) mye__: Ping timeout: 246 seconds 01:47 (join) dented42 02:00 (join) ambrosebs 02:15 (quit) mye_: Ping timeout: 260 seconds 02:24 (quit) ambrosebs: Ping timeout: 250 seconds 02:28 (join) kvda 02:55 (quit) mithos28: Quit: mithos28 03:03 (quit) kvda: Quit: Computer has gone to sleep. 03:53 (join) antithesis 04:32 (join) stis 04:42 Shambles_: What is the "box" type good for anyway? 05:12 (quit) jyc: Read error: Connection reset by peer 05:21 (join) sid0 05:30 (join) bitonic 05:46 (join) kvda 06:00 (join) masm 06:03 (quit) m4burns: Ping timeout: 244 seconds 06:06 (join) mceier 06:15 (quit) soegaard: Ping timeout: 245 seconds 06:40 (quit) nilyaK: Quit: Leaving. 06:48 (join) netrino_ 06:57 (join) plobzik 06:59 (quit) plobzik: Read error: Connection reset by peer 07:54 bremner: Shambles_: pass by reference 08:24 (join) Shambles_1 08:26 (quit) Shambles_: Ping timeout: 244 seconds 08:27 (quit) Shambles_1: Client Quit 08:34 (join) Shambles_ 08:36 Shambles_: bremner: Thank you. 08:36 Shambles_: bremner: Not sure what to make of the answer though. Aren't most large things passed by reference anyway 08:37 bremner: Shambles_: think about mutating a parameter passed into a procedure. set! doesn't work for this. 08:41 (join) lem_e_tweakit 08:41 (join) getpwnam 08:42 (join) hash_table 09:39 (join) RacketCommitBot 09:39 RacketCommitBot: [racket] plt pushed 2 new commits to master: http://git.io/06I_fg 09:39 RacketCommitBot: [racket/master] fix Scribble module languages to allow submodules - Matthew Flatt 09:39 RacketCommitBot: [racket/master] doc layout repair - Matthew Flatt 09:39 (part) RacketCommitBot 09:44 (join) djcb 09:50 (join) ambrosebs 09:53 Shambles_: bremner: Okay, that made sense. 10:34 (part) aidy 10:35 (quit) netrino_: Quit: Ave! 10:36 (join) netrino 10:36 Shambles_: Since structures and classes seem to have a lot of overlap, are there any guidelines for when to choose one over the other? 10:46 Cryovat: I'm a newbie, so take my word with a grain of salt 10:46 Cryovat: But I'd say use structures when you're not in need of inheritance 10:46 Cryovat: And think that the data will stay fairly stable throughout the lifetime of your program 11:04 (join) jao 11:05 (quit) jao: Changing host 11:05 (join) jao 11:07 (join) dzhus 11:08 (quit) kvda: Quit: x__x 11:15 (join) mithos28 11:27 (join) m4burns 11:34 (join) jacius 11:43 (quit) ambrosebs: Ping timeout: 260 seconds 12:07 (join) ambrosebs 12:20 (join) jonrafkind 12:38 (quit) antithesis: Quit: yes leaving 12:39 (join) mye 12:42 Shambles_: Cryovat: It appears that structs have inheritance. 12:44 (join) mye_ 12:44 (quit) ambrosebs: Ping timeout: 256 seconds 12:47 (quit) mye: Ping timeout: 250 seconds 12:48 (join) ambrosebs 13:03 (join) tyson1 13:05 (join) mye__ 13:08 (quit) ambrosebs: Ping timeout: 244 seconds 13:09 (quit) mye_: Ping timeout: 244 seconds 13:37 asumu: Shambles_: There aren't any official guidelines, but I would use classes if you need methods and late binding. 13:37 asumu: Structs are (usually) more about data than your behavior. Classes tie those together. 13:38 (join) untrusted 13:39 (part) tyson1 13:40 (quit) karswell: Remote host closed the connection 13:44 Shambles_: asumu: I wasn't even sure about that, since 'data' in a language like Racket isn't really cleanly separated from 'code'. I guess I should pretend that structs are as limited as they are in C++, and use classes where I'd use them instead of structs in C++? Is there a significant performance difference? 13:47 jonrafkind: structs are the same as classes in c++, jfyi 13:48 offby1: really 13:48 offby1: ? 13:48 bremner: except for default visibility 13:48 offby1: I thought C++ classes "contained" functions or methods or whatever they call 'em 13:49 offby1: oh, you meant "C++ structs are the same as C++ classes". 13:49 bremner: yes\ 13:49 offby1: I though you meant "Racket structs are the same as C++ classes". 13:49 offby1: this is what comes of multitasking. 13:49 offby1: offby1 is on channel(s): #ruby #scheme #racket #github #git #emacs ##cinema 13:49 Shambles_: jonrafkind: Not without a lot of pain. No inheritance. Methods can't be called directly (you'd have to use pointers). Structs are pretty much the same as they are in C. You can bludgeon them into doing what objects do. Getting 'real' OO out of it is a lot of work, though. 13:49 offby1: and eating a chicken sandwich and playing with the cat 13:49 jonrafkind: no they are the same 13:50 jonrafkind: except that struct uses public: by default and class uses private: 13:50 bremner: Shambles_: sorry, your wrong here. Back to the C++ text ;) 13:50 jonrafkind: i know im being pedantic and i knoww hat you mean, you are comparing C structs to the c++ object system 13:50 bremner: also, you're wrong ;) 13:50 (join) karswell 13:50 offby1: also, gimme back my bike 13:51 bremner: it's in the shed 13:51 Shambles_: bremner: Did it in college. Spent a big chunk of last year fixing someone else's C++ code. I'll touch it when I have to now, thank you. I hate the language. Took everything I didn't like about C (which I mostly like, keeping in mind "it was a good thing at the time", which excuses some mistakes), and made it worse. 13:52 bremner: Shambles_: ok, well, you'll just have to take our word for it. In modern C++, structs are just classes with default public visibility 13:52 offby1: Shambles_: I doubt you'll find much disagreement here 13:52 Shambles_: bremner: Won't be going back to any texts. I do know how structs behave in C quite well. It's a pretty straight up 'record' type. With function pointers you can achieve methods, and by chaining structs together with a lookup method you can get inheritance. Doesn't mean structs 'are the same as classes', at least in C. Just that you can get from there to here. 13:52 Shambles_: bremner: In much the same way that metal ore is not a car. 13:53 bremner: Shambles_: well, we seem to be talking past each other. structs in C++ are much different than in C 13:53 Shambles_: bremner: I see what you're referring to now. Apparently C++ extended structs, so you can ugly up your code by calling thing structs when you mean classes. 13:53 bremner: yes 13:55 Shambles_: bremner: If you haven't figured out what I was trying to say before, it was "pretend the structs are as limited as they are in C" (I didn't know or had forgotten about that C++ design flaw) "and use classes where I'd... have to use C++ or go through a lot of work to do the same thing with structs in C". It reads a lot less clear this way. 13:56 Shambles_: The question remains as to "how do I know which to choose" since right now it looks like I could do everything I'd want to do with classes with structs. I'm not sure if one performs better than the other. The guide doesn't seem to give any guidance on the matter. 13:57 bremner: at a wild guess, the thing with the least features performs the best 13:57 offby1 nods gravely 13:57 offby1 gestures lovingly towards his hammer 13:57 bremner switches to ed to edit text 13:58 offby1 points with bitterness at his Brother Printer/Fax/Copier/Toaster 13:58 bremner: use the hammer! 13:58 offby1: Please Brother Don't Hurt 'Em 14:04 (quit) untrusted: Remote host closed the connection 14:04 (quit) dzhus: Remote host closed the connection 14:05 anonus: guys? is there flymake-mode for racket ? T_T 14:05 mithos28: flymake-mode? 14:05 anonus: yes, for emacs 14:06 bremner: anonus: what would that do exactly? 14:06 anonus: highlight errors on-fly of course 14:07 mithos28: Racket is impossible to parse (correctly) without running racket itself 14:07 bremner: I guess most racket+emacs users use some repl support mode like geiser; I'm not aware of something like that. 14:07 mithos28: let alone understand errors 14:07 bremner: where that=what you want 14:07 mithos28: Drracket has online syntax checking 14:07 anonus: of course it should run racket 14:08 anonus: for example erlang mode just pass the file to simple erlang script that just parse it and return all errrors 14:08 offby1: anonus: I suspect it'd be easy to get flymake-mode working for racket -- assuming it works at all :) 14:09 offby1: I think flymake-mode just runs the command of your choice; as long as that command emits output that emacs can parse, it should work. 14:09 mithos28: what would it do once the parenthesis match up? Compile it, to make sure its valid? 14:09 offby1: mithos28: flymake-mode's purpose in life is pointing out syntax errors so that emacs can highlight them. If the program is clean, I think it does nothing. 14:10 mithos28: what are syntax errors in racket? 14:10 offby1: anything that makes racket emit a warning or error at compile time. 14:10 mithos28: reader errors or errors during expansion 14:10 mithos28: expansion might have effects 14:10 Shambles_ personally writes stuff in EMACS, and pastes the code into a IDE to check the syntax and run it. I use EMACS for the spell checking and more pleasant (to me) editing. My text mode is set up to automatically load spell checking and bracket matching extensions. That's not just Racket. I do the same thing in other languages. 14:10 offby1: i.e., anything that would make "raco --make" fail or warn. 14:11 offby1 calls the /me police on Shambles_ 14:11 Shambles_: Why's that? :P 14:11 mithos28: ok, but assuming that raco make is safe to run all the time is not a valid assumption 14:11 offby1: Shambles_: pronoun agreement, son; pronoun agreement 14:11 offby1: mithos28: ah, good point. What evilness is it likely to get up to? 14:12 Shambles_: I could have written two lines, but it wouldn't have changed much. 14:12 mithos28: downloading code off the internet and running it 14:12 offby1: mithos28: true, but ... you'd probably have done that by hand at some point anyway 14:13 mithos28: I'm not saying it is impossible to do, I'm just saying that checking for 'syntax' errors in racket is not as easy at it is for other languages 14:14 mithos28: also using typed racket, where checking for errors would take a while 14:14 mithos28: I'm not sure if flymake runs consistently or on demand 14:14 Shambles_: I'm of the opinion that human language is rather like programming in some awful probabilistic version of C++ (let's hope quantum computing doesn't make this a reality). I'm not convinced it's worth checking the syntax and formally verifying everything. It's not like anything gets communicated without severe damage to the original intent anyway. 14:15 Shambles_: Gee, that's very existentialist. 14:18 (join) snearch 14:19 (join) Fare 14:20 offby1: Shambles_: I dunno about you, but I've been using racket, perl and python for years, and Lord how I'd like some compile-time type checking. 14:20 offby1: Looking into Typed Racket now, of course 14:21 mithos28: TR is nice, other than the slow compile time 14:21 mithos28: and sometimes brokenness 14:22 Shambles_: offby1: I don't seem to run into type errors. I've never had the 'method does not exist' issue, or assigned to a misspelled variable name. I really can't imagine the former happening in practice. The only reason the latter doesn't happen is probably because I spell-check everything and use real words for most things. 14:22 Shambles_: offby1: On the other hand my programs regularly end up with nonsense values, especially after running a while, so I'm quite pleased with things like design by contract. You can get addons for that for Python. 14:23 mithos28: I run into type errors all the time. Which list operators take the list as the first argument, or as the second? 14:23 mithos28: Where does the accumulator go in the function to foldr? foldl? Why does this not match other languages? 14:23 Shambles_: I tend to look at the documentation, or use what IntelliSense says about the arguments. 14:24 mithos28: right, but without tools like IntelliSense you would make stupid errors like that 14:25 mithos28: Also you get IntelliSense for racket? 14:25 Shambles_: mithos28: I suppose that's true. I'd be assigning to misspelled identifiers without spell-checking too. The tools exist, and don't really take any effort to use. For Python I spend a lot of time screwing around in IPython, which solves whatever problems my spell checking habit doesn't. 14:27 mithos28: I don't get your point. You say you don't run into static errors, because you have tools that find them? 14:28 mithos28: You still have the errors, just that the tools let you find them before running the program 14:28 Shambles_: mithos28: EMACS has a nice feature, possibly not intentional, that anything duplicated in series (e.g. "and and"), or any misspelled word also seen before shows up in yellow, but /new/ (first encountered) misspelled words show up in red. That means even if you name your variables p32xploSpcMod you're unlikely to mistype the variable name and not know (if it's red, it's bad, except the first time, if it's yellow, it's okay). 14:29 Shambles_: mithos28: Oh, yes, but that's what is important now isn't it. Either finding the bugs before you run the program, or, if that's not possible or practical, finding and fixing them with the least amount of effort after. I don't care one whit that I have errors in my code, so long as they don't make it to run time. 14:29 Shambles_: mithos28: Further, I don't see how (ab)using the spell checker and a IntellSense-like tool is any different than static type checking, only I don't have to write a whole bunch of extra crap to get things done. 14:30 mithos28: Its not. 14:30 Shambles_: mithos28: The static type checking is also a 'tool that lets you find the errors before running the program'. 14:31 mithos28: Nevermind, I think I misinterpreted something you said. 14:33 (join) dzhus 14:34 Shambles_: mithos28: Funny thing is I don't actually have a strong opinion on static or dynamic type checking. The only thing along those lines that I care about is: (1). there absolutely *should* be 'safe' typing, by all means blow up on me at run time with a meaningful error if you must, but /do not/ go do something wacky and seemingly unrelated to the code (2). I lothe complex type systems that are not sufficient for full formal ver 14:36 Shambles_: mithos28: I find COBRA quite pleasant to use. C# has absorbed all it's features except the better syntax and null pointer static checking. It is (primarily, you can ask for dynamic typing) statically typed. I get along well with Python too, though I'm trying to move to Racket for most things to get some features that don't exist in Python. 14:37 (quit) djcb: Read error: Connection reset by peer 14:37 mithos28: racket is statically typed, not with a very expressive/useful type system. What do you mean between static and dynamic typing? 14:38 Shambles_: mithos28: I'm not sure I understand the question. 14:38 (join) djcb 14:38 mithos28: I'm playing devil's advocate and saying all languages are statically typed 14:39 jrslepak: just that some only have one type? 14:39 mithos28: jrslepak: yes 14:39 Shambles_: mithos28: I don't see how you can make that claim. Either the variables have a type that defines what kind of value you can place in them, and is generally checked at compile time, or the values have a type that 'follows them' as they are copied around, and it is generally checked when a operation is attempted at run time. 14:40 mithos28: racket values have the type RacketValue 14:41 mithos28: some operations are not total 14:41 mithos28: just like / in most languages 14:41 (quit) jonrafkind: Ping timeout: 252 seconds 14:42 Shambles_: That might be possible in some theoretical sense, but in practice, even assembly language has some notion of type. Everything is either a integer or floating point number of one of a limited set of bit-widths. It just isn't a "safe" type system. You can treat a floating point number as a integer, and you can add two integers representing characters together. 14:43 (join) jyc 14:43 mithos28: why is that not safe, what are you defining as safe? 14:44 Shambles_: It's possible to have a useful language with only one type (integer, as in assembly for machines that don't support floating point), and with no partial functions (that I can think of anyway... 8-bit processors don't usually have division built in). 14:44 mithos28: Also yes I am talking theoretically, as I am talking about languages not implementations 14:46 Shambles_: Safe: The common sense notion that certain things are pointless or even harmful. A programming language (above assembly, at least) should refuse to perform 5 + "cat" either at compile or run time, rather than adding 5 to the pointer aimed at the string's location in a data segment. 14:46 mithos28: I don't get your point. How does that detract from my point that all languages can be considered to have a trivial type system, and all operators might be partial. 14:47 mithos28: 5 + "cat" => "5cat" 14:49 Shambles_: mithos28: Except nobody would want that. If you wanted to insert a number in a string, you would at least be expected to write something like result = str(5) + "cat" 14:49 mithos28: I don't get that point, the language must say what happens when 5+"cat" is evaluated. And then by definition it is correct and safe. 14:50 Shambles_: mithos28: From a purely "I have no common sense" point of view, there's nothing wrong with the "add 5 to the pointer aimed at the start of the string in the data segment". It's fully defined. It's not what anybody would *want*, but it's defined. 14:51 mithos28: Why are you turning "cat" into pointer? 14:51 bremner: because C? 14:51 mithos28: bremner: And C is wrong. 14:51 Shambles_: mithos28: Who said anything about 'turning it into' anything. A string constant in C *is* a pointer (to a location in the data segment blah blah blah). 14:52 mithos28: Why are we in C? 14:52 Shambles_: mithos28: If C is wrong, I suspect you know what I'm getting at, and this is some weird pointless academic mind game. 14:53 mithos28: yes, that is why I prefaced it with I am playing the devil's advocate 14:53 Shambles_: mithos28: Otherwise, really, the point in type systems is not some academic sense of mathematical elegance, or purity, or 'completeness'. It's to handle errors. 14:53 Shambles_: mithos28: I'm not sure what you're advocating. 14:53 mithos28: That all languages are statically typed. 14:54 mithos28: The type system just doesn't rule out any programs 14:54 mithos28: that pass parsing (that is) 14:54 Shambles_: mithos28: This is true, to the extent that Brainfuck is "as good as any other programming language" because it's Turing-complete. It's also as false as that statement, for obvious reasons. 14:55 mithos28: No because it is not as expressive as other languages 14:55 mithos28: Turing-completeness is not the be all end all, of expressiveness 14:55 Shambles_: mithos28: Why do you care about expressiveness? 14:57 mithos28: Because that is the point of languages. To turn a term into a meaning. 14:57 Shambles_: mithos28: Brainfuck is Turing complete. It can still turn any term into meaning. 14:58 mithos28: That is not what expressiveness is. 14:59 Shambles_: mithos28: And I asked you why you care about expressiveness. You said it was so you could turn terms into meaning. I explained that you don't need any more expressiveness than Brainfuck has for that. 14:59 mithos28: I am using expressiveness as in http://www.google.com/search?client=safari&rls=en&q=felliesen+expressiveness&ie=UTF-8&oe=UTF-8#hl=en&client=safari&pwst=1&rls=en&sa=X&ei=9z65T5fJLZDKiALj1OWhBw&ved=0CDoQvwUoAQ&q=felleisen+expressiveness&spell=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=17c6eb2a8dc3e7bb&biw=1280&bih=664 14:59 rudybot: http://tinyurl.com/7h6b7u8 14:59 Shambles_: mithos28: Maybe you meant you care about expressiveness for some other reason. 14:59 mithos28: first link 14:59 mithos28: I also would like to compose terms 15:00 Shambles_: I know what it means. It's how little you have to write to 'depict' a algorithm. 15:00 Shambles_: mithos28: Why do you want to compose terms. 15:00 Shambles_: mithos28: I can do this all day. You know the *real* reason you care about expressiveness, and composing terms. 15:01 mithos28: No actually I don't, but that is getting too existential. 15:03 mithos28: I would like to express certain meanings, and the easiest way that I know how to do that is with composing terms of related meanings together. 15:03 Shambles_: mithos28: The real reason you care about this stuff is it saves you time. It saves you a lot of extra typing. Guess what? That's the reason real type systems should be safe, and have more than one type. It's not *fun* spending 1 to 3 days to figure out some horrible C++ program crashed due to a mistake in a method called 15 minutes ago, that corrupted data, that was read somewhere really far down the line. 15:04 Shambles_: mithos28: Generally speaking "playing devils advocate" from a extreme academic standpoint, doesn't get you anywhere (other than people angry at you). Deep down most programmers know what they do doesn't /usually/ (graphics, compression, and some other areas are exceptions) involve any fancy mathematics. 15:05 Shambles_: mithos28: 'Computer science' that's worthwhile (i.e. will actually get used in real life) is about making real machines do useful work with as little effort as possible, as fast as possible. 15:05 mithos28: And what If I am an academic, interested in this for academic reasons. 15:06 Shambles_: mithos28: That's not to say some understanding of the underlying theory is worthless. Just anything that says all languages are type checked, just some only have 1 type, has wandered way off into academic wanking land. 15:06 Shambles_: mithos28: I think you got lost looking for the mathematics department then. 15:07 mithos28: CS is a math. 15:08 mithos28: You still have type errors in 'statically typed' languages null pointers, division by zero, case clauses that are not encompasing 15:09 Shambles_: Some people make that claim (Djikstra was famous for it). It does make me wonder how art students would react if chemists took over and claimed that their craft was really a branch of chemistry, because chemistry can describe and be used to craft custom pigments. I think about as much of art would be lost in the process as computer science as mathematics. 15:09 mithos28: Would you really say that algorithms is not math? What about crypto? Type theory/Programming language Theory? 15:10 mithos28: I agree that software is not math, but CS is not software. 15:11 Shambles_: mithos28: Unless you're going to have a mighty loose definition of 'math' you'd be missing things like how choice of syntax effects the prevalence and kind of errors in a programming language. Does syntax matter? Seen lots of math-heads that claim it doesn't. Also seen lots of people paying for C's mistake of choosing the = and == operators, and having overly permissive notions of expressions. 15:13 Shambles_: mithos28: There are workarounds for those problems you mentioned. COBRA prevents null pointer errors by having a 'nullable' vs 'non-nullable' pointer (really reference), and to pass a nullable pointer to a non-nullable type, it must pass through a if-test that checks if it's null (and nothing else) first. 15:14 Shambles_: mithos28: You can bludgeon numeric values into different types, one of which can be non-zero, which is a popular passtime with formal verification folks that like everything to be expressed as types. switch-case was one of those "computer science all math, nothing else matters" mistakes we're still paying for in most languages. 15:15 Shambles_: mithos28: Some don't have fallthrough, some make you state fallthrough explicitly (rather than break, which is what's usually desired), some cause a run time error if it reaches the end and there's no 'default' case. If the language's case statement is restricted enough you can even statically check the range. 15:16 Shambles_: mithos28: I think some languages have done the latter by restricting switch-case to characters and integers, but I can't give you a name. I'm tempted to say Ada, but it might be SPARK I'm thinking of, which is usually formally verified. I think some of the less-hardcore correctness-oriented languages have done that thoug. 15:16 mithos28: Yes there are many choices to make in the surface syntax of the languages, but once you get past that what is not math? 15:17 mithos28: Unless you want to define usability/usefulness. 15:17 mithos28: But then you are getting into the design of a language and not its theory. 15:19 Shambles_: mithos28: You need roughly a high school level education (no optional math classes required) to do basic grunt sysadmin programming. You won't see anything more complicated than addition, subtraction, multiplication, and division, with variables, most of the time. Most of the real problems in real programming have to do with bad language design (e.g. "=" vs "==", wrong defaults like C's switch-case fallthrough, and so on). 15:19 mithos28: Or bad language choice. 15:20 Shambles_: mithos28: And then there's areas that are technically mathematics but aren't what most people would think of as it, such as graph theory, which does see some practical use in screwing with data structures real people might see doing real tasks. You can even excuse some of what they do as abstract algebra, if you want to make sure the transformations don't ever corrupt anything. 15:20 (join) yoklov 15:20 (join) antithesis 15:21 Shambles_: mithos28: Bad language /design/ usually has very little to do with mathematics, and a whole lot to do with common sense, and knowing the kinds of errors people tend to make. For example adding or omitting a single character, or transposing neighboring characters, is common. Any language where doing that is likely to 'still have meaning' (lex/parse correctly) is error prone. It'll be especially error prone if the omission i 15:22 ChibaPet: That reminds me. I need to play with Paredit. 15:23 Shambles_: mithos28: For example, people notice 'stuttered' (the same) characters less than differing characters. That makes := for assignment and = for equality a better choice than = for assigment and == for equality, not that that's anything new. Of course <- for assigment and = for equality would probably be even better. 15:23 ChibaPet: ← 15:24 mithos28: ChibaPet: Unicode as a regular thing to type in a language is awful. 15:24 mithos28: Unless you have a new input method that makes it easy to type 15:25 ChibaPet: Yeah, I think that's the issue - ease of access. 15:25 yoklov: == for equality and = for assignment has enough history that doing it differently comes with its own downsides 15:25 Shambles_: mithos28: You were right the first time. The 'new input method' has been tried. The result still makes some people squirm. Look up APL, also known as "programming in the Klingon character set". 15:26 mithos28: Agda is a more current example 15:26 yoklov: but apl still was successful and saw commercial use 15:26 mithos28: Also I think my second statement still holds, it was qualified on easyness to type 15:27 (quit) snearch: Quit: Verlassend 15:27 (join) tyson1 15:28 Shambles_: So does Perl, which has "make a ass of u and me" ("do what I mean") as a feature. That doesn't mean they were good designs. Good things about APL were the array operations, and, if memory serves, everything was point-free and there was no priority system for expressions, just like Forth and Joy. None of that required the hideous syntax though. 15:28 (part) tyson1 15:28 yoklov: but i'd much rather have a language have a good (i.e. not fractured) definition of equality than it to use better syntax wrt assignment and equality. 15:29 mithos28: yoklov: what is a good definition of equality? 15:29 Shambles_: yoklov: I'd like a language that at least errored on "Oysters, oysters, oysters, chop, chop, chop" as a statement or expression, which is more than I can say for C and C++ (try it, stick a semicolon on the end if you have to). 15:30 yoklov: mithos28: i think clojure's has the best I know of, but it requires immutability for most things. haskell might have a similar one but I haven't written enough of it to say 15:30 Shambles_: yoklov: That said, I won't rip on C *too* bad. It was better than most Fortran-inspired languages before it, and it does what it was designed for pretty well. 15:31 mithos28: yoklov: What features of clojure's make it good? 15:31 yoklov: http://clojure.org/state 15:31 yoklov: is what i'm referring to as far as equality is concerned 15:31 yoklov: you don't have eq? vs. eqv? vs equal? vs = 15:32 Shambles_: I don't think Lisps have a huge issue with equality. A language needs to have at least two kinds of equality testing. One for testing if two things are *the same thing* (compare pointer/reference), and one for comparing if the /values/ are the same. I think Racket has 3 kinds, with "eq?" and "equal?" being the two I mentioned. 15:32 yoklov: Shambles_: i disagree 15:32 yoklov: it's needless complexity 15:33 Shambles_: In a language with 'complex' parsing very little should be valid in a expression. Assignment is one of those things that most definitely should /not/ be valid in an expression. 15:33 yoklov: how often do you _really_ need pointer equality? 15:33 mithos28: Racket also does cyclic structures correctly, which I don't think other languages have. 15:33 mithos28: Shambles_: Why have assignment? 15:33 yoklov: besides, a good equality checking function tests for pointer equality first 15:33 Shambles_: yoklov: Any time you are really pressed for speed, and know you will be comparing against a limited set (much like an enumeration). 15:34 mithos28: Shambles_: And then equal? <=> eq?, and so equal? should be optimized in that case. 15:35 Shambles_: mithos28: Because non-imperative I/O sucks horribly. If you don't know why, so play with Haskell. If you play with Haskell, and still don't know why I/O must be imperative to be acceptable, there is probably no hope for you, though it would explain the "computer science is just math" attitude. :P 15:35 yoklov: Shambles_: clojure does give you identical? to test if they're the same, but really you never need to do that 15:36 yoklov: (except in java-land sometimes) 15:36 mithos28: Shambles_: The only imperative I/O that haskell lacks is debugging IO 15:36 Shambles_: mithos28: If "equal?" is deep comparison then it will be slow, potentially *very* slow (think about comparing things in a tree, where each node is one of a small set of options), so "eq?" is still useful. 15:38 yoklov: Shambles_: honestly, i think thats usually a premature optimization 15:38 Shambles_: mithos28: For some value of 'imperative'. It's generally considered monadic, which outside the do-notation (relatively terse and readable way of expressing sequence), results in rather hideous code, and is even more fun in the light of mandatory lazy evaluation. But what the hay, it's 'purely functional', and that makes ____ happy. 15:38 mithos28: Shambles_: If equal? is not as fast as eq? but eq? and equal? always returns the same results. Then your compiler isn't sufficently smart, and I should work on that. 15:39 yoklov: well the dont always 15:39 yoklov: they* 15:39 mithos28: yoklov: in some cases they do 15:39 yoklov: right 15:39 mithos28: (lambda (x) (eq?/equal? x x)) 15:40 yoklov: two things that were eq? are equal 15:40 Shambles_: yoklov: It's all well and good to try to write something as clearly as possible. I'm very much for that. On the other hand, one should be very, very cautious about removing a feature known to be able to perform much better, just because it isn't *always* needed. I don't need a jet to go to the supermarket, but that doesn't mean nobody ever needs to use a jet. 15:40 yoklov: two things that are equal? aren't necessarially eq 15:40 (join) RacketCommitBot 15:40 RacketCommitBot: [racket] plt pushed 2 new commits to master: http://git.io/j61ksg 15:40 RacketCommitBot: [racket/master] dependency-cycle detection in parallel `raco setup' - Matthew Flatt 15:40 RacketCommitBot: [racket/master] slideshow: add `current-gap-size' and some `#:gap-size' arguments - Matthew Flatt 15:40 (part) RacketCommitBot 15:40 mithos28: My local supermarket doesn't have jet parking 15:41 Shambles_: mithos28: Use a Harrier. Park on the roof. 15:41 yoklov: Shambles_: not suggesting removing, but there's a distinction between identity and equality, and ignoring that distinction because sometimes it might be slow is a huge mistake 15:41 ChibaPet: A jet would make my commute better. 15:41 ChibaPet: Teleportation, better still. Tesseract, ideal. 15:41 Shambles_: yoklov: You said "how often do you need it". Admittedly, it's not that often, but it doesn't mean the language shouldn't have it, or is 'broken' for having it. 15:42 yoklov: if equal? tests first for identity, why do you need eq? 15:43 yoklov: either way, it should be availiable, but have a distinction between tests against identity and tests agains equality 15:43 chandler: rudybot: eval (equal? (mcons 1 2) (mcons 1 2)) 15:43 rudybot: chandler: your sandbox is ready 15:43 rudybot: chandler: ; Value: #t 15:43 Shambles_: Also, good luck with that inferring whether to use eq? or equal? thing. It'd be hard in most languages. It should be excruciating in a language without static types (real, not academic, static types; you know what I mean), especially one that can create and evaluate arbitrary code on the fly. You might be able to infer it 'sometimes', and that sometimes might be enough to help, though. 15:44 chandler: rudybot: eval (equal? (make-vector 4 0) (make-vector 4 0)) 15:44 rudybot: chandler: ; Value: #t 15:44 chandler: yoklov: Are you really suggesting that you can't see a reason to use eq? with those objects? 15:45 yoklov: chandler: well, mutation makes it nearly impossible to have a good definition of equality. 15:46 Shambles_: yoklov: You could get away with that (making "equal?" compare pointers), yes. It might be slightly slower in the case where you know the pointers differ, but not if the values do, however, since you're doing a extra check now. 15:46 yoklov: so? 15:46 yoklov: its a single check 15:47 yoklov: 1 extra comparison of two numbers 15:47 Shambles_: yoklov: The 'so' is the same reason for having 'eq?' in the first place. It can matter in a tight loop. 15:48 mithos28: Shambles_: I think you are optimizing for the wrong thing if you are worrying about eq? versus equal? and tight loops in the same language 15:48 yoklov: Shambles_: i don't think so, and i don't think that situation is really worth it 15:48 Shambles_: yoklov: I'll put it this way. I can't think of any language that /didn't/ have at least those two notions of equality. I don't believe computer science as a whole ignored the potential for one test of equality the whole time. That tells me there's a good performance reason not to do it that way. 15:49 yoklov: well the reason is you have state and as soon as you have state everything becomes a huge mess 15:49 yoklov: *unregulated state 15:50 chandler: I've used `cons' for the purpose of generating a fresh object, which means that the results of `eq?' are what matters, not the results of `equal?'. I could have used some kind of opaque atom type instead, but it wasn't necessary. 15:50 Shambles_: Even Python has those two notions of equality. Pointer comparison is always defined for you. Deep comparison requires you to define a method. That's another difference, though I guess you could just refuse to compare types that don't also define the method, rather than demanding people do the extra work for something they may never want to do. 15:50 yoklov: chandler: that's reasonable, and why i think that the option should exist, but that it should be clear that it's a test for identity, and not a test for equality 15:50 yoklov: the things are equal, but thats not what you care about then 15:50 chandler: If the order of comparison used by `equal?' was specified and deterministic, then adding an opaque atom type to the front of your objects would suffice as an `eq?' replacement, but that seems to be something that would inhibit optimization possibilities elsewhere. 15:51 Shambles_: yoklov: I've heard that stance before, and I'm about to say something that may make the room mad. I still believe it to be true, and I'm not trying to troll. 15:51 chandler: yoklov: So it's the name of `eq?' that bothers you? 15:51 yoklov: chandler: that's a large part of it, yeah. 15:51 chandler: OK, well, there are a lot of hysterical raisins in Racket, and not all of them are worth changing. 15:52 Shambles_: yoklov: First, state has been demonized in the functional programming community. Functional programming is a paradigm, which is quite handy for certain tasks (almost everything but I/O IMO). It's also not very handy for others. Functional programming doesn't use assignment. 15:52 yoklov: but more that it's considered a test for equality 15:52 chandler: It's considered a test for equality of identity. 15:52 yoklov: chandler: right, i wasn't suggesting changing it in racket 15:52 Shambles_: yoklov: Somehow we went from "this is a handy way to express a lot of things, and it happens to not use assigment" to "assigment is evil, and state must be eliminated!" 15:52 yoklov: i was just saying originally that i'd prefer a sane version of equality than different syntax for equality 15:52 yoklov: Shambles_: regulate your state 15:53 Shambles_: yoklov: Fact is, I can't think of *any reason* to use a program, except to manipulate state. All the stuff that matters to me, graphics, sounds, work I stored in files, is state. If a paradigm says we need to get rid of that, the paradigm is flawed. 15:53 yoklov: have an explicit reference to something, and have the reference be able to change 15:53 chandler: `eq?' is still an insane operator, though. I'd challenge anyone to find a situation where the difference between `eq?' and `eqv?' is useful, or a speed difference that's actually measurable. 15:54 yoklov: Shambles_: I'm not saying do away with state, just that if you do away with the idea that any variable can change its value, things become much simpler 15:55 Shambles_: yoklov: The other thing (the thing that is likely to piss off the room) is that you either mutate state, or mutate code. Functional programming does the latter. Most people won't own up to it, but 'creating' functions at run time by assembling them via (basically) function pointers, is basically self modifying code. Forgive me if I point out that self-modifying code doesn't exactly have a spotless reputation in the develop 15:56 chandler: Huh? Closures aren't self-modifying code at all, and they aren't required to program in functional style. 15:56 yoklov: yeah, i don't know if i follow you on that one 15:57 Shambles_: yoklov: The reality of all this is problably that: (1). state isn't so bad, some people just like to try to dodge the problem or sell snake oil, (2). self modifying code probably isn't so bad, especially if it only happens at certain points (a.l.a. function pointers), (3). sometimes the imperative paradigm is handy (e.g. I/O), sometimes others are (e.g. most other tasks), thankfully Lisp lets you choose rather than force feed 15:58 Shambles_: Chandler, if I write a function that assembles a function out of other functions and returns it, then how is it any different than self modifying code in any language that allows it? If each of the primitive operators is put in a function that can be used to assemble the one that is returned, it is exactly the same thing. Usually the division isn't that fine grained, but there's no inherant difference. 15:59 (join) zyoung 15:59 yoklov: honestly, i do a lot of (non-professional) game development, so i'm pretty familiar with the need for state, but i think a programming language which _doesn't_ have unrestricted state simplifies its model significantly, while not making itself significantly less useful 15:59 Shambles_: chandler: On the other hand, you're pretty screwed 'in real life' if you want to get rid of function pointers/references entirely. I'm just not convinced that mutating data *or* code is inherently inferior. To do 'real things' you'll have to do one on the other. 16:00 yoklov: Shambles_: I'm not suggesting not mutating any data, at the end of the day you have to mutate data. 16:00 chandler: Huh? Again, closures don't mutate code, and they're certainly not self-modifying. Think of them as a structure containing a function pointer and a context object containing the closed-over environment. 16:00 yoklov: just be explicit about which things you're mutating 16:01 Shambles_: yoklov: I believe avoiding mutation AND 'cute' code (including doing anything to fancy with higher order functions) is best for most things. It's best to have most of the program written in that style. Split the I/O code off. You'll have to anyway for unit testing, and if you ever decide to swap out the GUI toolkit, file formats, or whatever. Write the I/O imperatively. Write the rest in some kind of declarative style (n 16:02 chandler: Shambles_: FYI, your messages are getting cut off. There's a silent maximum message size limit on IRC. 16:03 yoklov: i think avoiding higher order functions in a functional language would be about as usful as avoiding state in an imperative one, except less so because higher order functions tend to reduce coupling, whereas mutation tends to increase it 16:03 yoklov: and IO is imperative, I agree. 16:04 Shambles_: chandler: This is a bit contrived, but let's say I create a loop using tail recursion. Inside that loop I create a function, then call it. It gets to return before the next pass of the loop. I can, for example, cause it to return functions that add a increasing (with each iteration of the loop) number to another number. This is all in functional style, but gets around maintaining the counter variable in the loop by creati 16:04 yoklov: I think haskell's IO suffers more from the laziness than being functional, however 16:04 chandler: Shambles_: You got cut off at "in the loop by creati" 16:04 Shambles_: chandler: I understand it's 'not mutating state', but the fact is the function doesn't *do the same thing* on each pass. 16:04 Shambles_: by creating functions. 16:05 yoklov: recursion is simpler than iteration though. 16:05 chandler: I'm not sure I understand your example. Either it's mutating state *somewhere* or the function does in fact do the same thing every time it's called with identical inputs. 16:05 yoklov: iteration you have things like 'break' and 'continue' just so that you can handle the things you might want to do 16:06 yoklov: with recursion you just call the next operation that you want to happen 16:06 Shambles_: yoklov: I didn't say avoid higher order functions. I said avoid unnecessary cuteness. Don't go sticking 1 or 2 operations in each function, then assemble the thing several layers deep and return it to the code that runs it when calling a single 10 line function would do. Sort of like don't mutate state unnecessarily, but don't go through lots of self flagellation to try to convince yourself you're still pure while committ 16:07 Shambles_: yourself you're still pure while committing the terrible sin of performing I/O. 16:07 yoklov: oh, alright then. 16:08 yoklov: any language that makes you think that performing IO is a sin is probably not intent on being useful. 16:10 Shambles_: yoklov: I don't agree that recursion is simpler than iteration. They're about the same, assuming tail-call position. Otherwise you /need/ those stack frames, and you'd either have to manage them manually (ugly) or use the language's stack frames (pretty and easy). 16:10 yoklov: iteration's a subset of recursion 16:11 Shambles_: yoklov: This is true, but without break and continue, the language will have (here it goes again) potentially serious performance problems in tight loops, and you end up sticking in lots of extra flags in your tests. 16:13 Shambles_: yoklov: The 'rules' are basically: (1). you never need to jump into a environment/context (usually pair of braces), (2). you should never jump past a initialization, (3). jumping *out of* braces, and forward (downward) is safe, and necessary for good performance (3). jumping out of and /backwards/ is never necessary for performance, but may save on code space. 16:13 yoklov: i mean, i'd assume that with most compilers that perform TCO, a recursive loop ends up being about the same code as a for loop 16:14 Shambles_: yoklov: You see 3 done in most all languages. I've only seen 4 (misnumbered 3 again, sorry; I mean the last one) done 'seriously' in assembly. 16:16 Shambles_: yoklov: Yes, TCO makes tail calls into loops. It's more like a 'until' loop (loop with test at the end) than a 'for' loop (loop that increases/decreases a value on each pass), but other things inside the function can achieve 'while' or 'exit in the middle' loops. 16:17 yoklov: i'm not concerned about that distinction. 16:21 (quit) jacius: Remote host closed the connection 16:22 Shambles_: chandler: If on each pass through the tail-recursive loop I pass (for example) an integer, which is used to construct the function, which adds to a number (perhaps itself, so it goes up exponentially), I am creating functions that add different amounts through each pass of the loop. It's basically while (true) { x = x + x } only inside we're 'mutating' functions (by passing arguments which get used to return new and differen 16:23 Shambles_: arguments which get used to return new and different functions) rather than state to get the increasing 'x'. 16:24 (quit) antithesis: Quit: yes leaving 16:25 yoklov: Shambles_: but you still have referential transparancy, right? 16:26 Shambles_: chandler: The usual reaction to this is "it's not /really/ mutating anything". My reaction is "yes it is, it's returning functions that do different things". I don't think it's any better or worse than the imperative version. Functional programmers usually think it's better. I'll just simply observe that 'functional programs still "go wrong"' and they seem to "go wrong" in about the same way you'd expect mutating state. 16:27 yoklov: you're missing the point 16:27 Shambles_: yoklov: Referential transparency means "the result of the function depends only on its arguments". The /strict/ answer to your question is "sort of". 16:27 (part) stis 16:27 Shambles_: yoklov: If you don't do something like "pass the state of the world" (their term, not mine) through your code, then yes, it's still referentially transparent. 16:28 yoklov: it sort of means that, but really it means that you can substitute any calls to the function with the function body itself 16:28 yoklov: replacing variables as necessary 16:28 yoklov: and your code still works 16:29 yoklov: if you know that's true, your code is very easy to think about and work with 16:29 yoklov: when you have state, it's not true 16:29 yoklov: state/mutation 16:29 yoklov: when you have higher order functions it's still true. 16:29 Shambles_: yoklov: If you do, then, well, no, it's basically the same thing as imperative code. The 'state of the world' stunt is sometimes done to obfuscate I/O to make it seem 'pure'. You can 'loop over' the whole program's state, essentially "returning" the graphics/sound on each pass, and "taking as arguments" keyboard and mouse input for the next pass. 16:29 yoklov: how did the state of the world get involved? 16:30 yoklov: i though we were talking about a function that returned an integer and some tail recursive loop 16:30 yoklov: if you have mutation then obviously… there's mutation involved. 16:31 yoklov: IO is equivalent to mutation here, in that it breaks referential transparency. 16:31 Shambles_: yoklov: Because if you maintain a 'state of the world' then you can achieve true state. It will never 'lose' the changed state, like in my example, the value of the 'x' after it's been running for a while. With 'state of the world' it behaves as with mutated state, along with all its glorious opportunity for corruption. 16:32 Shambles_: yoklov: Without 'state of the world' (or similar stunts) eventually the 'x' will be lost, like any variable within a stack frame (outside 'main') of any language. 16:33 Shambles_: yoklov: Except true Fortran (77), which had no stack frames. 16:34 yoklov: i'm not sure what you have just said makes any sense. 16:34 yoklov: in the example you gave 16:34 yoklov: the only object in the code is x. 16:34 yoklov: it's the entire world 16:35 yoklov: you never change its value 16:35 yoklov: only call functions with new values of x, so how is this equivalent to mutation? 16:38 Shambles_: yoklov: If you never 'return to' a previous state of the world (due to the tail-call recursion over aspect), then there is no difference between it and mutation. The state of the world can become (and remain) corrupt. The claim that functional style is superior is basically "nothing ever changes, so if it starts in a valid state, it will always be valid". This is only true if you don't 'hold onto' any state. 16:39 Shambles_: yoklov: If you don't 'hold onto' any state, you can't do anything useful. 16:39 yoklov: I don't think thats why the functional style is superior 16:39 yoklov: I've never heard anybody claim that's why either 16:40 Shambles_: yoklov: So you either pass a big wad of state around and never return, or you end up using mutable variables /somewhere/ to hold data and functions. 16:40 yoklov: the latter tends to be better. 16:40 yoklov: well 16:40 yoklov: it sort of depends on what you're doing 16:41 yoklov: but if every function can change the state of the world then obviously you're no better off than if you were doing it imperativley. 16:42 Shambles_: yoklov: It's the latter only in 'impure' languages like Lisp. One reason Haskell I/O is so ... the way it is, is due to trying to get around the mutation. Mercury (basically statically type checked Prolog) is a example of a language that uses the 'state of the world' excuse. 16:43 yoklov: i think the best way to do it in most cases is to have lots of pure functions and then an impure `main` 16:43 Shambles_: yoklov: And what's to keep every function from changing the state of the world if you pass the state of the world around, and never return to previous states? It's exactly the same as imperative programming, only more obfuscated. 16:43 yoklov: don't pass the entire state of the world around, then. 16:44 yoklov: and i'm pretty sure laziness is more the reason haskell IO is the way it is 16:44 Shambles_: yoklov: Yes, I'd agree. Make I/O imperative, and do the rest declaratively, though not necessarily functionally. It depends on what you need done. Prolog would be better at planning/routing/scheduling type tasks, better as in 'you have to write less code to get it done'. 16:45 Shambles_: yoklov: I hold no illusions that it will be any less *buggy* than a imperative version, except for the possibility that there would be less code involved. State is changing either way. If you get rid of it the code is worthless. 16:45 yoklov: logic programming is great if you're doing something logic programming is great for. 16:46 Shambles_: yoklov: Yes, as are other declarative paradigms. There's rewriting ones which are nice for manipulating strings and trees. There's dataflow which is nice for simulations. 16:46 Shambles_: yoklov: Functional is nice if what you're doing is much like math or chemistry. 16:47 yoklov: functional is nice if you like having small, easy to understand functions. 16:48 Shambles_: yoklov: I'm interested in Lisp not because it's functional, but because it does everything I want in a programming language. Things I haven't found in Python that I want are the ability to use as many stack frames as my RAM will hold, and the ability to easily add/use domain-specific languages for parts of the program, without having to use one language for the whole thnig. 16:48 yoklov: it's not only good for math or chemistry, and I actually think it would be terrible for chemistry. 16:49 Shambles_: yoklov: You can have small, easy to understand parts in many paradigms, though, outside logic programming, many would be considered some flavor of functional. If you want itty bitty functions you probably want Forth/Joy, really. 16:49 yoklov: Shambles_: having written in factor (similar to forth), your functions tend to be small, but are rarely easy to understand for in concatenative. 16:49 Shambles_: yoklov: Most languages don't have a 'symbol' type, so Lisp is well suited to symbolic algebra, chemistry, and other non-numerical operations. 16:50 yoklov: errr, *in concatenative languages 16:51 (quit) mye__: Ping timeout: 244 seconds 16:51 Shambles_: yoklov: I haven't found Forth-likes to be particularly hard to understand. I hate debugging them. You get a stack trace where the corrupt stack was read. There's no easy way to detect when it goes bad, since most operations are side-effecting (to the stack). The way you're supposed to develop in Forth-likes is make tiny functions that can be used to describe your task. 16:52 Shambles_: yoklov: You get lots of tiny functions made of tiny functions made of tiny functions... And you'll just about have to write it that way since using the stack heavily makes it hard to work with much data at once. Hard for the human that is, trying to keep it all in mind. 16:52 yoklov: more than one dup or swap in a function and I tend to get lost. 16:53 Shambles_: yoklov: Yes. The Forth answer is "so don't do that". Take as few arguments as possible. Do as little as possible in each function. Make *SURE* they have good names. Otherwise your code will be incomprehensible. Done right, though, it reads a lot like Yoda describing how to solve a problem. :P 16:54 yoklov: what if you need to do math? 16:54 Shambles_: yoklov: Try to stick each equation in its own function. Try not to get too cute. 16:56 (join) flying_rhino 16:56 flying_rhino: hi people 17:00 (quit) zyoung: Remote host closed the connection 17:01 yoklov: Shambles_: still, even then it ends up being much harder to read. 17:03 Shambles_: yoklov: It may be familiarity, or how people's heads are wired. Supposedly the reason many programmers don't like Lisp is the lack of 'landmarks'. The syntax is so regular that it's difficult for them to figure out what's going on. 17:03 Shambles_: yoklov: There's actual studies that show this 'matters' for most people. 17:03 yoklov: consider (+ a (* t (- b a))) with [ over - ] dip * + 17:04 yoklov: heck, even the lisp syntax is hard to read compared to a + t * (b - a) 17:05 Shambles_: yoklov: Now, on the other hand, personally I find complex syntax gives me a headache. Most of the time things are okay, but as soon as I need to worry about operation priorities for anything other than basic mathematics, I'm likely to screw up. I really *like* having evaluation only work one way, unconditionally. So I like stuff like Forth and Lisp. 17:05 yoklov: I like lisps syntax but it's somewhat removed from that of mathematics. 17:07 yoklov: regardless, can you tell what the factor version does without knowing it's equivalent to the lisp? 17:07 Shambles_: yoklov: You will generally find it 'hurts' to use large expressions in Forth-like code. The "* +" is a hint. Seeing two operators against each other with no value in-between means the stack probably holds quite a bit. Might not be anything you can do about it if you're using a familiar equation (e.g. trying to write the quadratic equation), but try to avoid it where you can, and be sure to step through it in the debugger. 17:08 yoklov: that's code for `lerp' 17:08 yoklov: it takes 3 variables, a b and t 17:09 yoklov: and interpolates along the line between them. Splitting it up even more than that would be absurd, and would hinder performance (this is a function which would get called _many many times_ in the inner-most part of a rendering loop) 17:09 Shambles_: yoklov: I wouldn't know what the "[" "over" or "]" did. Been a long time since I fiddled with Forth, but I seem to remember there were comments that looked sort of like "( some stuff here - other stuff)", which I believe is the stack 'before' and 'after' state for the code. That would have been my guess otherwise. I would have thought "dip" was a typo for "dup" (duplicate top of stack). 17:10 yoklov: yeah, i don't know forth 17:10 yoklov: it's factor 17:11 Shambles_: yoklov: I will say Forth-likes don't tend to be terribly performant. Screwing with the stack constantly is slow, compared to doing things in registers or even locations in RAM. Due to them making it very painful to work with much state at once, Forth programs, and environments, tend to be extremely memory efficient, however. 17:12 yoklov: factor is compiled and ends up being nearly as fast as c in a lot of cases. 17:13 yoklov: that said i can't stand to use it for anything non-trivial 17:13 Shambles_: yoklov: I think the main advantages are it's about as easy as it gets to write a Forth-like interpreter, especially if you don't allow heap use, and it discourages memory waste (again, by making it hard to think about wasting memory). Forth gets used in embedded devices and bootloaders where RAM or storage space still matters. 17:15 Shambles_: yoklov: I think you'd find a lot of the same thing with assembly. ;) There's a lot of people that can do non-trivial things with both assembly and Forth-likes though. Both have very simple syntax, and make it hard to think about wasting space much. 17:16 (quit) Fare: Ping timeout: 246 seconds 17:18 ssbr: The great thing about racket is that you can define infix math pretty easily. 17:18 Shambles_: yoklov: As an aside, while I admit I didn't recognize the Factor code, and I wouldn't have recognized it as linear interpolation, I honestly don't find the Lisp version any harder to read than the original. I'd find it easier if it weren't for memorizing Please Excuse My Dear Aunt Sally ages ago. 17:19 ssbr: The whole point of using a lisp is to get the syntax that's most readable. Prefix notation for some arithmetic expressions is bleh. (OTOH, a prefix multiply/sum operation often _is_ what you'd use in regular mathematical notation too) 17:19 yoklov: I can't imagine feeling that it's worthwhile to define infix math though 17:20 yoklov: I might complain about lisp being far from math but I typically just put up with it. 17:20 ssbr: You only have to do it once. 17:20 ssbr: Actually other people have done it already, so you don't even have to do it once ;) 17:20 ssbr: although I'm not sure how sane some solutions are. e.g. you can override function application so that (a + b) == (+ a b) 17:21 Shambles_: ssbr: I'd be inclined to agree with the 'readable syntax' argument, but we'd just been talking about how people appear to be wired differently there. I don't like complex syntax. Some people do. 17:21 ssbr: Shambles_: oh, is that it? I tried following the conversation back a long way and couldn't figure out what it was about <_< 17:21 yoklov: it's annoying to translate formulae to lisp sometimes 17:23 yoklov: I don't really know what it's about. it got fairly off topic for #racket though 17:24 Shambles_: ssbr: It's wandered for a while. It started out with "state is evil, be functional" and me claiming "state isn't evil, it's the only thing of value, you will either mutate code or data, and functional is but one paradigm (though useful for some things)", then wandered into syntax (because of me claiming that "computer science isn't (just) math, any more than painting is chemistry because of pigments"), and a bit of Forth. 17:24 Shambles_: of pigments"), and a bit of Forth. 17:25 ssbr: ugh I wish I'd dropped in at any previous point 17:25 Shambles_: ssbr: Why? 17:25 ssbr: Because I haven't gotten tired of any of those arguments yet :) 17:26 Shambles_: I don't like arguing really. It wastes a lot of time. This all got started when I started asking questions about which constructs to use in which situations in Racket. I'd been trying to finish the @#$% guide, and make notes for myself for anything the guide didn't make clear, which was quite a few things. 17:27 ssbr: e.g. I'm never clear why people don't think CS is math. Almost all the papers I've read are essentially applied math. 17:27 ssbr: the only ones that aren't are experimental, and they're usually only experimental because they can't prove it (yet), e.g. an experiment showing that some hierarchical path finding mechanism "closely approximates" the optimal algorithm 17:27 Shambles_: I also don't feel like I've learned much from programming arguments for quite a while, probably because I've piddled with a lot of languages, so not many things are truly new. I just may not know about many things in great depth. 17:27 ssbr: and then the ones that aren't that are UX stuff and so on, which people honestly don't do enough of. 17:28 yoklov: ssbr: what's the mathematical basis for an object system? 17:28 ssbr: yoklov: which object system 17:28 ssbr: yoklov: the ones in Scheme and Haskell and so on have been rigorously formalized 17:28 ssbr: you can read the specs if you like 17:28 ssbr: (you need to learn how to read denotational semantics first) 17:29 Shambles_: ssbr: Well, some of my points are CS folk tend to fall neatly into two camps. One just wants to make computers do interesting things with minimal amounts of pain. The other got lost looking for the math department, and is determined to force the other group to agree with them. The latter group seems to be in power at the moment. 17:29 yoklov: ssbr: how about the ones in Java or C++, which are clearly neither experimental nor theoretical 17:29 (join) Fare 17:29 Shambles_: ssbr: The 'cost' to the world (i.e. people that actually work with computers, to do useful things, outside the ivory tower) has been ignoring issues like how the choice of syntax impacts the probability of making errors. 17:30 yoklov: or racket's object system, for that matter 17:30 Shambles_: ssbr: Because syntax is fluffy froofroo psychology soft science crap that is beneath mathematicians. ;) 17:30 ssbr: yoklov: so your argument is that because nobody has written a mathematical model of it, it is not math? 17:30 ssbr: eh 17:30 ssbr: is not mathematical 17:31 ssbr: Shambles_: Right, this is what I mean when I say we don't do enough UX studies 17:31 ssbr: Shambles_: it's really looked down on 17:31 yoklov: ssbr: I think the connection is probably fairly distant. I think programming is all math though 17:31 ssbr: yoklov: If programming is all math, and a C++ implementation is written from programming, what is C++? 17:32 ssbr: yoklov: The argument I was _going_ to go for was that you were saying fermat's last theorem wasn't math until a proof was written, but this is way better ;) 17:33 yoklov: haha, math, I guess. I don't actually disagree, on this one, I was just playing devils advocate. 17:33 ssbr: well it's hard for me to imagine programming languages as anything but a formal constructive mathematics -- so formal that even a computer can grok it 17:33 Shambles_: ssbr: I'm getting old and gray and crotchety. I've seen too many 'next big things' supposedly solving all the problems. I'd like to tell the first group "learn to use a debugger!", and show the latter where the math department is, and then tell them "either go do awesome useful stuff while bitching about the first group (like Djikstra, probably the best of the lot), or go to the math department and don't let the door hit yo 17:34 ssbr: although in fairness, you could've argued that C++ implementations are not C++. The spec has undefined behaviour which an implementation always defines 17:34 Shambles_: department and don't let the door hit you on the way out!". :P 17:34 ssbr: but maybe the spec is math. 17:34 ssbr: Shambles_: I dunno. I'm involved in the mathy part of CS. 17:34 (join) jonrafkind 17:35 ssbr: The way I see it, the problems with a lot of CS people aren't that they use math, it's that they don't care how they use it 17:35 yoklov: I didn't really think programming was math until I took a course on the theory of computation, the segment on decidaility and turing machines really made it sink in that it gets back to math at the end of the day 17:35 ssbr: like the crowd of haskell papers whose only purpose is to relate haskell to known mathematical objects, without actually using these to prove things about haskell 17:35 (join) gerardpaapu 17:35 Shambles_: ssbr: Please don't tell me C++ is a good representation of math. I may not like the "you will accept that CS is just math, or be snorted at, you filthy plebeian!" mathematician infestation in CS, but I don't hate mathematics as a whole. C++ makes me want to hit things. :P 17:35 ssbr: math can be used usefully to actually, yanno, _prove_ things about programming. 17:36 ssbr: The soft UX people can make things improbable, math can make things _impossible_ 17:37 ssbr: Shambles_: I wouldn't dare 17:37 ssbr: although the spec is probably pretty well organized. 17:37 Shambles_: yoklov: There is a lot to computer science that doesn't fit neatly into what people think of as math. First you have all this stuff that *is* important in the real world (syntax -> bugs, and so on) that definitely isn't math. Then you have stuff that is technically math, or at least some form of philosophy (e.g. data structures as graph theory + abstract algebra) but doesn't involve any numbers. 17:37 ssbr: Shambles_: woah, woah, back up 17:38 ssbr: math totally doesn't involve numbers 17:38 Shambles_: yoklov: You also get a LOT of misleading stuff taught to you in most CS courses. To pick something from the other side of the fence. "Formal verification is pointless, since the Halting problem shows no program can do it." You hear that a lot. It's not true. 17:38 yoklov: Shambles_: I don't know how you can thing abstract algebra and graph theory aren't math 17:38 ssbr: math is anything with rigor and formal proof :( 17:39 Shambles_: yoklov: First, the Halting Problem is a specific example of a more general problem. The most general form I know of is Godel's incompleteness theorem, that basically says that any system that can express basic arithmetic will either be inconsistent (it will generate paradoxes, i.e. 'lie'), or incomplete (it will be unable to answer some questions about itself). 17:40 Shambles_: yoklov: So, in practice, you will end up having to add more facts to your verifier to verify some programs, but it's still quite capable of doing it. Further, most programs (outside graphics, compression, and a few other areas), aren't 'interesting' mathematically, so probably won't need any additional facts. 17:41 yoklov: Err, yeah but what is your point? 17:41 Shambles_: yoklov: I said /most people/ don't think of graph theory as math. Further, I'm pretty sure I could teach most bright 6th graders (or even younger) graph theory without any great difficulty. For some reason it's usually reserved for grad students, while they keep trying to teach calculus at ever-younger ages. And it definitely doesn't *look* like math. Again, no numbers, no algebra (in the high school sense). 17:42 bremner: I guess most undergrad CS students get graph theory these days 17:43 bremner: and for the last few decades 17:43 Shambles_: yoklov: My point was "mathematics is the cancer that's killing CS" (to put it in sound-byte meme-speak). That's exaggerating, and as I said some of the supposed facts you get out of teachers aren't facts. The over-formalization is causing problems, and a lot of the useful formalism isn't being taught. 17:44 Shambles_: yoklov: You'll have calculus rammed down your throat, but you probably won't be forced to take graph theory. Real programmers are going to need the latter more than the former, unless they do graphics work. 17:44 yoklov: That's not true in every case, but it's probably true in some 17:44 yoklov: I haven't used calculus a single bit in graphics work, to be hones 17:45 Shambles_: yoklov: Not even defining curves or using quaternions for rotations? 17:46 yoklov: I haven't done it that much. most of what I've done was texture mapping, or 2d work, but it was entirely linear algebra 17:46 yoklov: I've felt that my calculus knowledge was totally useless. 17:47 Shambles_: yoklov: You won't need calculus for 2-D stuff outside maybe parts of vector graphics. 2-D is just fine with geometry and trig, which give me warm fuzzies. I like math I can 'see'. :P 17:47 yoklov: I've also done 3d stuff. 17:48 Shambles_: yoklov: I dunno how you get by in 3-D stuff without quaternions. As soon as anything rotates you have to deal with them. 17:49 yoklov: Honestly they're not something I was ever taught about in calculus 17:50 yoklov: http://thomcc.github.com/Argh/ is basically the extent of my 3d experience, though the text below it is significantly quite out of date 17:50 Shambles_: yoklov: The calculus courses I had were horrible. Like most math courses I had (other than geometry, trig, and statistics) there seemed to be some sort of bizarre hatred toward application. I never learned how to use it. None of it made any sense. Imaginary numbers seemed like something that resulted from a mathematician dropping acid. 17:51 Shambles_: yoklov: Imaginary numbers are involved in using quaternions. There /is/ a good geometric explanation for imaginary numbers, that makes them seem far less nonsensical. I just never got anything like that in class. 17:52 yoklov: We did fourier and laplace transforms in my calc classes so imaginary numbers feel worthwhile to me 17:53 Shambles_: yoklov: We never got that far in mine, though my teacher spent, I think, about 1/2 the course on them. Never had any idea what they had to do with anything. I just remembered the whole basis was nonsense (square roots of negative numbers) and basic math operations no longer made sense. Again, it doesn't have to be nonsense, it's just how it was taught. 17:54 (join) jacius 17:54 asumu: Mathematics departments definitely think of graph theory as math. I took such a course. It's also quite different from what CS departments teach. 17:54 ssbr: asumu: in what way? 17:54 ssbr was going to take the math department's graph theory course next semester 17:55 Shambles_: yoklov: Maybe it's better now. I grew up with 'plug and chug'. You were handed 100 to 200 equations to solve. Maybe 2 to 4 word problems in them. Somehow from playing meatbag calculator for hours you were supposed to understand why this worked and how to use it in real life. 17:55 ssbr: Shambles_: that's mostly what high school "math" is about, yeah 17:55 asumu: ssbr: CS courses typically describe graphs very briefly just to get an idea of how they're useful for algorithms. Then teach a bunch of algorithms with them. This is definitely useful to know. 17:55 asumu: ssbr: OTOH, the math course will focus on proving interesting properties about graphs. 17:56 Shambles_: yoklov: I got geometry and trig from the same teacher that taught physics. Ate that up. Loved every minute of it. It all made good sense. She taught us how the equations were discovered and why the worked. We got to predict where model rockets would land (in real life). Yes, you could still play withe explosives in schools back then. 17:56 shawnps: if anyone has a sec - i want to give this function a list of pairs as the optional-params argument, but i can't just give it a list and then do something like (for ([i optional-params]) i). anyone know what i can do here? https://github.com/shawnps/mygengo-racket/blob/master/mygengo.rkt#L31 17:56 Shambles_: yoklov: Statistics is pretty much always applied, thank god. I don't know why some of the equations work, but I did understand what to use for what real world purpose. I rather liked some of the assigments. 17:56 shawnps: since i'm using alist->formurlencoded, it expects a single list of pairs, but i haven't figured out how to flatten optional-params 17:56 ssbr: asumu: this sounds about right. I think I should take the math course then -- I've forgotten too much about graphs 17:56 ssbr: plus I bet the matrix representations of graphs have some neat properties 17:57 asumu: ssbr: Yeah, definitely worth taking. And things like bipartite graphs, graph coloring, and so on have applications in CS. 17:57 asumu: Also, I think graph theory is just a very interesting subarea of math. 17:58 (join) bluezenix 17:58 Shambles_: I never had a course on graph theory. I have read some books on it years ago. I didn't find it difficult at all, and thought it was rather fun. 17:59 (quit) bluezenix: Client Quit 18:00 ssbr: Yeah. Apparently a lot of people don't get it or else just plain dislike it. 18:01 ssbr: shawnps: I don't really understand the question 18:01 ssbr: shawnps: it might help if you gave some code that didn't do what you want, and explained why it didn't work 18:01 (join) bluezenix 18:02 Shambles_: ssbr: Kind of surprised to hear that. It struck me as immediately relevant since it's really painfully obvious how a graph relates to a data structure or execution path. I didn't think any of it was really hard. Maybe the people that don't like it are the one that think math is always about numbers or rearranging equations. :P 18:03 ssbr: Shambles_: I never understood the dislike either. To be fair, I only ever heard about it on weird blog posts. All my classmates appreciated graphs :) 18:04 (quit) bluezenix: Client Quit 18:09 Shambles_: ssbr: I have been made aware that many students didn't like courses on programming language design and implementation. It's usually the mandatory one where you use a lot of 'weird' languages (Lisp amongst them), usually just for a short time (you don't have to learn them in depth). Did most of your friends like it? 18:10 ssbr: Shambles_: I remember that when I took it, I couldn't stand the lecturer (very difficult accent) so I ended up never attending class. So I never knew my classmates. :) 18:10 ssbr: I was the TA for this semester's edition, though, and we had an exceptional lecturer who made pretty much everyone enjoy the course 18:11 ssbr: He made everyone use -- and learn in depth -- racket. And then he gave people a backtracking search library and told them to implement unification. And then he went, "btw this is prolog. OK, let's move on to haskell..." :p 18:12 ssbr: actually near the end there it was pretty bad. Nobody learned haskell properly. But hey. 18:12 ssbr: People enjoyed it and learned a lot. 18:12 Shambles_: ssbr: Hmm, so maybe it's not just me. I think different language designs are fascinating. I also liked studying operating systems, though that seems sort of pointless now. Looks like nobody's going to use anything but Windows and Unix from here out. 18:13 ssbr: Even windows is becoming a unix ;) 18:13 ssbr: Unix is the cancer that's killing OS research !!1111 18:13 Shambles_: ssbr: It's actually closer to ITS/VMS underneath I think. 18:14 Shambles_: ssbr: I have to admit it does seem to have stagnated a lot. It'd be nice to see some progress. At least someone implement capability security CapDesk style, or something. There's progress to be made, but the chance of it seeing the light of day seems very slim. 18:16 Shambles_: And yeah, I know, there's some research OS's with capability security. I meant something commercial, with a nice UI, that people would actually be willing to buy. That last part is the real problem. 18:17 Shambles_: Well, not necessarily commercial, but at least people would be willing to use it. Something at least as popular as a top-10 Linux distro would make me happy. 18:24 asumu: Shambles_: BSD has capabilities. 18:24 ssbr: Shambles_: yeah, that won't ever happen 18:25 ssbr: the world hasn't been that kind of way as long as I've been using computers 18:25 Shambles_: asumu: In the object capability sense? i.e. "programs have permissions, instead of, or in addition to, users"? 18:25 ssbr: WEll, I guess BeOS was kind of popular 18:25 asumu: http://www.cl.cam.ac.uk/research/security/capsicum/ 18:25 asumu: Not sure if it's in the release versions or not. 18:25 asumu: Oh, I think it shipped in FreeBSD 9. 18:26 Shambles_: ssbr: When I was growing up it was. There were lots of OS's. Most of them wouldn't be interesting from today's standpoint. I guess the Lisp machines would be, along with that Smalltalk project. 18:26 (join) wtetzner 18:26 asumu: Yes, I believe it's in the object capability sense. I don't know how ambitious it is, but it's definitely OS research that's made it into a real OS. 18:27 asumu: A rare example, of course, but still great. 18:27 Shambles_: ssbr: One nice thing about them, though, even if most were monolithic kernels with fairly conventional GUI's on top and hierarchal file systems, is if you absolutely couldn't stand one, you could usually find a job where you didn't ever have to touch it. Now you can't escape Windows if that happens to be your 'can't stand'. :P 18:28 Shambles_: asumu: That is encouraging. Is it integrated with the UI any? As in, can you use 'powerboxes'? 18:28 ssbr: What on earth is a "user angel"? P.S. that's the best spin of "daemon" yet 18:28 ssbr: Shambles_: I think you can as a software developer 18:28 ssbr: especially with web development, the servers usually run on a unix-y system, so you can usually get away with linux. Maybe even BSD. 18:29 ssbr: And since everyone uses Windows, you can get away with Windows, too ;) 18:29 bremner: I'm not sure trading windows for php is a win. 18:29 ssbr: eh, it doesn't have to be PHP. 18:29 ssbr: pick ruby on rails or python or whatever. 18:29 ssbr: of course it's still web development, so it still is terrible 18:30 Shambles_: ssbr: Not heard that term, but I'm familiar with most of the basics. The main concepts are installation endowment (permissions a program is granted on install, and always retains) and powerboxes (one-off permissions you get through a UI widget). There's some other things like Principle of Least Authority and whatnot, but they seemed fairly 'obvious'. The real trick is giving programs permissions, and keeping most in powerb 18:30 Shambles_: permissions, and keeping most in powerboxes. 18:30 asumu: "This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs." 18:30 asumu: (answers seems to be yes) 18:30 asumu: *answer 18:30 Shambles_: asumu: You officially have me interested. This is FreeBSD? 18:31 asumu: Shambles_: Yep. See http://www.freebsd.org/releases/9.0R/announce.html 18:31 (quit) dzhus: Read error: Operation timed out 18:31 asumu: (it is now an "experimental" feature) 18:32 Shambles_: asumu: I last messed with FreeBSD somewhere around the mid 90's, so I don't know much about their behavior. Does this mean it's likely to stay in? 18:35 asumu: Shambles_: Sorry, I have no idea. I'm not a FreeBSD user. I suspect it just means it's not stable yet, but that's just my uninformed guess. 18:36 Shambles_: asumu: I may try to run this in a VM. This seeing actual use is one of the things I'd hoped for that I never expected to happen. It's one of my two OS wishes. The other is moving, at least, video drivers into a microkernel-style system since they seem to be responsible for most crashes. 18:38 Shambles_: asumu: The other thing I'd really like to see is computers offloading code to FPGA's for speed. It looks like some of the old Commodore/Amiga fans are toying with that. It's not something likely to be 'big' but it might be something available at least. 18:42 asumu: That'd be neat, especially with some of the FPGA designs optimized for functional programming. 18:43 chandler: Shambles_: I know the capsicum developer (robert watson), and have talked with him about it quite a bit. It's "experimental" in 9.0 because there may be changes to the userspace API between now and 9.1, when it should be deemed "stable". 18:43 chandler: Shambles_: To address your general point, a lot of OS research is done within the context of existing systems like Linux or BSD, but that doesn't mean there isn't anything interesting going on; if anything, it means there's more of a focus on making new ideas available in existing operating systems. 18:43 Shambles_: chandler: So it's likely FreeBSD will keep it (as opposed to dump it later)? 18:44 chandler: I think it's almost certain. As I said, the intention is to declare it stable in 9.1, and rwatson is a FreeBSD core developer, so he can do that if it's ready. 18:45 Shambles_: chandler: Well, then, I may just have to become a FreeBSD user. Pretty much nothing I use depends on the Linux kernel. How's the hardware support on FreeBSD nowadays? I know it used to be much worse than Linux. 18:46 Shambles_: chandler: I *do* use Linux pretty heavily, but what I was getting at is the stuff I use is probably all on FreeBSD, except maybe hardware drivers. 18:46 yoklov: my roommate is a graduate student on hardware design (specifically security, so he could be off base) and he seems to think that fpgas (or some sort of reprogrammable logic) will be integrated with cpus soon, so that certain operations can be optimized for on the fly 18:46 chandler: I'd say that it lags behind Linux. If your xorg driver depends on kernel mode setting, it probably doesn't work on FreeBSD. (E.g. older Intel GMA graphics work, but there's no 3D/DRI for the HD graphics found in Arrandale and later.) 18:47 chandler: I'd suggest that you download PC-BSD and give it a try. 18:48 Shambles_: chandler: I usually end up using fbdev, or the proprietary NVidia drivers. I just cheked, and it looks like the proprietary NVidia drivers exist for FreeBSD. I wonder about other pretty vital stuff though, like the onboard network connection. 18:48 chandler: nvidia does publish their proprietary drivers for FreeBSD, so those devices should work. Wireless chipset drivers seem to lag behind linux, so if your hardware is a couple years old you might have a good chance of making it work. 18:49 chandler: I haven't found an ethernet interface yet that doesn't work with FreeBSD. In fact, I've got a little Atom microserver here whose ethernet interface worked in FreeBSD but not in Linux. 18:49 Shambles_: chandler: It's a desktop, no wireless, but the network and sound are RealTek, which isn't always the best supported thing, though Linux started supporting them ages ago. 18:50 Shambles_: chandler: I take it PC-BSD is a 'distro', to put it in Linux-speak? 18:51 Cryovat: Think of it as the Ubuntu of BSD 18:51 Cryovat: Before they started taking the Unity route 18:51 chandler: Yeah, though they tend to avoid that word. 18:53 Shambles_: chandler: Has KDE right? That's what's needed for the PowerBoxes, and it's my preferred desktop anyway. Looks like they have a LiveDVD. 18:53 chandler: Yes. PC-BSD's preferred desktop is KDE. 18:54 Shambles_: I just looked up my networking hardware and it looks like that's good to go. Was supported around 2008. 18:54 Shambles_: This is great news! Thanks for letting me know. 19:15 (quit) mceier: Quit: leaving 19:27 (quit) asumu: Remote host closed the connection 19:32 Shambles_: Is there a way to ask Racket if any identifiers shadow existing ones? 19:38 friscosam: maybe something with namespaces 19:38 friscosam: I'm thinking namespace-variable-value, but I cannot construct an example 19:39 friscosam: that works 19:41 friscosam: ah. this will work in the repl: 19:41 friscosam: (namespace-variable-value 'printf #t (lambda () #f)) 19:41 friscosam: (namespace-variable-value 'foo #t (lambda () #f)) 19:45 Shambles_: I suppose that'd work manually. I was hoping there'd be some sort of compiler flag I could turn on that would say something like "Warning: variable blarg defined in [file] [line-number] is shadowed in [file] [line-number]". 19:48 (quit) netrino: Quit: Ave! 19:49 (join) zyoung 19:50 (join) ambrosebs 19:56 (join) nilyaK 19:58 shawnps: ssbr: thanks, turned out i just needed to use append... i was way over thinking it 19:59 friscosam: Shambles_: generally speaking that is not needed functionality 20:00 ssbr: shawnps: okie dokie. 20:00 ssbr: Glad you solved your problem. 20:03 Shambles_: friscosam: I'm not sure why it would be not-needed. Almost every language allows shadowing identifiers. It 'works okay', in the sense that your code won't break. It is confusing however. gcc has -Wshadow to tell you you're doing things that may confuse people. 20:04 Shambles_: friscosam: The Racket Guide warns you not to do it. I thought there might be a feature to help let you know when you were. 20:06 (quit) djcb: Read error: Connection reset by peer 20:07 (quit) zyoung: Remote host closed the connection 20:07 friscosam: I see what you mean. I thought you meant from a runtime perspective 20:08 (quit) masm: Quit: Leaving. 20:09 (join) wtetzner_ 20:09 (join) FareWell 20:09 (quit) wtetzner: Read error: Connection reset by peer 20:17 (quit) bitonic: Quit: WeeChat 0.3.7 20:19 (join) kvda 20:28 bremner: Dr racket can give visual feedback for moused-over identifiers after "check syntax" 20:32 (join) zyoung 20:34 Shambles_: bremner: I tried redefining "null" just to see what it would say. I don't seem to be getting any feedback on the shadowing problem. 20:36 bremner: when you use null, the definition is picked out? 20:37 Shambles_: bremner: I'm not sure what you mean by picked out, but it seems to be the same as if I'd defined anything else. 20:40 bremner: there should be a line from null to it's definition or module 20:42 bremner: I'll double check in a few min 20:43 (join) jeapostrophe 20:43 (quit) jeapostrophe: Changing host 20:43 (join) jeapostrophe 20:44 Shambles_: bremner: The goal is to have it complain that "null" is already defined (as a empty list). It does not do this, even as a top level define. I tried it inside another define too. Further, I appear to be able to define "foo" twice as a top level define within the same module with no complaints, which surprised me. 20:46 bremner: sure, I didn't promise you a precise equivalent to gcc -Wshadow 20:48 bremner: This requires inspecting a given identifier that you suspect of being shadowed, so it might not help at all. 20:49 bremner: But, anyway, so you know: in a buffer with "#lang racket\n(define null 0)\nnull", press check syntax, then place the mouse cursor over either null 20:55 (join) nilyaK1 20:56 (quit) jacius: Remote host closed the connection 20:57 Shambles_: I take it you want the \n to be carriage returns. Is that last "null" intentional, because it looks like invalid Lisp. 20:57 (quit) nilyaK: Ping timeout: 244 seconds 20:58 bremner: it's perfectly valud 20:58 bremner: err, valid 20:58 bremner: and yes, hit newline. Or not. 20:59 bremner: it's a kind of stupid program which evaluates to 0 20:59 Shambles_: bremner: Okay, I did this. The area where it's defined doesn't show anything when mouseovered. The second null shows a blue line to where it was redefined. 21:00 bremner: huh, works for both for me. 21:00 Shambles_: I'm using version 5.2.1 which I think is the latest. 21:01 bremner: me too. And if you place the mouse over the first null, no blue line? 21:01 Shambles_: I just get a blue line from 'null' to 'null' inside this file. 21:01 bremner: sure. So in the definition, it finds all uses 21:01 bremner: it happens to be boring in this case 21:02 Shambles_: When mouseovered, the definition points to the null outside parens. When mouseovered, the null outside parens points to the definition. 21:02 (join) dnolen 21:02 bremner: right. Try it in a real program maybe. 21:02 Shambles_: Theres no hint this was already defined, though it definitely was. 21:02 Shambles_: 'real program' you mean I need to save it in a file and then load it? 21:03 bremner: well, take away the definition, then the blue line will go to the module defining null 21:03 bremner: it just finds the current definition 21:04 bremner: oh, by a real program, I just mean something you wrote. 21:04 Shambles_: Right, but that doesn't help me. 21:04 bremner: fine. 21:04 Shambles_: I want to know that null already existed. This just shows me that I defined something called null. 21:04 Shambles_: It's not telling me it existed before I defined it. There's no line to 'racket'. 21:05 bremner: there would be if that was the active definition 21:05 bremner: for example "define" has a blue line to racket 21:06 yoklov: wait, ddn't racket used to error when you defined something that was already defined? 21:10 jamessan: multiple top-level declarations, yes 21:10 (join) antithesis 21:10 Shambles_: bremner: Still just getting the blue line between my local redefinition. 21:10 bremner: I mean the identifier "define" 21:11 Shambles_: Though now it's properly complaining if I redefine null twice at the top level. 21:12 bremner: rudybot: init racket 21:12 rudybot: bremner: your sandbox is ready 21:12 bremner: rudybot: eval (define define list) (define 0 1) 21:12 rudybot: bremner: ; Value: (0 1) 21:13 jamessan: rudybot: init racket 21:13 rudybot: jamessan: your sandbox is ready 21:13 jamessan: rudybot: eval (define x 0) (define x 1) 21:13 rudybot: jamessan: Done. 21:13 (join) replsos 21:14 jamessan: well, that definitely errors in drracket 21:14 bremner: that must be something odd about rudybot's sandbox 21:16 yoklov: I feel like when I was working through SICP it gave me a hard time about redefining `eval` 21:16 yoklov: i'm almost certain it did 21:16 bremner: could depend on the language 21:17 bremner: might have done something sneaky with define 21:17 yoklov: hm 21:17 yoklov: nope, #lang r5rs doesn't seem to complain 21:18 yoklov: and i don't think i used anything else 21:18 Shambles_: I guess any time I want to name something I need to try the name in the interactive window to see if it gives me anything, before using it. It'd be nice if there was a better way, but nothing seems to work reliably other than that. 21:19 jamessan: Shambles_: does it really matter if you redefine something that you wouldn't know to use anyway? 21:20 jamessan: it's not like this is elisp where that has an effect on everything else that would be using that name 21:20 Shambles_: jamessan: It can matter if someone else reads the code and doesn't see the redefinition. 21:20 jamessan: then they should read the code better *shrug* 21:21 Shambles_: jamessan: I try not to write in a bad style, especially when first getting used to a language. 21:21 bremner: Shambles_: if that's your concern, you're better of search the docs, in case the identifier is defined in an optional module. 21:21 Shambles_: bremner: racket/gui wouldn't import everything? 21:21 bremner: I don't know. 21:22 bremner: I can probably think of some artificial examples of stuff it doesn't. 21:22 (quit) jeapostrophe: Ping timeout: 240 seconds 21:24 bremner: plot doesn't seem to be 21:28 bremner: of course, included in racket/gui is a perfectly reasonable definition of "standard definition" 21:37 replsos: It's more on the "secret weapon" side of Paul Graham's programming language taxonomy 21:53 (join) Demosthenes 21:53 (quit) Demosthenes: Client Quit 21:53 (join) Demosthenes 21:53 (quit) Demosthenes: Client Quit 21:53 yoklov: why aren't threads in racket real threads? 21:55 (join) Demosthenes 21:55 (quit) Demosthenes: Client Quit 21:55 FareWell: what's a real thread? 21:55 (join) Demosthenes 21:56 yoklov: an OS thread 21:58 yoklov: it seems like they behave the same as OS threads, but just… aren't for some reason 22:05 Shambles_: I thought "places" were real threads? 22:05 yoklov: they are, but aren't what i'm asking about 22:05 yoklov: futures can act concurrently too 22:06 yoklov: i just don't get the point of a concurrency system as complicated as racket's threading system if it's… not actually concurrent 22:10 Fare: how is it not actually concurrent??? 22:11 yoklov: they're not OS threads 22:11 Shambles_: Might be a older system? 'Green threads' were all the rage at one point. Before OS's had good async I/O support it was sometimes still useful for keeping slow operations (disk, network, long computations) from 'hanging' the UI. They let you do things like claim you can use a million threads, while real threads would tend to consume all the RAM with stack space. 22:11 yoklov: at a given time, only one is ever running 22:15 yoklov: Shambles_: that makes sense, but is annoying. 22:16 Shambles_: yoklov: Could just ignore it. There's redundancy elsewhere, like empty(?) vs null(?) and so on. 22:16 yoklov: you can't really ignore it in the gui stuff. 22:20 Shambles_: yoklov: Hmm. Guess it's used to do the kinds of things you'd expect for the event loop? You wouldn't want parts of the GUI running in different threads anyway. 22:21 (quit) Demosthenes: Quit: leaving 22:22 yoklov: right, but it makes me wonder why they exist, and if they're not real threads why I even have to worry about them in the gui 22:26 friscosam: I think they exist because it is a lot easier to implement 22:26 friscosam: that's my opinion 22:27 friscosam: opinion/theory 22:35 (quit) FareWell: Quit: Leaving 22:40 yoklov: that's still not really desirable, especially when they're so ingrained with the language 22:59 (join) neilv 23:11 (quit) zyoung: Remote host closed the connection 23:14 friscosam: Shambles_: here is a super dumb way to get shadowing warnings in Racket: https://gist.github.com/2760405 23:14 friscosam: it's only partly tested 23:14 friscosam: and doesn't support all of define 23:15 (join) RacketCommitBot 23:15 RacketCommitBot: [racket] plt pushed 2 new commits to master: http://git.io/OP_FYQ 23:15 RacketCommitBot: [racket/master] racket/place/distributed: fix doc problems - Matthew Flatt 23:15 RacketCommitBot: [racket/master] add some missing acks - Matthew Flatt 23:15 (part) RacketCommitBot 23:18 friscosam: yoklov: I find the thread/event/sync system quite elegant, but I've read a lot of John Reppy's papers 23:20 yoklov: its not really a question of elegance, so much as it's a question of functionality 23:20 yoklov: though, it seems very low level to me. 23:21 yoklov: but maybe because i always use semaphores with them and never really the event/channel system 23:21 friscosam: eww 23:21 yoklov: *shrug* it's what was in the examples for what i needed to do 23:24 (join) asumu 23:27 (quit) jao: Ping timeout: 265 seconds 23:35 (join) zyoung 23:40 (quit) zyoung: Remote host closed the connection 23:45 (quit) dnolen: Ping timeout: 252 seconds 23:46 (join) dnolen 23:59 (join) Shambles_1