[nem-en] loving Nemerle

[Kamil Skalski]

Well, I think that it would be a little bit too limiting for users...
Especially, that the question remains which style do we want to
enforce... In fact currently we have a small piece of such validation,
with -pedantic-lexer option compiler warns about usage of tabs in
sources, so maybe it's not that bad idea.
Maybe the way to do this elegantly would be to develop a separate
tool, which would use Nemerle.Compiler.dll library and provide it's
own "validating lexer / parser" pipelines, which would just parse all
sources in the project and show the places where style / formatting
issues are found (according to specified rules). I don't need such
tool myself, but if anyone does, it shouldn't be that hard to develop
(feel free to ask about hints).

I like the idea of IDE managed source code, though it has the one very
important problem, it is not very portable. Language, whose usage is
limited to one (or even several) IDEs doesn't feel like being general
purpose.

Today at work we had a short discussion about possibility of having
auto-formatting always enabled in IDE or even set up script, which
would reformat sources at every CVS commit. Actually it souded like a
joke - formatting tools have many problems, sometimes the result of
formatting is.. *ugly* and also merging the reformatted source code
from the branch is a hell (ok, maybe if every file were initially
correctly formatted it wouldn't be a problem).

And finally, I don't think that code formatting make any problems,
maybe beside readability of code
not-formatted-in-your-favourite-style.


05-10-27, Niki Estner <n.estner at gmx.de> napisał(a):
>
>
> > -----Original Message-----
> > From: devel-en-bounces at nemerle.org [mailto:devel-en-bounces at nemerle.org]
> > On Behalf Of Sean L. Palmer
> > Sent: Thursday, October 27, 2005 6:31 AM
> > To: devel-en at nemerle.org
> > Subject: Re: [nem-en] loving Nemerle
> >
> >
> > >>Great job, keep it up, and I very much look forward to trying out the
> > >>indentation-based syntax in a future release.  And are there plans to
> > >>infer types of private class methods?  (cuz i'll gladly test-drive
> > >>that too :)
> > >>
> > >>
> > >
> > >Thanks! I'm also curious if people will find the indentation syntax
> > >useful in Nemerle.
> > >Some already tried: http://d.hatena.ne.jp/akiramei/20051020#p1
> > >Indeed, language have a different feel this way, though I would be a
> > >little bit scary about whitespaces ruling semantics of my program...
> > >We are planning a new release soon and this feature will be there for
> > everybody.
> > >
> > >
> > I thought about this recently and it seems to be more of an IDE display
> > and UI issue than anything.
> >
> > Think about it, why can the IDE not take code like this:
> >
> > foo { bar { baz } } bam
> >
> > and display it to you as you edit, like this:
> >
> > foo
> >      bar
> >           baz
> > bam
> >
> > but you can configure the indentation level.  Or if you really like the
> > brackets, like this:
> >
> > foo {
> >     bar {
> >         baz
> >     }
> > }
> > bam
>
> Just a little note from a "working-class programmer": It can be quite
> annoying to maintain code that was written by people with different
> indention styles (opening brace on the same line, tabs vs. spaces etc.).
> Having a compiler that would actually accept both of the code samples above
> as equivalent... well, let's just say I wouldn't want to maintain code
> written in that language. Smart IDEs reduce the problem, but sometimes
> they're simply not smart enough. IMHO it would be better if the compiler (at
> least optionally) would enforce correct indention _and_ bracing.
> Suggestion: Function bodes, namespace, class and property definitions must
> always have braces+indention, in all the other places it's optional, but if
> you have braces, they must match the indention. If you don't, you get an
> error or a warning, depending on a compiler setting. How's that?
>
> > Or in fact in any other way which you find easier to edit!
> >
> > When saving, it converts indentation back into brackets so that it will
> > compile.  In fact it could be implemented as a preprocessor that
> > converts Nemerle embedded in HTML into raw text Nemerle.  (then use a
> > WYSIWYG HTML editor to write code.)  I am not sure why people refuse to
> > leave pure ascii text editors behind in the dustbin of history.
> > Similarly, why do people still hate HTML email?
> >
> > >Yes, the inference on global level is a planned feature:
> > >http://nemerle.org/bugs/view.php?id=213
> > >And it is quite probable that Michal will implement it sooner or
> > >later, as this is a subtopic of his PhD studies.
> > >
> > That will be wonderful.
> >
> > Keep up the good work guys.  I hope to have time to play more with
> > Nemerle soon.
>
> Me too!!!
>
> Niki
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.12.4/146 - Release Date: 21.10.2005
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


--
Kamil Skalski
http://nazgul.omega.pl