IRC Logs for #io Monday, 2014-09-22

prologicjer: talk to me about programming lanauges with eact arithmetic such as Scheme? thoughts? experiences?00:50
jerprologic, a numeric stack?01:13
jeror numeric tower is what i guess it's called properly01:15
jerin general, i like the idea, but as i get older, i like it less =]01:15
jeracute was going to have a numeric tower01:15
jeras to remain mostly compatible with io code01:15
jerthe older i get, the more i like the idea of having a robust type system, and while numbers would be in various types, with something ala type classes or interfaces that types can opt-into, you could craft yourself a numeric tower if you chose to01:18
jerthe robust type system buys you a first approximation of behaviour imo01:19
jerthat's all types are01:19
jererr, a first approximation of expected behaviour01:19
prologicI see :)01:50
prologicI’ll stew on this and get back to you with my thoughts :)01:50
prologicbtw, what precisely do you mea by a robust type system? for me (over the years) I have come to a strong appreication for strong typing (I know it’s highly opionated; but strong typing in the ense that a = “1”; b = 2; a + b; fails with a TypeError)01:53
prologicunlike in langs like PHP and JS for example01:53
*** nisstyre has quit IRC01:57
*** nisstyre has joined #io01:57
pdurbinbut without those languagues we wouldn't have a funny "wat" video01:58
prologichaha yes that’s quite true :)02:09
prologicit cracks me up every time I watch it :)02:09
prologicahh JS :) I lvoe you :)02:10
*** c74d has quit IRC02:16
*** c74d has joined #io02:18
*** gatesphere has quit IRC03:27
jerprologic, i mean robust in the sense that, 1 + 4.5 is also a type error, unless of course both int's and floats have implementations of + in a number type class, and the + function operates on two instances of the number type class03:54
jerin which case, it's encoded in the type system03:54
jerand therefore permissable, as it is sensical03:54
prologicI can’t decide if I want to design a pure functional langauge; and/or a language with exact arithmetic03:55
prologicI know I don’t want a static type system :)03:55
jeri do want a static type system03:56
prologicbut at teh same time I have a greater appreciation for purely functional langauges more and more (though I don’t use any on a day-to-day basis — yet)03:56
prologicI don’t — because it makes things like handling data you don’t know upfront harder03:56
prologice.g: JSON :)03:56
prologicor anything really that doesn’t have a strict structure03:56
prologicbeen there with C# :/03:57
prologicbut otoh I *do* want strong typing03:57
jerwell, not really04:04
jerbut it helps reduce bugs if you know what the data is ahead of time04:04
prologicI agree04:05
jeryou can represent any type of json as a single data type04:06
prologicyes by boxing it :)04:06
prologicI know04:06
prologicit’s the same technique RPython uses really04:06
jerby saying, it's either a string taking some arg (type constructor, sum type); or a number taking a double, or a boolean taking a bool, ...04:06
jerthen you can use the Maybe monad to get items out of it04:07
jerso write functions like get_bool :: string -> Maybe bool04:07
jerentirely type safe, flexible04:07
prologicbeen reading up lots on Monads :)04:08
prologicneed to play with them for practice04:08
jerthe maybe monad is easy04:08
prologicnow do one in Io :)04:09
jeri can, but there'd be no guarantees in the type system04:09
jerso it'd be kinda moot04:10
prologicare you impliying you can’t have a purely functional language without static typing?04:13
jerno, i'm implying that you can't have type safety without static typing04:14
jerif you view programs as hostile environments, which they typically are04:14
jerfor instance, i recently received word that UI code I wrote when iOS 2.2 was new and shiny, was still being used in production today, on iOS 804:14
jerthe fact it's survived that long in such a hostile environment (iOS SDKs are very hostile to compatibility long term)04:15
jerand continued to function as specified originally, is amazing04:15
prologicyou make a persasive argument :)04:16
jerbut i know the code and do remember it, the backing data has no way to prove safety in types04:16
prologicbut surely type saftely is not limited to static typing?04:16
jerwhy? because C04:16
jerprologic, you can have memory safety in a type unsafe system, as an example; but no, type safety requires static typing04:16
jerstrong typing does not require static typing04:17
prologicI’ve gotten used to strong typing04:18
jerhere's the thing with duck typing04:18
jerif it walks like a duck, talks like a duck, it might turn out to be a hunter with a loaded gun pointed at your head.04:19
jerthat first approximation is important04:19
jerit's effectively a contract and the better type system the language supports, the more limits you can put on those functions04:19
jernow there's a limit between restrictions on code and restrictions on developer productivity, that i'll grant you -- but once you trim away the newcommers, i think you'll find that in most languages that exist today, it's not at all that distruptive04:20
jerif anything, it helps you think more ahead of time04:20
prologicIHMO (I coulld be wrong) you don’t need static typing to nesseitate pure functions though?04:20
jerand makes you a better developer by being able to spot problems the compiler will catch, before you initiate a compile phase.04:20
jerno you don't04:20
prologicpure in the sense they satisfy the two requirements (side effects and indempotent)04:21
prologicso it’s possible to have *some* level of type saftey without static typing by implication04:21
prologicI think :)04:21
prologicbut maybe not with duck typing04:21
prologicI was more thinking strong typing + traits04:21
jeradd := method(a, b, asm(a=r1, b=r2, "add r1, r1, r2")) <-- for instance, is pure04:21
jerif we assume that arg1 and arg2 map variables to registers, and the string uses the format of instruction dest, sourceA, sourceB04:22
prologicit has obersvable side effects though04:22
prologichow can it be? :)04:22
jerwhat side effects?04:22
prologicor are is considered pure bcause the memory/regsiters is modifers will always evaulate to teh same result04:22
jerforget about assigning the method to some slot04:22
jerwell given the same inputs, you'll always get the same output in this method04:23
jer*always*; because we know how add works at a machine level, and this asm() function is merely calling out to the underlying hardware 04:23
jermore as an illustration that + maps directly to a machine instruction04:23
jerconsider if numbers in io were tagged pointers between given ranges04:24
jerso we take objects out of the picture here04:24
prologiclet me throw another example at you04:24
prologicx = Object(); x[“foo” = 1; x[“getfoo”] = method(return;)04:24
jermore important than type safety however, is memory safety. 04:24
prologicis getfoo() considered pure?04:24
jerdepends on the semantics of Object instances04:25
jerif they are value types, then yes; since foo is constant and could not be modified04:25
prologicso OO would have to modelled as Monads in a purely functionali langauge04:26
jerwell no but it might help =]04:26
jerOO -- when we think of classes (or prototypical objects in the case of io) are merely ADTs with coupled interfaces04:28
jertyped functional languages tend to separate these two things, and not couple them04:28
jeryou get ADTs, and then you get things like type classes, or interfaces04:28
jerwhatever they're called, they're mostly similar -- define some function that can operate on arbitrary types04:28
prologicI’m a little confused about it really04:28
prologicbecause IHMO getfoo() is pure04:28
prologicit will always reutrn x[“foo”]04:29
jerwrite specialized versions of said function, and then when any type doesn't matter, but the interface does, pass in said type class, because it itself is a type04:29
prologicbut that’s of course assuming x[“foo”] cannot be changed04:29
prologicI suppose?04:29
jerprologic, simple way to clear it up for you04:29
jer1) references to reference types are never pure04:29
jer2) references to value types are by definition pure, because value types are immutable04:30
jerso long as said value type doesn't contain references to reference types, then #2 above holds04:30
jerin all honesty, value types probably shouldn't be able to hold references to mutable things04:31
prologicso the above example could be pure as long as 1 (is a value type that’s immuteblae)/04:31
jerobject semantics are important here04:31
jerif x can be mutated after the fact w/o copying it first04:31
jeri.e., x is a reference type; then no it can never be pure even if 1 is a value type04:32
jeryou can think of it as pure, and you can even write a proof that given all your conceivable values foo might end up being, for those limited inputs, getfoo is pure04:32
jerbut that's proving an assumption for a limited set of inputs (maybe ok for your purposes); doesn't make it pure in terms of what the compielr can determine04:32
prologicafaik there are two ways of handling I/O and State — a) Monads (modelling as sequences of as arguments to fucntions) and 2) state passing style04:34
prologicbut I haven’t read up on SPS as such yet04:34
jerme either04:34
prologicI wonder whether there could be a third that could be worth explroing04:35
prologicthat is modelling state and I/O as a series of events04:35
prologiclaughable? :)04:35
jerwell there are other ways of handling i/o and state too04:35
jerlinear typing comes to mind04:36
jerbasically, linear typing is a way of saying that some type must be used exactly once. you can't ignore it, and you can't reuse it04:36
prologicand such a type would be I/O? for example?04:36
prologicor a particular state?04:36
jerconsider a getchar() function04:37
jeryou'd consider that as a function taking a world type, and returning a tuple of a char and a world04:37
jerand putchar() would do the inverse; take a char, and a world, and output a new world04:37
prologicisn’t that state passing style?04:39
prologicperhaps linear typing and SPS are similar04:39
prologicAnother way in which functional languages can simulate state is by passing around a data structure that represents the current state as a parameter to function calls. On each function call, a copy of this data structure is created with whatever differences are the result of the function. This is referred to as 'state-passing style'.04:42
prologicbut the link to
prologicis a blank/undocumented page04:42
prologicso NFI :)04:42
jerwell for an implementation of a linear typesystem, clean's uniqueness types are based on a linear typesystem04:44
jerclean is a lot like haskell except for this difference -- focus on uniqueness types rather than monads04:44
prologicI’ll have to read up on it :)04:45
prologicthis one?04:45
prologicI do have one thing to say to all this; after working in a largish team for a few months now (first time with a team size > 3 or so) — I can really truely appreicate static typing as you often can’t trust other develoeprs to a) communciate well and/or b) abide by contracts you make in your apis/libraries,/etc04:55
jerprologic, indeed04:56
jerexpand beyond a team that's worked together for years (~5+) continuously on similar products, and it's very hard to trust them to abide by api contracts04:59
jercommunicating well is hit or miss04:59
prologicunless of course all 5 developers worked well together all those years and communications effectively and abided by contracts that all agreed upon05:03
prologicbut when does that happen :)05:03
prologicI’ve only had a team like that once a few years ago and we were 3 for 2 years :)05:03
jeryou've been lucky05:15
jeri've been working with someone for 8 years -- not always continuously but nevertheless, we've worked together on many products05:15
jerand he and i still have communications issues, and contract abiding issues05:15
jerof course, he's a typical OO developer, and i've mostly migrated to be more of a FP developer05:16
prologicsorry :)05:16
jerso i just think it's the impedence mismatch05:16
prologicI’m heavily learning towards FP05:16
prologicbut torn between static typing and wtll not sure :)05:16
prologicI think maybe once I understand Monads a bit more and CPS (or LInear Typing)05:17
jerwell remember, a first approximation of expected behaviour is often enough of a savings to avoid having to write some unit tests 05:17
prologicI might call myself a purely FP developer :)05:17
prologicunit tests almost seem irrelevant in a purely functional language05:17
prologicsince you could argue that you could prove that a program is correct05:18
prologicquick search seems to indicate that there are several or more papers on type saftey with traits05:33
prologicor in other words implemenitng type safe systems with traits05:33
*** hashmal has joined #io07:22
*** iorivur has joined #io08:20
*** io-github has joined #io08:36
io-github[13io] 15stevedekorte pushed 2 new commits to 06master: 02
io-github13io/06master 14ae1e3b3 15Iori YONEJI: a tytypo, missi "CMAKE_BINARY_DIR" on CMake macrogis inserted.08:36
io-github13io/06master 142274478 15Steve Dekorte: Merge pull request #285 from iori-yja/fix_build_dir_typo...08:36
*** io-github has left #io ()08:36
*** iorivur has quit IRC09:52
*** marcous has joined #io09:54
marcousio coin Simon Gale ??09:55
*** marcous has left #io ()10:12
*** TheMonkey has joined #io11:42
*** ElMonkey_ has quit IRC11:45
*** ijon_ has joined #io11:46
*** keeto has joined #io12:05
*** bjz has joined #io12:09
*** fredreichbier has joined #io13:04
*** ijon_ has quit IRC13:21
*** ijon_ has joined #io13:22
*** bjz has quit IRC13:55
*** fredreichbier has quit IRC14:05
jerprologic, the way i look at it is similar to the accepted answer on that SO article you posted -- dynamic types place an extra cognitive burden on your ability to comprehend your program as a whole, or in large part14:10
jeryou constantly (if you'er doing it right) have to be aware of what a compiler with a robust type system would tell you at compile time, as you write it14:10
jerthis leads you to writing a lot of your type checking code in unit tests, to relive some of that burden14:11
jerthose tests just disappear when you use a different type system -- one the compiler can reason about at compile time14:11
jerthis frees you from having to think as much about that14:11
jerkind of ironic really =]14:11
*** bjz has joined #io14:12
*** ijon_ has quit IRC14:21
*** ijon_ has joined #io14:22
*** hashmal has quit IRC14:34
*** ijon_ has quit IRC17:26
*** ijon_ has joined #io17:40
*** ElMonkey has joined #io18:19
*** TheMonkey has quit IRC18:21
*** TheMonkey has joined #io18:22
*** ElMonkey has quit IRC18:24
*** ijon_ has quit IRC18:52
*** gatesphere has joined #io21:10
*** gatesphere has quit IRC21:52
*** hashmal has joined #io22:01
*** gatesphere has joined #io22:11
*** petr has quit IRC22:25
*** petr has joined #io22:26
*** bjz has quit IRC23:48
*** bjz has joined #io23:48
*** gatesphere has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!