These are chat archives for Gozala/wisp

27th
Feb 2015
Adam Avramov
@egasimus
Feb 27 2015 09:40
@gozala: the glob thing? sorry, I fail to see how this would fit in :/
a defining aspect of my use case: I'm running my Wisp code in a sandbox using https://github.com/felixge/node-sandboxed-module
I'm calling the Wisp compiler is being called from a source transformer (https://github.com/felixge/node-sandboxed-module#sandboxedmodulesourcetransformers), which is sort of per-file
I've decided to heed the vaguely menacing warning in node docs and leave require.extensions alone
Adam Avramov
@egasimus
Feb 27 2015 09:46
And for delivering code to the browser I use browserify with https://github.com/conradz/wispify
I think it's pretty important to have macro imports work across required modules, not only across files
Irakli Gozalishvili
@Gozala
Feb 27 2015 09:49
@egasimus can you elaborate what you mean here ?
referring to last sentence
Adam Avramov
@egasimus
Feb 27 2015 09:52
well, in the end macros compile down to js just fine, right? they're just functions which take some forms and output some other forms, correct? so I think they should eventually end up in something like exports.__wisp_macros__ so you could import the macros from someone else's module and use them to transform your own Wisp code
am I making any sense here? I started systematically reading through the Wisp source just today :D
Irakli Gozalishvili
@Gozala
Feb 27 2015 09:54
@egasimus yeah that pretty matches thinking I had
@egasimus have seen that issues I pointed to you earlier today ?
@egasimus I guess it was yesterday
@egasimus I think there has being discussion about that there
@egasimus anyway the problem there was, how does macros get imported during compile time
one way was to leverage node and just use require and let it either return .js file with macros or .wisp file that it can live compile to js and there for get those macros
@egasimus the issue with that was too tight dependency on node, which would be impossible to support in browser, which currently is supported
Irakli Gozalishvili
@Gozala
Feb 27 2015 09:59
@egasimus that being said I think I could live with that
@egasimus another option was to let compiler deal with dependencies during analyzes phase, when it sees imports it could reach out associated wisp file and anlyze it, import macros along the way.
@egasimus anlyzer is smart enough to understand types of imports like is it a macro, is it a function or maybe a list. If function how many arguments it can handle etc.. That data can be then used to warn user during compile time if for example function is missused or if import is not even defined in the module it’s importing from etc...
But more importatently that no longer would depend on node, so it would work in browsers as well.
Irakli Gozalishvili
@Gozala
Feb 27 2015 10:04
Problem with that is though how to deal with imports that are results of compilaction to js.
& there are several options there as well
  1. To encode inforamtion from analyzer into generated js file, but than it would make compilation output little awkward.
  1. To keep macros separate from non-macros as there is no much point of including macros into generated js.
@egasimus at this point I’m more than happy to support any option if someone is willing to lead the effort.
Irakli Gozalishvili
@Gozala
Feb 27 2015 10:10
@egasimus also I was thinking about exports[‘wisp.macro.name’] = function(…) {} instead as it would be easire for the analyzer and compiler I think
@egasimus so reason why you would not want to include macros into js output is because macros will likely depned on functions from standard lib, like wisp.ast and etc… That will be obsolete for resulting code.
@egasimus there is also an option to generate macros as functions that would take standard library as an argument or require as argument from wisp and the inline imports associated with macros into it, but that just makes whole thing a lot more complicated
@egasimus so I was leaning towards recommending to keep macros in separate modules from the rest of the code
Irakli Gozalishvili
@Gozala
Feb 27 2015 10:15
@egasimus which is what clojurescript does now, although for a different reasons.
Irakli Gozalishvili
@Gozala
Feb 27 2015 10:21
@egasimus I image that is too much info all at once
Adam Avramov
@egasimus
Feb 27 2015 10:48
@Gozala not at all :) Could you clarify on why using require would pose an issue in browsers? As far as I understand Wisp's :require still depends on there being some kind of platform-provided require available anyway? As it is, if you're serving multiple separate modules in the browser you would use something like Browserify -- which provides its own require shim -- or any of the available in-browser module systems (which I have zero experience with tbh).
@Gozala I also imagine it should be easy to have an option to toggle including macros (and their dependencies) being included in the compiled output or not? This could be either a compiler option, or per-module and/or per-macro flag (via metadata)... I can certainly see how a Wisp library which is distributed in its compiled form would want to make its macros available without having to recompile the whole library every time
Adam Avramov
@egasimus
Feb 27 2015 13:34
@Gozala I also don't understand how you're actually :refering a couple of macros here: https://github.com/Gozala/wisp/blob/master/test/protocols.wisp#L2 :D
@Gozala I assume they're just added to **macros** as a side effect of importing the module and the :refer is just for show? Or is there something I'm missing here
Irakli Gozalishvili
@Gozala
Feb 27 2015 19:04
@egasimus good catch! It’s actually there, just to make editor happy :)
@egasimus the reason macros are actually available in those test is because wisp loads this module first https://github.com/Gozala/wisp/blob/master/test/test.wisp
then when node hits requrie(‘./util’) it will load util.wisp file and live transpile it
becasue compiler hit’s the defmacro they will be added to the macros for the compiler instance used by node for live transpiling
as a side effect next wisp module that will be transpiled will have those macros available
@egasimus in other words that line you pointed to is not really necessary
Irakli Gozalishvili
@Gozala
Feb 27 2015 19:09
but there to 1. information purposes 2. Make editor happy 3. I had a hope it would actually do import in a future.
@egasimus I’m afraid I don’t remmebr all the details why I thought coupling with node’s require further was a bad idea. And you right currently you want platform to provide you with requier, although I had a plan to fix that & I think I wanted to make sure I would not introduce more dependncies that would prevent me from that.
Irakli Gozalishvili
@Gozala
Feb 27 2015 19:17
@egasimus oh there was also my ambition to make lua & go backends for wisp so coupling it with runtime forther did not seemed like a good idea. Now thinking about it, I would much rather have macro imports that depend on node’s require than no macro imports, I can deal with those constraints if I do actually get to work on those ideas.

@Gozala I also imagine it should be easy to have an option to toggle including macros (and their dependencies) being included in the compiled output or not? This could be either a compiler option, or per-module and/or per-macro flag (via metadata)... I can certainly see how a Wisp library which is distributed in its compiled form would want to make its macros available without having to recompile the whole library every time

That actually reminded me another idea I had, which was to generate two outputs when file with macro definitions was passed like module.js and module.macros.js so that macro definitions won’t tax the generated js, but would still make it available, alternative would be to let compiler either emit file with macros or file with actual js so you could create two outputs or one.

@egasimus but more I though about it it felt that if library that wishes to export macros could just bundle wisp files and be done with all that.