Perl 6 - the future is here, just unevenly distributed

IRC log for #6macros, 2015-04-28

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:56 ilbot3 joined #6macros
01:56 Topic for #6macros is now 6macros: discussing the finer points of Perl 6 macros, Qtrees, and how to stay sane | irclog: irclog.perlgeek.de/6macros/today
03:42 vendethiel joined #6macros
05:07 vendethiel joined #6macros
05:36 vendethiel joined #6macros
06:39 vendethiel joined #6macros
07:09 Ven joined #6macros
08:55 Ven joined #6macros
11:21 Ven joined #6macros
11:23 vendethiel joined #6macros
14:02 Ven joined #6macros
14:06 vendethiel joined #6macros
15:44 masak joined #6macros
16:30 vendethiel joined #6macros
17:10 vendethiel joined #6macros
18:16 vendethiel I wonder why everyone sells their language as having "type inference"
18:16 vendethiel auto a = 5; isn't type inference, it's type computation
18:16 vendethiel much in the same sense I can do a().b().c() without having to cast every single expression there.
20:02 masak *nod*
20:02 masak what's your criterion for "real" type inference? that the computation goes both top-down and bottom-up?
20:03 vendethiel that's what seems to be what's accepted in papers, at least that's what it seems to me
20:04 vendethiel I mean
20:04 vendethiel the (most?) common definition
20:06 vendethiel it can even work surprisingly well
20:06 vendethiel c++ has "variadic templates"
20:06 vendethiel template<class... Types> void foo(Types...) {}
20:14 * masak starts writing an abstract for a "Category Theory for programmers" course abstract for Edument
20:14 masak s:2nd/abstract //
20:14 * vendethiel will finish his shitty story :P
20:14 vendethiel so, variadic template thing, can be very useful for the crazy meta-programming they do
20:15 vendethiel since well there's no "list" or "array" type
20:15 vendethiel the the real "type inference" thing that works remarkably well is *double variadic templates*
20:15 vendethiel template<class A..., class... B> void f(std::tuple<A...>, B...) { ... }
20:15 vendethiel the compilers are to fill correctly the tuple part
20:16 vendethiel and leave only the correct types for B...
20:16 vendethiel which means
20:16 vendethiel std::tuple<int, int> mytuple(1, 3);
20:16 vendethiel f(mytuple, true);
20:16 vendethiel will work.
20:17 vendethiel that's type inference to me
20:19 masak I... almost follow.
20:19 masak what I get from this is that C++ templates are quite powerful, if weird and ugly.
20:20 vendethiel well, it knows where to "split" the types
20:20 vendethiel can I make some part clearer?
20:20 vendethiel wait
20:20 vendethiel http://stackoverflow.com/questions/15043527/two-variadic-templates-for-a-single-function
20:20 vendethiel that'll maybe be more readable
20:24 * masak clicks
20:25 vendethiel boo
20:26 masak no, I don't think I'm deep enough in C++ to really appreciate that. sorry.
20:26 vendethiel alright. it's pretty deep already in the "madness" part
20:26 vendethiel I'll translate that to Perl6 code, considerign we have splatted types parameters
20:28 vendethiel role Tuple[*::T]{/*tuple with the types T[0], T[1], ... T[n] */};
20:28 vendethiel You can use this one as "Tuple(True, 0);" which is really "Tuple[Bool, Int](True, 0);"
20:28 masak ok.
20:29 vendethiel role F[*::T, *::Other] { method invoke(Tuple[*T] $tuple, Other *@args) { /* @args[0] has type Other[0], @args[1] has type Other[1] */ } }
20:29 masak *nod*
20:29 vendethiel now I can
20:29 vendethiel my $tuple = Tuple[Bool, Int](True, 0);
20:29 vendethiel F.invoke($tuple, "hey")
20:30 vendethiel and that'll be F[T=[Bool, Int], Other=[Str]]
20:30 masak that last line doesn't seem to quite work in Perl 6.
20:30 vendethiel the compiler has been able to "split a splat"
20:30 masak you'd have to qualify F with type parameters.
20:30 vendethiel ;-)
20:30 masak but I think I see the point a bit better.
20:31 vendethiel okay, I think I can translate this to simple perl6 actually!
20:31 masak btw, did you see http://irclog.perlgeek.de/perl6/2015-04-28#i_10517697 ?
20:31 vendethiel last try
20:31 masak I'd like to explain to you (when you're done explaining stuff to me) what I want to do with that blog post.
20:32 vendethiel amazing :)
20:32 vendethiel sub add($a, $b, $c){$a+$b+$c}; /* the compiler knows add() takes 3 args*/ sub f(*@addargs, *@otter){ say @otther };
20:32 vendethiel sub add($a, $b, $c){$a+$b+$c}; /* the compiler knows add() takes 3 args*/ sub f(*@addargs, *@otter){ f(|@adddargs); say @otther };
20:32 vendethiel sorry, fixed it.
20:32 masak oki
20:32 vendethiel now, here, since the compiler knows add() can only be called with 3 arguments
20:33 vendethiel it'll only "slurp" 3 arguments
20:33 vendethiel and leave the rest to @otther
20:33 vendethiel effectively printing 4
20:33 masak I... don't think that's how * works in perl 6
20:33 vendethiel no, it's definitely not
20:34 vendethiel that's how "..." work in c++'s templates
20:34 masak I see.
20:34 vendethiel it knows where to stop
20:34 vendethiel because it wouldn't be valid otherwise
20:35 vendethiel alright
20:35 vendethiel that wasn't all that interesting in the end
20:35 vendethiel not worth such commotion
20:35 vendethiel but hey, at least I managed to end up explaining myself correctly :P
20:35 masak ;)
20:36 vendethiel i'm all ears now :)
20:36 masak ok, so
20:36 masak blog post
20:36 masak first solution, in actual today-Perl 6 would be
20:36 masak a heredoc with a specification of the problem in a nice clean syntax
20:37 masak sent to a function which constructs a bunch of lambdas out of the parsed input
20:37 masak and calls them and solves the problem
20:37 masak expectation: a lot of people would say "hey, that's *cheating"! you didn't solve it *in Perl 6*"
20:37 masak even though it's a very "sixish" solution: build a language that's fit for the purpose, and solve it in that
20:37 masak grammars make this a whole lot more painless in Perl 6
20:38 masak but of course, it *is* cheating
20:38 masak so
20:38 masak second solution
20:38 * vendethiel would call anyone using EVAL a cheater :P
20:38 masak solve it *in an actual grammar*
20:38 masak it's not EVAL, at least not a Perl 6 EVAL
20:39 vendethiel where remove' ls x = filter (/= x) ls
20:39 masak it's building (a compiler for) a smaller language and solving the problem in there
20:39 vendethiel who doesn't write that as `(flip filter) . (/=)` anyways.
20:39 masak ;)
20:39 * masak is guessing mjd++ is a Haskell newbie
20:39 vendethiel >  which constructs a bunch of lambdas out of the parsed input
20:39 vendethiel that's not using EVAL?
20:39 vendethiel .oO( USEING eval )
20:40 masak second solution: write out the solution *in an actual grammar*, which has the appropriate backtracking semantics
20:40 masak this tends to be TimToady's favorite/recommended solution, incidentally
20:40 masak but it trips the "uuurgh, ugly" filter
20:40 masak deliberately
20:40 masak so
20:40 masak third solution: outline how macros would solve this
20:41 masak by introducing enough control flow modifying semantics to actually write out the solution directly in (macro'd) Perl 6
20:41 masak but at the same time having enough control to alter the control flow and add backtracking
20:41 vendethiel ah; backtracking is the article's issue?
20:41 vendethiel i'm barely at the middle
20:42 masak this is the "optimal" solution, and *in itself* is a good enough reason to have decent macros the way I/we envision
20:42 masak in fact, I daresay it's probably the most convincing use case I've come across so far
20:42 masak even though it's a bit toy-ish
20:42 vendethiel if it can be done in normal haskell, with ease, shouldn't it be doable in normal perl6 much the same? =P
20:42 masak so I'm thinking if I can pull off this blog post right, I can then use this as the flagship example of why we need good macros
20:43 masak to be able to effortlessly do stuff like this
20:43 masak actually, one question came up as I thought of this
20:43 masak namely, whether the macro(s) in question would create the altered control flow "the hard way", by painstakingly tweaking Qtrees
20:43 vendethiel ahhh.
20:44 vendethiel mmh, that's interesting, there was something about creating a prolog-like lang in "on lisp"
20:44 masak or whether there could be a "standard combinator library" containing combinators such as "now, introduce a lexical scope from here on out to the end of the surrounding scope"
20:44 * masak bumps "on lisp" on his reading list
20:44 vendethiel I mean, I'd all be for a combinator library :)
20:44 masak me too
20:44 vendethiel basically, in on lisp's code (and before you actually use said code for the prolog)
20:44 masak but I don't have enough know-how yet to create one
20:45 vendethiel you're basically building a... idk how it's called. a pseudo-word-matching-AI?
20:45 vendethiel that tries to recognize sentences
20:45 vendethiel much in the same way a grammar does
20:45 vendethiel and so, paul grahams adds a macro to define functions with backtracking and such flow control
20:46 vendethiel (it pretty much just adds an argument "continuation" and rewrites a few thing in the body <- code walker right here)
20:47 masak aha
20:47 vendethiel because common lisp doesn't have continuations
20:47 vendethiel the author just wanted to show they could be added to match scheme's
20:47 vendethiel without too much syntactic overhead :-)
20:47 vendethiel come to think of it, grammars is another place we have a feature that doesn't exist in the mainline
20:47 vendethiel (that is, continuations)
20:48 vendethiel (and yeah, they exist in "take", but that's pretty limitated :P)
20:48 vendethiel (the other place I'm thinking of right now is signature-style matching)
20:49 vendethiel aaand i can't find my on lisp pdf anymore
20:54 vendethiel bah.
20:54 vendethiel so, yeah, seems like rewriting functions inside the scope to be coroutines of some sort or something would be fun
21:01 vendethiel *and* in line with your talk about goto :D
21:01 masak PDF is at first link in http://www.paulgraham.com/onlisp.html
21:02 masak I don't think I'm actually talking about rewriting into coroutines here
21:02 vendethiel that'd be like the haskell solution here though
21:02 masak I'm basically just rewriting (on the fly) a seemingly flat block of code to contain (implicit) loops
21:02 vendethiel "a complete atn parser" here, that was it
21:03 masak the closest thing that's come up like this is an `amb` keyword to simulate non-deterministic programming
21:04 vendethiel http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf 322 "an atn compiler" if you're interesting
21:04 vendethiel no, sorry!
21:05 vendethiel it's actually 307 (written as 294 here) "22.4 Common Lisp Implementation"
21:05 vendethiel the scheme right before doesn't have to define its own thing
21:05 masak oki
21:05 vendethiel but to come back to the talk
21:05 masak thanks
21:05 vendethiel it seems to me like you're not only adding for loops
21:06 masak in this case, yes
21:06 vendethiel you're also adding some kind of "backtracking" (as in going deeper in several areas "at the same time")
21:06 vendethiel and a "fail" operation that marks a path as wrong
21:06 masak hm
21:06 masak only in the sense that guards correspond to some kind of `next`
21:06 vendethiel sure :)
21:07 vendethiel mabye i'm looking for a mechanism that ends up being too general
21:07 masak right, I just want to solve this particular problem well
21:08 vendethiel the puzzles themselves don't make sense to me, that's probably why I don't find a concrete solution
21:08 masak they don't make sense?
21:08 vendethiel they're not uhhh
21:09 vendethiel feeling natural
21:09 masak it's just "find numbers for these letters"
21:09 masak or digits, even
21:09 vendethiel that part's easy
21:09 vendethiel i'm talking about the puzzles you talk about in your blogs, say :)
21:10 masak oh!
21:11 masak that might simply be due to my poor expository skills
21:11 vendethiel nope, I've just not been exposed to this kind of stuff much
21:12 masak I see
21:12 vendethiel that's a very interesting problem though
21:12 masak I guess things like the recent labyrinth post?
21:12 vendethiel yes
21:12 vendethiel given the parameters and the output, guess the implementation :P
21:13 masak I have a follow-up to the labyrhinth post that I want to write.
21:13 masak that'll have to happen later, though
21:14 vendethiel :)
21:14 vendethiel i considered writing an equivalent to scalaz in perl6
21:14 vendethiel called siz :D
21:14 vendethiel but I'm not sure how it'd look like from here
21:16 masak :)
21:20 vendethiel and, uuhhh.
21:21 vendethiel I think grammars would work for that situation, but mostly because as said -- they're really continuations in some sense
21:21 vendethiel except for the guard part at the end maybe
21:23 masak no, that's just a {? ... } assertion.
21:24 vendethiel ahh mhhh true :D
21:24 masak what do you think of https://gist.github.com/masak/fa8e1819346118c0b6e4 ? :)
21:24 vendethiel well, then, it's a derived use of grammars
21:24 vendethiel > Welcome to the world of category theory.
21:24 vendethiel I refuse to believe in some One True God :-)
21:24 masak hehe
21:25 masak I'm planning to send this abstract to my boss just to see what happens
21:25 vendethiel no Idris? :P
21:25 masak oh! Idris!
21:25 * masak adds
21:26 vendethiel I think yoneda is much easier than martin-löf's "stuff"
21:26 vendethiel :P
21:26 masak good point
21:26 * masak reverses order
21:26 vendethiel recursion vs guarded corecursion would be very interesting, also
21:26 vendethiel explaining how total programs can have "infinite loops"
21:26 masak ooh
21:26 masak yeah
21:27 masak both added.
21:27 vendethiel Covariance and contravariance <- do you not like bivariance and invariance? :P
21:27 masak meh
21:27 masak those are derived concepts, by and large
21:27 vendethiel are you gonna explain that, i.e., parameters are in contravariant pos.
21:28 vendethiel and that returns are in co
21:28 masak oh yes
21:28 masak that's my primary example
21:28 masak and that parameters in parameters are again co
21:28 masak (which happens when you pass a comparator to sort, for example)
21:28 vendethiel Isomorphism <- are you gonna explain what composes an isomorphism?
21:28 vendethiel (in the "bijection" sense)
21:29 masak hm. not sure what you mean.
21:29 masak a morphism is an isomorphism if it has an "opposite" morphism such as the two compose to id.
21:29 vendethiel that's true, but not very mathematical-y :-)
21:30 masak still not sure what you're after, more exactly
21:30 vendethiel if you have an injection and a surjection, you have a bijection
21:30 masak *nod*
21:30 masak but that's true in Set
21:30 vendethiel are you going to explain the injection and surjection parts
21:30 masak not necessarily in other categories, AFAIU
21:31 vendethiel I think that's correct here
21:31 vendethiel at least
21:31 masak more precisely, in other categories, injection != monomorphism and surjection != epimorphism
21:31 vendethiel that's more "mathematically correct" than saying "there's f . g = id"
21:31 vendethiel right
21:31 vendethiel maybe you want to talk about monomorphisms and epimorphisms then :)
21:32 masak yeah, probably
21:32 vendethiel don't if you don't feel like it!
21:32 vendethiel i'm just quoting this because it made sense to me when I learned it all
21:32 vendethiel .oO( good old times, weren't they )
21:33 vendethiel I only read 30 pages or so of aluffi chapter 0 :/
21:34 vendethiel reading c++'s standard and my perl5 book took "precedence" (because they're at the right spot in my house)
21:34 masak heh
21:35 * masak submitted the abstract for review to $boss and two colleagues
21:35 vendethiel amazing :-)
21:35 vendethiel .oO( I'll teach this course when you'll be fed up with it, in a few years )
21:35 masak :D
21:35 masak speaking of courses, I'm having a kind of renewed interest in TypeScript
21:36 masak thinking about finishing up my course abstract for it, too
21:36 vendethiel "infernu looks better!"
21:36 vendethiel ( https://github.com/sinelaw/infernu - in haskell )
21:36 masak oh! I did! it's already in there. nevermind.
21:36 * masak checks out infernu
21:37 masak just from glancing at the README.md
21:37 masak it does look interesting
21:38 masak but a lot less polished than TypeScript
21:38 masak and not nearly as usable in practice
21:38 vendethiel definitely :-)
21:38 vendethiel but much better
21:38 vendethiel given:
21:38 vendethiel function (a) { return a; }
21:38 masak forgive me if I'm judging it too quickly here
21:38 vendethiel it infers the type `t -> t`
21:38 vendethiel not `any -> any` like TS
21:38 masak maybe inferny deserves a mention in the TypeScript course.
21:38 vendethiel it's MUCH better than TS' type sytem
21:38 vendethiel (which is even unsound)
21:38 vendethiel inferny :P
21:39 * masak adds infernu as an issue in the issue system
21:39 masak infernu* :)
21:39 vendethiel .oO( you're not nearly usable in practice if people can't spell your name )
21:39 vendethiel infernu is pretty new
21:39 masak I'm not 100% sober. which is why I could write that CT course abstract.
21:39 vendethiel that's what I want to believei
21:39 vendethiel hahaha, I can understand that feeling :D
21:40 masak I basically only do CT-related stuff while drunk.
21:40 masak it's too weird sober.
21:40 masak I'll have to get drunk to give that course, too.
21:40 vendethiel that's... an interesting take
21:40 vendethiel I only drink with friends, usually to play some game
21:40 vendethiel (oftentimes, tabletop RPGs)
21:41 masak I went to the pub, had dinner and two beers, and read through all the top Math Overflow answers by Terry Tao.
21:42 vendethiel seems like a great afternoon!
21:42 vendethiel which I'll have to end for me, since it's almost midnight
21:42 masak 'night
21:43 vendethiel best of luck with that
21:43 masak :)
21:43 vendethiel please ping with me further info :D
21:43 masak will do
21:43 masak please come work for us so you can give the course after I get tired of it ;)

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary