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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!