[erlang-questions] Getting rid of the preprocessor

[alisdair sullivan]

you could compile using 'P' or 'E' to get a source listing after preprocessing, compile that and debug from that source. not optimal, but better than not having source at all 

-- 
alisdair sullivan
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, 24 May, 2012 at 6:11 AM, Max Bourinov wrote:

> Ah I see :-)
> 
> The "bad" key-word here is "generic tool provider".
> 
> Maybe good README.markdown file will help somehow? It always helps when code cannot solve everything. 
> 
> Best regards,
> Max
> 
> 
> 
> 
> On Thu, May 24, 2012 at 4:54 PM, Vlad Dumitrescu <vladdu55@REDACTED (mailto:vladdu55@REDACTED)> wrote:
> > On Thu, May 24, 2012 at 2:38 PM, Max Bourinov <bourinov@REDACTED (mailto:bourinov@REDACTED)> wrote:
> > > You are right, it is nearly impossible to properly work with macros in
> > > IDE. I never tried erlide. Does it give any coding performance boost? I use
> > > sublime2 and emacs. Most of Erlangers uses Emacs (as far as I know).
> > 
> > Well, there's a whole bunch of them at Ericsson use erlide, plus
> > others that I only have fragmentary information. Of course, I believe
> > that an IDE helps the development process, but I know that it is a
> > controversial question. Some people like it, some don't.
> > 
> > > About your example: You can agree within your team which macros you will use
> > > and which not. For example:
> > > 1. No complicated code snippets in macros - this is good for code
> > > simplicity.
> > > 2. All atoms that are flying between modules must be in macros. Or even
> > > better - use records for that.
> > > Simple rules - simple code. Macros are good. They are cool. Use right tool
> > > and you have no problems.
> > 
> > Yes, that would be good enough for me -- but as a generic tool
> > provider, I can't force people to follow any rules. There is also the
> > issue of legacy code, that nobody will touch as long as it works.
> > 
> > Anyway, the simple usage you describe above doesn't require a
> > preprocessor, these could be handled inside the language with some
> > additions to the compiler. This would enforce the cleanliness and I
> > don't think anybody would feel sorry about that. For the dirty work,
> > the preprocessor could still be there, if needed.
> > 
> > regards,
> > Vlad
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120524/3ad007d6/attachment.htm>