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 28 July 2015.
03:09 vendethiel joined 08:12 FROGGS joined 08:38 Ven joined
masak Ven: I've been mulling over your point about operators as methods. 08:57
Ven hi
masak yo
Ven: I think it would be possible to do that, but I think the losses would be significant.
Ven conflating both as Qtypes?
masak no, deeper than that
as a first reason, lexical subs enjoy many advantages because some of their existence is statically scoped. 08:58
this means (among other things) that operators can be macros.
if they were methods, I don't think they could be.
because method dispatch is Late.
Ven well, everything would need to be late-bound 09:01
that's why you'd need to declare fixity etc upfront OR just have fixed fixity OR have a static type system
masak yeah 09:04
let's just say, as Perl 6 stands today, all other things being equal, you'd lose ops-as-macros 09:05
Ven ya 09:08
"fixed fixity" as in scala would totally work 09:10
I'm gonna go ahead and actually say I'd prefer that... because stuff like haskell's fixity is absolutely insane
Especially the fact you can change the fixity of an infix call...
(i.e. fixity `foo` 3) 09:11
masak *nod* 09:13
I confess that at this point, most precedence/custom-op systems other languages have seem more or less insane/broken compared to what Perl 6 offers :) 09:16
Ven I've seen too much crazy stuff to enjoy custom precedence 09:29
masak that's what I like about Perl 6's custom precedence. it makes some kind of sense. 09:49
of course, I maintain that in 007 I got it slightly more right :P 09:50
Ven ;-) 09:51
masak (in Perl 6, two ops can accidentally get the same precedence because their precedences were created with the same tighter/looser instruction. that can't happen in 007) 09:52
11:39 Ven joined
Ven mmmh 12:02
maybe there's a point to make that late-bound OO has less niceties if you have macros
(not by design, but because macros can fill in)
masak it's a little bit of that, and of its converse 12:34
a language with many late-bound things, and many facilities to "reduce the pressure" caused by design needs -- like Perl 6 -- pushes the need for macros out to ever more unlikely semantic niches 12:35
Ven well, perl 6 has its fair share of inconsistencies and corner cases... 12:41
masak yes, of course 12:55
and some of those will be exposed as part of exposing the macro API
Ven :/ 12:57
masak ...which is largely good, because it will give people a bigger surface to go in and "fix" some of them 12:58
Ven no, I disagree 13:00
that's forcing a burden on people
I don't want to have to think, when coding, that I need to use .WHAT before comparing, because it's itemized, because the list I'm mapping is an Array, not a List
Itemization plainly shouldn't exist. I'd like a better module system, where I can alias classes, java-style "use". The fact I can import specific symbols is pretty good already, though. 13:01
Flattening at all shouldn't have been part of the language. it doesn't bring anything to the table, and it's miles more complicated than perl5's. I need to memorize a whole class of function signatures to know if they're "*@a" or "@a" or "+a" or whateverelse
the dynamic symbols are globals, and for a language that says it likes lexical scope so much, this is pretty sad. Especially as it was solved in every lisp dozens of years ago (even clojure has the right answer). 13:02
I shouldn't have to think "oh yeah, I can't use any() there, because there's a possibility one element of the array might be Mu, and that'll randomly break my code. (having to cap junctions is not that bad, though) 13:03
Lists shouldn't confuse themselves with items. ".[0]" shouldn't be the identity function on non-associatives, but someone wanted hyper-operators to be just a bit too DWIMmy I guess? 13:05
masak you have good points
I think I agree fully about flattening/lists and junctions
dynamicals: yes, I can see the problem. not sure I'm up in arms about fixing it at this point in the game.
Ven it's mostly like "you know all the problem we solve with namespaces and lexical scope? Let's fight them again with dynamics" 13:06
I don't like the fact it *doesn't* conflates strings and lists, but that is a good thing™. just not one I'm used to yet. 13:07
masak I come from the other direction on that one 13:08
viewing all those (mostly FP) languages that do conflate those as... cute, but largely misguided on that point 13:09
actually, let me condemn head/tail-based recursion while I'm at it
Ven yeah. perl6 does the right thing on Unicode
s/on/wrt/
masak it's a 20th century notion which should die under the pavement of monoidal algebra and mapreduce 13:10
anyway, back to the main point: corner cases and macro APIs
Ven I don't like the fact operators have custom fixity. Means you get less of both worlds: you need to define methods such as CALL-ME, and that means if you pass an object "in a pipeline", the pipeline won't have your module importer and you overloaded operators
(though, we don't often overload operators, so that's good) 13:11
it breaks duck typing, that's for sure
masak I *am* passionate about providing a convenience for people who want to build a better Perl 6 (or, more likely, parts of it) to be able to make their userland modification look "native"
JS and Perl 5 have taught me that as long as your language has closures, you can build what you want at the cost of some extra curly braces and commas 13:12
Ven doc.perl6.org/language/traps <- that's a bit of an issue; having such a page before the 1.0 even landed :P. 13:13
masak macros are there partly to eliminate those extra curly braces and commas, making the feature "blend in" with the rest of the language
Ven I don't like containers, but I know not everybody is that passionate about immutability etc as I am :)
ok, I'm done with my rant 13:18
I believe the main thing I'll want to fix will be flattening. The rest is meh
macro idea: a circumfix operator that builds a typed array. 13:20
T[1, 2, 3] will give me an Array[Int] :P 13:21
masak ooh :) 13:44
I like immutability, but I believe the industry/theorics are in a general state of "not quite there yet"
ok, about to ship the refactor 13:46
this commit isn't very big, all in all -- but it did take a lot of work 13:47
I feel I'm not so much making individual changes/patches, as I am making rough brush strokes, then standing back and pondering the result... 13:49
pushed! \\o/ 14:00
now it's back to the last few points of github.com/masak/007/issues/25#iss...156453622, and then we can close #25 :) 14:01
14:29 Ven joined
Ven looks 14:30
17:12 FROGGS joined
masak ladies and gentlebots 17:17
this now works in 007:
$ perl6 bin/007 -e='macro moo() { return Q::Identifier { name: "foo" } }; my foo = 42; say(moo())'
42
in other words, we just got synthetic ASTs 17:18
no doubt there are vast swathes of bugs in there that I haven't discovered yet
it's largely untested
but I want you all to try to stretch your imaginations to what can now be done in 007
hint: macros just got a crapload more powerful
runtime can now create *unhygienic* ASTs.
if you build something cool enough, your contribution might be immortalized in the upcoming examples/ directory :) 17:19
17:58 vendethiel joined
vendethiel cool, cool, cool 18:01
mh, this channel could do with a 007 evalbot =P
masak ooh, yes 18:02
I'm all for that -- would it be an easy thing to extend camelia, you think?
vendethiel camelia is perl5 :( 18:03
but yes
I think it shouldn't be too hard. it needs the appropriate compiling support, though
masak doesn't matter what language camelia is -- it could be Python or Haskell for all I care :) 18:54
re-implementing camelia in Perl 6 just to get 007 running on-channel would be a distraction
vendethiel masak: I can't *declare* a variable yet, though, can I? 21:38
masak Try It And See 21:46
I can't think of a reason it wouldn't work, actually
well
you still can't cheat the parser into believing things that aren't lexically there are there
but assuming you just mean "can I arbitrarily inject Q::Statement::My in code?", the answer is yes 21:47
one point remaining on github.com/masak/007/issues/25#iss...-156453622 21:49
I'll tackle it tomorrow
'night
vendethiel great stuff 21:56
22:49 pdcawley joined 22:58 FROGGS joined 23:12 FROGGS joined 23:32 FROGGS joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!