<br><br><div class="gmail_quote">On Wed, May 25, 2011 at 10:55 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Wed, May 25, 2011 at 07:58, Vance Shipley <span dir="ltr"><<a href="mailto:vances@motivity.ca" target="_blank">vances@motivity.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


I love the idea of ditching modules files and storing functions<br>
in a data store.  What I'm picturing though is that the functions<br>
are stored in their abstract syntax form (i.e. data) so that the<br>
issue of formatting standards is stripped away.  </blockquote></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><snip><div class="im">
<br>
<br>
The problem with that plan seems to be with the preprocessor.  It<br>
seems to me though that your plan suffers the same problem.  If<br>
macros are defined at a module level, or in an include file, you'll<br>
have to deal with them when you pull the functions out of the module<br>
and stuff it into the data store.  The extended syntax tree used in<br>
the erl_syntax application might be the answer.<br></div></blockquote><div><br></div><div>There are more things that need to be preserved by the parser, which make existing pretty-printers less than good. For example:</div>
<div>

<br></div><div>- integer values can be shown using different bases, from case to case, so one can't use a generic setting. So the parser needs to keep track of that.</div></div></blockquote><div><br>The new parser/tokeniser does I'm not sure if its worked its way in the pretty printers - I do have<br>
some unpublished code that does exact colorization of the source program<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div>- comments have to be anchored somewhere in the code. erl_syntax guesses only almost right. Of course, if there is going to be a more advanced metadata mechanism, the comments belong there too.</div>

<div><br></div><div>Also, I didn't understand where/how are record and macro definitions going to be stored and identified. As somebody else said it too, the best solution would be to get rid of them altogether and it's starting to look more and more like a different language :-) </div>


<div><br></div><div>regards,</div><div>Vlad</div><div><br></div></div>
</blockquote></div><br>