IRC Logs for #io Tuesday, 2013-12-03

*** mkroehnert has quit IRC03:10
*** gatesphere has quit IRC04:39
*** asie has joined #io05:44
*** asie has quit IRC06:18
*** mhi^ has joined #io06:33
*** mkroehnert has joined #io07:27
*** ElMonkey has joined #io07:41
*** pchalupa has joined #io07:43
*** pinupgeek has quit IRC08:21
*** pinupgeek has joined #io08:38
*** espiral has joined #io09:26
*** hashmal has joined #io09:29
*** mkroehnert has quit IRC09:40
*** pinupgeek has quit IRC11:03
*** mhi^ has quit IRC11:40
*** mhi^ has joined #io12:13
*** pinupgeek has joined #io12:40
prologica rework of traits for mio12:54
prologicTrait is now a special kind of object12:54
prologicI also have a plaec to store references to core defined traits (users can store them in Root Traits too)12:55
*** pinupgeek has quit IRC13:03
*** pinupgeek has joined #io14:33
prologicsome validation of required methods added14:51
jerprologic, and you can't put line 18 inside of the Hello block?14:53
prologicI can15:07
prologicbut it has to come after the name attribute15:07
Raimondihow do I if(a >1 && b == 2, 1, 2) && is not recognized, which I expected, but how do you express that in Io?15:18
Raimonditried if(and(a > 1, b =0 2)...  but and( only uses the first arg15:18
prologicif(a > 1 and b == 2, 1, 2)15:20
prologicand is a method of boolean objects15:20
prologica > 1 evaluates to a boolean15:20
Raimondioh! so simple! :)15:21
prologicyup :)15:21
prologicmessage passing ftw :)15:21
prologiceverything is a message passed to an object15:21
prologicif is actually implemented in terms of ifTrue/ifFalse15:21
prologicmethods of booleans15:21
prologicit's syntactic sugar15:21
prologic(a > 1 and b == 2) ifTrue(1) ifFalse(2)15:22
prologicis the same as if(a > 1 and b == 2, 1, 2)15:22
RaimondiI see, that makes sense15:22
prologicand btw && and || do exist in Io15:22
prologicbut they are bitwise operators iirc15:22
prologicor at least they should be :)15:23
prologic&& and || would only be implemented on Number(s)15:23
*** mi6x3m has joined #io15:23
prologicjer, I'm only missing conflict resolution now right?15:27
prologicmight have to re-read the paper again to be sure :)15:27
jersorry i'm a bit behind15:28
jerresponding as i read15:28
jerprologic, i realize it's an order of operations problem, but convention would dictate that you uses() a trait at the end anyway15:28
jerat least to me15:28
jerRaimondi, if you want to see how an expression is interpreted, wrap it in a message() in the REPL; i.e., message(a > 1 && b == 2)15:29
jeroh and neat fact, while in a conversation with a colleague about ux design15:29
jeri realized how i could implement evalArgAt() in io15:30
jerit was previously the only method you need to implement basic constructs15:30
prologicthe only method needed?15:32
prologicre convention uses(...) at the end - I kinda agree15:32
prologicand don't really see a problem with this behavior15:32
jerprologic, one thing we've found is that requiring a user define or execute something outside of the do() block is confusing15:40
jeranother option is you could defer throwing the exception until the end15:40
jerthat would be a neat trick15:40
jerto allow users to use it wherever they want15:41
jerjust add on the state a "waiting exceptions" which are coupled with a block to check if it should still throw15:41
jeryou'd then craft a block, store it in that list, and if it returns true then you throw, false, then you don't15:41
prologiccould do that15:41
jerit'd have limited usefulness, but still would be useful in these cases15:42
prologicI don't mind this though15:42
prologicit follows the same sematnics as most langauges15:42
prologicwhat's defined first, etc15:42
prologicorder of oeprations15:42
prologicdelayed exceptions15:42
prologicsomething to think abouut in this use-case :)15:42
prologicjer, changes15:48
prologicmight release this15:49
prologicnadd to work more on the RPython port :)15:49
jergood luck15:49
mi6x3mhaxe io is going to beat mio!!!!!1115:50
prologicoh'really? :)15:51
prologicbut haxe is a static language15:52
prologicso you've already got me beat there15:52
prologicand seeing as we're having a sizing competition15:52
prologichow much of Io have you implemented so far? :)15:53
mi6x3mthe lexer15:53
mi6x3mworking on the parser now15:53
prologicthen I'd say you have a long way to go :)15:53
prologic*phew* :)15:53
prologicmio might still beat haxe io yet :)15:53
mi6x3mit has a chance yeah15:54
prologicalso mio is developed using TDD15:54
prologic317 unit tests to date15:54
mi6x3mmhi^: a popular series!15:56
mi6x3mprologic: do you disallow expression lists for method parameters?15:57
mi6x3mas in15:57
mi6x3mx := method(1+1 a, true)15:57
mi6x3mio takes 1 as the name of the variable in this case15:57
prologicno that's perfectly allowed15:57
prologicalthough that would raise an error15:57
prologic1 + 1 a15:57
prologicdoesn't much make sense15:57
prologicunless Number has a method called "a" :)15:57
mi6x3myes was just an example15:58
prologichold on15:58
mi6x3mprologic: btw, Io disallows empty body if you have other parameters15:58
prologicI take that back15:58
mi6x3mx := method(a,b,c,) is not allowed15:59
prologicapparently that's not allowed in mio :)15:59
prologicbut should be15:59
prologicyeah an empty body is senseless15:59
mhi^BTW, the url from the topic doesn't seem to exist anymore.15:59
prologicmi6x3m, that example earlier16:03
prologicx = method(1 + 1 a, b, a + b)16:03
prologicfor example16:03
prologicis nonsense16:03
prologica block has to have an arguments list16:03
prologicor names of arguments to bind objects to16:03
prologic1 + 1 would evaluate to 116:04
prologicand create what argument name?16:04
mi6x3mprologic: this is true, but if you invoke a method you want to be able to pass expression lists and argument16:04
mi6x3mprologic: io normally uses just the first identifier16:04
mi6x3ma + b it uses 'a'16:04
prologicinvoking a method is different from defining it16:04
prologicI'm talking about method arguments here16:04
prologicnot parameters (as passed to a method call)16:05
mi6x3mprologic: not difference between definition and call in io16:05
prologicin any language I know this is nonsense16:05
prologice.g: (Python)16:05
prologicdef foo(1 + 2, a, b):16:05
prologic   a + b16:05
prologicthat would throw a syntax error16:05
prologic>>> def foo(1 + 1, a, b):16:06
prologic  File "<stdin>", line 116:06
prologic    def foo(1 + 1, a, b):16:06
prologic            ^16:06
prologicSyntaxError: invalid syntax16:06
prologicit's garbage16:06
prologicyou must declare argumetns as symbols16:06
prologicor names or whatever you want to call them16:06
prologicnot expressions16:06
prologicin fact the way mio works is it looks at call message args (the unevalauted message arguments) and gets their names16:07
prologicwhen defining the arguments list16:07
prologicjer, any ideas on how I'd provide conflict resolution for traits?16:10
prologicfrom an api/user persepctive that is :016:10
prologicI thought of:16:11
prologicusers(trait, mapping)16:11
prologicwhere mapping is a dict of key->value pairs of methods of trait to rename to. None to delete16:12
*** pinupgeek has quit IRC16:16
jersorry wasn't reading again16:29
jerprologic, ah ok16:30
prologicnps :)16:31
prologicanyway that was my first thought16:31
jerthe key takeways here is that you only lookup on the object itself, not any of its parents if you do inheritance16:36
jerif your parent object has a slot named "name" that doesn't matter16:36
jerif your trait brings in name, it shouldn't conflict then16:36
jerbut if your object has a 'name' then you need to resolve that16:37
prologicahh cool16:39
prologicwe agree on the api :)16:39
prologicthen you wnet on with some internals16:39
prologicso methods traits being in should only conflict with methods of the object (not their parents)?16:40
jerthat's a key property of traits16:42
jeryou need a way to look up only in the local scope16:42
prologicremind me why? :)16:42
prologicor I could go re-read16:42
jerbecause a trait application affects an object itself, and not its parent16:42
jerthe parent methods are only used if the object itself doesn't supply it16:42
jerwith that in mind16:42
jerit should be self-evident why a trait should'nt conflict with parent methods16:43
prologicAn inherited member from a base class is overridden by a member inserted by a Trait. The precedence order is that members from the current class override Trait methods, which in return override inherited methods.16:43
prologicdid PHP's implementation get it right? :)16:43
prologicahh yes16:43
prologicof course :)16:43
prologicwith that in mind and that cleared up16:44
prologicoff to bed I go :016:44
prologicbeen down the last 2 days with Gastro :/16:44
mhi^I guess  object foo  is just syntactic sugar for  object getSlot("foo")  , eh?16:45
prologicis method renaming enough to support conflict resolution?16:45
prologicmhi^, correct16:46
prologicerr no16:46
prologicsorry no :)16:46
prologicobject foo does a full lookup16:46
prologicgetSlot only looks in the object slots iirc16:46
mhi^getSlot seems to also return slots of the prototype if it isn't defined on the object. :o16:47
jermhi^, no, obj foo is shorthand for obj doMessage(message(foo))16:48
jermhi^, and that it does, getSlot. if you want only the local object to be scanned, use getLocalSlot16:48
jerthere are has{Local,}Slot() methods too16:49
mhi^Ah, awesome. Thanks.16:49
prologicahh yes16:50
prologicI forgot about those :)16:50
prologicin mio I don't make such distcintions16:50
prologicnamely because I haven't found uses for them :)16:50
prologicgetSlot vs. getLocalSlot that is16:50
mhi^Is everyone having his own Io clone in here? :P16:51
prologicpretty much :016:51
prologicjer has acute (or did)16:51
prologicI have mio16:51
prologicmi6x3m has haxe io16:51
prologicI wouldn't call mio an io clone though16:52
mi6x3mmhi^: io is just a very nice language16:52
mi6x3mor a language concept16:52
prologicmore influenced by Io16:52
mhi^I see. 16:52
jermhi^, i was (for nearly 10 years) a core developer on io16:53
mhi^I know only have a rough overview so far, but I like its simplicity so far.16:53
Raimondithanks for the explanations and hints, jer and prologic 16:53
jeri hang around here because i know a lot about the language and can help people16:53
jerbut i spend my days writing ios apps16:53
jeri know steve does mostly too16:53
jeracute was never really an io clone though, it's more of a "what would io look like if we stripped it down to its bare metal"16:54
jerarrived at a solution which gave special syntax for single arg methods (would eventually factor out multiarg methods and add currying)16:54
mhi^Oh, okay. It's nice of you that you still hang around here for helping out newbies (and probably even advanced users).16:54
jerlet you override the slot lookup mechanism16:55
jer(i.e., have special lookup semantics per object if you want)16:55
jerit was all nutty =]16:55
mi6x3mi am telling you, io will soon kick off globally16:56
mi6x3mand become _significant_16:56
mi6x3mwe just have to make it more like PHP, lol, no, j/k16:56
mhi^I'd like to see that. :)16:57
mhi^(Getting more publicity, not becoming PHP, that is.)16:57
prologicjer, for me I'm trying to create a language that encourages better code reuse17:02
prologicone of my motivating gaols at least :)17:02
jerprologic, then you need to support function composition17:03
jerblock composition that is17:03
prologichow do you mean?17:05
jerso let's say you have two blocks, one represents adding two integers, one represents dividing by two17:06
jerlets just call these, add and div217:06
jerlet's also let . be our function composition operator17:06
jer(add(1) . div2)(5)17:07
jerwhich would result in 317:07
jerthe result of add(1, 5) would be sent as the first arg to div217:08
jerso in effect what happens is: div2(add(1, 5))17:08
prologicisn't this just normal function composition?17:12
prologicif so, I can already do this quite easily17:14
*** mi6x3m has quit IRC17:19
jerprologic, cool, yeah you should do it17:25
jerand yes this is normal function composition17:25
prologicyeah I've already mucked around with this17:31
prologicjust implemented conflict resolution for traits :)17:32
prologicpretty much works how you'd expect it to17:37
prologicand now mio has both function and object horoziontal composition :)17:38
prologicwere there any other properties of traits I'm missing?17:39
*** pinupgeek has joined #io17:43
jerprologic, i haven't looked at your code yet, i'm working atm... but give me a high level overview17:44
prologicok so:17:51
prologictraits are a special object called Trait17:51
prologicwhich all traits are cloend from17:51
prologicno trait can contain state, trying to do so raises a TypError17:51
prologictraits that define methods that conflict with the object using said trait that does not provide a resolution raises a TypeError17:52
prologicthe API is:17:52
prologicTFoo = Trait clone() do ( ...)17:52
prologicuse(trait, resolution)17:52
prologicfoo delTrait(trait)17:52
prologicfoo hasTrait(trait)17:52
prologicfoo is TFoo (abused)17:52
jeri think that's fine17:53
jeri don't even provide a way to delete a trait in acute's implementation17:53
jerbut i was moving to copy-on-write semantics for object cloning17:53
jeras relief on malloc17:53
jersince io is object heavy17:53
jerand few object clones are actually mutated (i did write tests to verify this hypothesis)17:54
jerwe can simply reuse those objects unless and until they're mutated17:54
jermethods that mutate an object must signal on that object that it was mutated (error prone, but handled internally)17:54
jerand at that time, we block to create a new instance, then continue17:54
prologicjust discovered a flaw in my internals17:55
prologicif I delete a trait that was handled by some resolution17:55
prologicit doesn't remember the renames17:55
prologicbecause I copy the methods of the traits directly into the object17:56
prologicas you did with acute too I suppose17:56
jerthe idea of a trait is to keep the lookups shallow17:58
jerif you've gotta keep a ref to a trait in a separate list on the object, you might as well just inherit from them or mix them into your inheritance graph (then you get mixins which have some problems compared to traits (i.e., method shadowing))17:58
jerdeleting a trait isn't a common operation17:58
prologicno I suppose not18:02
prologicperhaps I should remove the method?18:02
prologicand not worry about that headache18:02
prologicok g'night :)18:06
prologic4am :(18:06
jersorry man debugging some shit code18:14
jeryou don't want to do anything that surprises the user18:14
jerin short, i'd document that once you add a trait, you can't un-add it18:14
jerand then remove your delTrait method18:14
*** mhi^ has quit IRC18:23
*** mhi^ has joined #io18:26
*** fredreichbier has joined #io18:27
*** pinupgeek has quit IRC18:29
*** nisstyre has quit IRC18:47
*** fredreichbier has quit IRC18:52
*** mhi^ has quit IRC21:06
prologicjer, now you have me thinking22:27
prologicI really should have a way to delete traits :)22:27
prologici.e: don't surprise the user22:27
jerwhy though?22:27
jeri'm really curious as to what the justification to support deletion is22:27
jeri've never found a need in the ... 8 years i've been using traits22:27
prologictbh I've only started using traits since developing mio22:31
prologicI've not used a traits library in any other langauge for example22:31
prologicor a language that supports first class traits22:31
prologicso I don't know is the short answer22:31
prologicI guess in any dynamic langauge hwoever22:32
jeri don't want to dissuede you if you think there's a valid reason for it, but i think you'll find when you start building things with traits, you never really want to undo it22:32
prologicyou can mutate almost any part of an object or class22:32
prologicmetaprogramming ftw22:32
prologicthink Pythons' metaprogramming and the awful evil stuff you can do at runtime :)22:32
jeroh python can't hold a candle to io22:32
prologicI would consider traits for example22:33
prologicthe same as addiging dynamic methods to python objects22:33
prologicwhich is essentially what you're doing22:33
prologicand you can just as easily delete them22:33
prologicI do agree hwoever22:33
jerbut in python, can you do:22:33
prologicit seems silly and useless to do so22:33
jerdef add(x, y):22:33
jer    x + y22:33
jerand then:22:33
jerdef sub(x, y): __get__("add").body = lambda x, y: x - y22:34
prologicsure why not22:34
prologicassuming that were valid Python :)22:34
jerwell yes22:34
prologicit's more Io-style there :)22:34
jerin io it's trivial22:35
prologicbut yes essneitlaly22:35
prologicPython doesn't really expose the internals of objects to that level though22:35
jeradd := method(x, y, x + y); sub := getSlot("add") clone message next setName("-")22:35
prologicyou'd have to mess with add's bytecode and code object22:35
jersub(1, 2) == -122:35
prologicwhich you can do22:35
jernow i'm not saying you SHOULD do this22:35
jerin fact, i'm explicitly saying you SHOULDN'T do it 22:35
jerbut still22:35
jerio is so flexible because we have one type of AST node basically, a message22:36
jerand we walk the message tree22:36
jerplus we expose the AST as the Message object in the language, and make it runtime mutable22:36
jerso now all of a sudden, you have a hook into the parsing subsystem from within the language, that extends beyond the evaluator22:36
jerfew other languages give you that power22:37
jera few lisps/schemes, and rubinius are the only ones that come to mind immediately22:37
prologicast as data22:37
prologicanyway do you thinkk think it's bad to provide a delete trait method?22:41
prologicI mean we can mutate everything else anyway22:41
prologicwhy not traits (even if it is useless and non-meaningful)22:41
prologicI can't see a use case for it22:41
prologicbut what if you wanted to do so?22:41
prologicyou'd find you couldn't22:41
jeri think it's not needed22:42
jeri never like to write a feature because it's easy (ie., "i can do it, why not?")22:42
jerespecially in a programming language, because it's something people will use, and it'll be a support burden22:42
jerif you had a Person object, and you wanted to have it use the Animalish trait22:43
jerbut you didn't always want that22:43
jeryou could just define a new object: AnimalishPerson := Person clone do(uses(Animalish))22:43
jerrather than figuring out which instances you want to remove the trait from22:43
prologicI can see both sides here22:50
prologicon one hand you could rewrite your code22:50
prologicand rerun22:50
prologiccreate a different instnace22:51
prologiccould we say that traits are like bases in python's class system22:51
prologic(not really, but sort of)22:51
prologicand that Python doesn't expose that very well (if at all) to the user22:51
prologici.e: it's a tuple (immutable)22:52
prologicso therefore Python does not support deleting basses of a class once defined22:52
prologiceven though strictly speaking that's not true because if you worked hard enough you could do it22:52
jeroh you can delete a trait22:55
jerafter it's defined22:56
jerTrait := nil22:56
jeror Traits removeSlot("YourTrait")22:56
jerit won't affect any objects that currently use that trait22:56
jerbut... =] nobody else will be able to use it22:56
prologicno I meant delete a trsit from an object22:56
prologicthe use of one22:56
prologicif you don't nkow Python internals22:57
prologicPython classes store their base classes in __bases__22:57
prologicwhich is a tuple of classes22:57
prologictuples are immutable22:57
prologicbut the __bases__ attribute is not immutable22:57
prologicso in theory you can still modify a classes's bases22:57
*** mkroehnert has joined #io23:00
prologicI'm torn23:09

Generated by 2.11.0 by Marius Gedminas - find it at!