6 ms·
Creating domain-specific languages in Julia using macros
- deleted 9y ago[deleted]
- kensai 9y agoDon't miss the video [https://www.youtube.com/watch?v=rAxzR7lMGDM https://www.youtube.com/watch?v=rAxzR7lMGDM] of his ideas.
- ViralBShah 9y agoThanks for posting the link. David Sanders is an amazing speaker, and the best person to learn Julia from, if you get a chance. There's a bunch of his videos in the Julia channel on Youtube.
- cutler 9y agoWhat's the chance of Julia ever reaching 1.0 realistically? It seems to be turning into another Perl6.
- KenoFischer 9y ago1.0 is the next major version (there'll be an 0.7 to give us an extra deprecation cycle and start 1.0 without any depwarns, but 0.7 will essentially be identical to 1.0 otherwise). You can follow the 1.0-blocking issues here: https://github.com/JuliaLang/julia/milestone/4 https://github.com/JuliaLang/julia/milestone/4.
- jrs95 9y agoPerl 6 is awesome though...guess I'm learning Julia tonight!
- zaphar 9y agoJulia macros are one of it's best features. They are every bit as powerful list macros. Something very few non lisp languages can say.
- dmpk2k 9y agoUnrelatedly, have the Julia devs decided to require variable declaration yet? E.g. "local x = 1" instead of just "x = 1"? Or better yet, "x := 1"? How many times does this mistake have to be repeated in various languages? It'll just be a matter of time before people are banging on for a strict mode, and rightfully so. At least the default scope in Julia is local. :/
- jwdunne 9y agoPython and Ruby do this without a problem. Many others do it too. If there's a set of complaints about those two languages, variable scope isn't in the top ten. If you're gonna do lexical scoping or some variation of, defaulting to the current scope makes the most sense. Defaulting to global scope is what causes the issue, not choice of keywords.
- ptx 9y agoNot entirely without a problem. Not being explicit about declaring variables means you need to be explicit about not declaring variables when assigning to a variable in an enclosing scope, i.e. Python's "nonlocal" and "global" keywords. (Which is, if not a problem, at least a little ugly.)
- jwdunne 9y agoI thought about this. I would just avoid the need of declaring a variable with the same name as one in the enclosing scope. That means minimisation of global variables, minimisation of lexical pyramids, etc. Generally good things with or without explicit declarations. If you're creating a closure, that's inherent part of the enclosing scope. Just like variable reuse is discouraged for clarity, so it should in closures. I think declaring a global variable deep in scope sounds like recipe for hell. I think declaring a global with a name as short as you'd use in function parameters is a mistake. I don't see how it'd be a problem if you follow practices that encourage maximum clarity. If I could see an example, it'd make it easier to understand your point - I haven't seen the problem you describe so it's difficult for me to visualise it.