not a question, just a fun thing with syntax_tools

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Bengt Kleberg-3
greetings,

i have a erlang pretty printer built upon syntax-tools (by Richard
Carlsson, thank you very much). i just noticed that it will re-write my
ugly code for me.

New = [1|[2|Old]],
will pretty print as
New = [1, 2 | Old],

does this mean i have finally found an argument to support not using
emacs? :-)

and will syntax_tools be able to refactor my functions soon?


bengt



Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Ulf Wiger-4
On Wed, 21 May 2003, Bengt Kleberg wrote:

>does this mean i have finally found an argument to support
>not using emacs? :-)

While working at AXD 301, you are allowed to use any editor
(I know both vi and textedit have been used), as long as you
comply with the indentation rules in the Emacs Erlang mode.
;-)

There is even a design rule to this effect:

"Indentation shall be according to the Erlang mode for
emacs"

(actually, this is part of a recommendation - not a rule -
outlining preferred coding style. It says other wise things
too, like "Comment on principles and ideas rather than
details. Never forget that bad programming practice cannot
be explained away. It must be rewritten." We stole that
last part from Joe.)

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes



Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Vance Shipley-2
The vi/emacs religious wars aside ..

Im my humble opinion exposing the emacs specific (and broken) way
of indenting is just plain wrong.  The source shouldn't be tied to
the editor.  That's just obvious.  Indentation should be done with
tabs, that should be obvious.  A consistent number of spaces is
not bad either.  The emacs way is just ugly and makes it hard for
the rest of us.

        -Vance


Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Ulf Wiger (AL/EAB)
The recommendation at AXD 301 had very little to do with what
was considered the prettiest way to indent code. There was one
editor available that provided an indentation mode for Erlang,
so we chose that in the name of consistency.

Even then (and still), some programmers did not like emacs.
That's fine, but we want our code to be written in a consistent
way. This simplifies maintenance and debugging, and in large
projects, the most common scenario is that the person
maintaining a program is not the same person who wrote it.

Personally, I think emacs is a great editor with really quirky
keyboard shortcuts, but you can get used to anything.  ;-)

/U

----- Original Message -----
From: "Vance Shipley" <vances>
To: <erlang-questions>
Sent: den 21 maj 2003 20:01
Subject: Re: not a question, just a fun thing with syntax_tools


> The vi/emacs religious wars aside ..
>
> Im my humble opinion exposing the emacs specific (and broken) way
> of indenting is just plain wrong.  The source shouldn't be tied to
> the editor.  That's just obvious.  Indentation should be done with
> tabs, that should be obvious.  A consistent number of spaces is
> not bad either.  The emacs way is just ugly and makes it hard for
> the rest of us.
>
> -Vance


Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Vance Shipley-2

Given that Emacs is supposed to be the end all be all of everything can
it not be coaxed to put out normal tab based indentation?

        -Vance

On Wed, May 21, 2003 at 11:01:17PM +0200, Wiger Ulf wrote:
}  The recommendation at AXD 301 had very little to do with what
}  was considered the prettiest way to indent code. There was one
}  editor available that provided an indentation mode for Erlang,
}  so we chose that in the name of consistency.


Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Chris Pressey
In reply to this post by Vance Shipley-2
On Wed, 21 May 2003 14:01:51 -0400
Vance Shipley <vances> wrote:

> The vi/emacs religious wars aside ..
>
> Im my humble opinion exposing the emacs specific (and broken) way
> of indenting is just plain wrong.  The source shouldn't be tied to
> the editor.  That's just obvious.

In more ways than one - programs aren't linear!

But if you try to improve on it, say by introducing a 2D notation, you
risk tying the source to an obscure, custom editor - ends up much worse
than simply declaring an arbitrary text editor, like say, emacs, as
official.

So, I'll bet we'll still be using text files to represent program source
code in 2081.  What the world could use is a brilliantly clever editor
that can display the source in any number of arrangements as determined
by the essential structure of the program.

I think Gabriel touched on this in 'Patterns in Software' - if you say
  a(X) -> b(c(X)).
and the optimizer and the editor both 'know' this, then you should be
able to see and/or type a(X) and b(c(X)) interchangeably while working
on your program.  For example, have some key binding that switches
between the 'collapsed' and 'expanded' forms, kind of like the +/-
buttons in the 'tree view' in most modern GUIs.  I would love this.

It could also help the situation Joe rants about in his Why OO Sucks
article - it doesn't matter where data declarations really "are", so
long as the programmer can choose to see them all in one place, or
individually, as they choose, and so long as the compiler knows where to
find them...

> Indentation should be done with tabs, that should be obvious.

Tabs are the work of the devil.  Repent, sinner.  :)

-Chris


Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Vance Shipley-2
In reply to this post by Vance Shipley-2

Just for the record vim (the modern vi) now comes with an Erlang mode.

        -Vance



Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Thomas Lange
I would not say that it has an "Erlang mode". There is a syntax file for
Erlang which colorizes the text according to the types of lexical
entities. It doesn't really understand syntactic entities. Not being
fully satisfied with the stock syntax file, I have tried experiments in
improving it. I think you can get nice results...

I think code formatting requires a perceptive mind with a bit of talent
for aesthetics. No mode is going to provide that.

On a related topic: With a small Vim macro, you can fold Erlang
functions into an outline which you can then expand and collapse at
will. Vim does a very nice job of managing folds.

~Thomas


Vance Shipley wrote:

>Just for the record vim (the modern vi) now comes with an Erlang mode.
>
> -Vance
>
>
>  
>




Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Michał Ptaszek
Since we're on the subject, has anyone come across SciTE from
http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer
out-of-the-box, but I've been working on two versions. Both have syntax
highlighting, one has folding based on indentation depth, the other
folds on (limited) syntax parsing. They're both a bit green, but I use
SciTE almost exclusively and it suits me. The source will compile for
M$-Windows as well as *NIX, and the editor has a pleasant GUI and tool
integration.

I'm planning to feed back my work into the SciTE project so that Erlang
becomes one of the many languages it supports. But before I do, is
anyone interested in giving it a spin and offering some criticism?

Pete.

Thomas Fee wrote:

> I would not say that it has an "Erlang mode". There is a syntax file for
> Erlang which colorizes the text according to the types of lexical
> entities. It doesn't really understand syntactic entities. Not being
> fully satisfied with the stock syntax file, I have tried experiments in
> improving it. I think you can get nice results...
>
> I think code formatting requires a perceptive mind with a bit of talent
> for aesthetics. No mode is going to provide that.
>
> On a related topic: With a small Vim macro, you can fold Erlang
> functions into an outline which you can then expand and collapse at
> will. Vim does a very nice job of managing folds.
>
> ~Thomas
>
>
> Vance Shipley wrote:
>
>> Just for the record vim (the modern vi) now comes with an Erlang mode.
>>
>>     -Vance
>>
>>
>>  
>>
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

not a question, just a fun thing with syntax_tools

Richard Carlsson-4
In reply to this post by Bengt Kleberg-3
----- Original Message -----
From: "Bengt Kleberg" <eleberg>
Sent: Wednesday, May 21, 2003 10:04 AM

> does this mean i have finally found an argument to support not using
> emacs? :-)
>
> and will syntax_tools be able to refactor my functions soon?

It is already -- if you switch to Emacs and use Luke Gorrie's Distel. :-)

    /Richard


Reply | Threaded
Open this post in threaded view
|

SciTE (was: Re: not a question, just a fun thing with syntax_tools)

Chris Pressey
In reply to this post by Michał Ptaszek
On Thu, 22 May 2003 07:11:42 +0100
Peter-Henry Mander <erlang> wrote:

> Since we're on the subject, has anyone come across SciTE from
> http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer
> out-of-the-box, but I've been working on two versions. Both have
> syntax highlighting, one has folding based on indentation depth, the
> other folds on (limited) syntax parsing. They're both a bit green, but
> I use SciTE almost exclusively and it suits me. The source will
> compile for M$-Windows as well as *NIX, and the editor has a pleasant
> GUI and tool integration.
>
> I'm planning to feed back my work into the SciTE project so that
> Erlang becomes one of the many languages it supports. But before I do,
> is anyone interested in giving it a spin and offering some criticism?

I found the port, built it, and tried it.

Overall, I like it.

I'm disappointed that it doesn't seem to have a way to simulate tabs -
or if it does, it hides it unecessarily.  (Tabs are definately one of my
pet peeves.  When I press left arrow, I want the cursor to move left one
space.  Not three spaces, not eight spaces - just, one space, like
always.  I like predictability in an editor.)

I also couldn't see anything about defining or applying macros.
Although complete-word is nice, as is folding, and block comments...
Don't know yet if it's enough to break my unhealthy nedit addiction.
But an Erlang mode might push it over the hump :)

-Chris


Reply | Threaded
Open this post in threaded view
|

SciTE (was: Re: not a question, just a fun thing with syntax_tools)

Michał Ptaszek
Hi Chris,

If you're willing to recompile the source, here's the source for Erlang
support. The files are for v1.53, but do a diff just to be sure my files
don't walk all over things. Hopefully I haven't missed anything.

The lexer colours the source file, but the folding algorithm is a bit
primitive. It folds "case", "fun", "if" and "receive" statements, but I
would also like it to fold function clauses too, which will require a
better lexer and syntax analyser. I wish to use
http://spirit.sourceforge.net which is recursive descent, easy to
understand, and thanks to C++ templates I can practically copy the
Erlang EBNF spec straight into C++ code. Nice.

There's also user-defined folds which are marked thus:

%{ fold start
%} fold end

...and I find that's quite neat already.

I've also enclosed the .SciteUser.properties file I use which uses
spaces instead of tabs. (You'll notice I was using the Matlab lexer
until I got tired of it and rolled my own.)

The spaces-for-tabs option is not available in any of the menus, but
there are _so_many_ options that I think the menus would become
impractical if they were all included!

Let's see if this weans you off the nedit addiction (-: Nedit doesn't
look all that bad really, so why is it so unhealthy? The one possible
advantage of SciTE is that it works on M$-Windows too, but why would I
want to do that?

Pete.

Chris Pressey wrote:

> On Thu, 22 May 2003 07:11:42 +0100
> Peter-Henry Mander <erlang> wrote:
>
>
>>Since we're on the subject, has anyone come across SciTE from
>>http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer
>>out-of-the-box, but I've been working on two versions. Both have
>>syntax highlighting, one has folding based on indentation depth, the
>>other folds on (limited) syntax parsing. They're both a bit green, but
>>I use SciTE almost exclusively and it suits me. The source will
>>compile for M$-Windows as well as *NIX, and the editor has a pleasant
>>GUI and tool integration.
>>
>>I'm planning to feed back my work into the SciTE project so that
>>Erlang becomes one of the many languages it supports. But before I do,
>>is anyone interested in giving it a spin and offering some criticism?
>
>
> I found the port, built it, and tried it.
>
> Overall, I like it.
>
> I'm disappointed that it doesn't seem to have a way to simulate tabs -
> or if it does, it hides it unecessarily.  (Tabs are definately one of my
> pet peeves.  When I press left arrow, I want the cursor to move left one
> space.  Not three spaces, not eight spaces - just, one space, like
> always.  I like predictability in an editor.)
>
> I also couldn't see anything about defining or applying macros.
> Although complete-word is nice, as is folding, and block comments...
> Don't know yet if it's enough to break my unhealthy nedit addiction.
> But an Erlang mode might push it over the hump :)
>
> -Chris
>
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: .SciTEUser.properties
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030523/9b5b4f1d/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SciTE-1.53-Erlang.tgz
Type: application/x-gtar
Size: 30300 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030523/9b5b4f1d/attachment.gtar>

Reply | Threaded
Open this post in threaded view
|

recursive-descent parsing (was: Re: SciTE (was: Re: not a question, just a fun thing with syntax_tools))

Ulf Wiger-4
On Fri, 23 May 2003, Peter-Henry Mander wrote:

>The lexer colours the source file, but the folding
>algorithm is a bit primitive. It folds "case", "fun", "if"
>and "receive" statements, but I would also like it to fold
>function clauses too, which will require a better lexer and
>syntax analyser. I wish to use
>http://spirit.sourceforge.net which is recursive descent,
>easy to understand, and thanks to C++ templates I can
>practically copy the Erlang EBNF spec straight into C++
>code. Nice.

I started making a recursive-descent version of yecc a while
back. The idea was that the generated code would be pretty
enough that you'd want to read it.

It was never finished. If anyone thinks the idea is
interesting, you can have my code and run with it.
I started with the erlang grammar for my tests. This was a
mistake, I think, since there is a lot of code needed
besides the generated code to e.g. compile a .erl file.

Anyway...

The following yecc clause:

case_expr -> 'case' expr 'of' cr_clauses 'end' :
   {'case', element(2, '$1'), '$2', '$4'}.

currently expands to this in the generated code:

case_expr(Ts, Match, Skip, S) ->
   match_rule(['case', 'expr', 'of', 'cr_clauses', 'end'], Ts,
              fun(Result, Ts1, S1) ->
                    X = {'case',element(2,'?v1'),'?v2','?v4'},
                    Match(X, Ts1, S1)
              end, Skip, S).


Where Match is a dynamically created continuation.

A clause with multiple branches:

receive_expr -> 'receive' 'after' expr clause_body 'end' :
   {'receive', element(2, '$1'), [], '$3', '$4'}.
receive_expr -> 'receive' cr_clauses 'end' :
   {'receive', element(2, '$1'), '$2'}.
receive_expr -> 'receive' cr_clauses 'after' expr
clause_body 'end' :
   {'receive', element(2, '$1'), '$2', '$4', '$5'}.


Translates to this:

receive_expr(Ts, Match, Skip, S) ->
   match_rules(
       [
        {['receive', 'cr_clauses', 'after', 'expr',
          'clause_body', 'end'],
         fun(Result, Ts1, S1) ->
               X = {'receive',element(2,'?v1'),
                    '?v2','?v4','?v5'},
               Match(X, Ts1, S1)
         end},
        {['receive', 'after', 'expr', 'clause_body',
          'end'],
         fun(Result, Ts1, S1) ->
               X = {'receive',element(2,'?v1'),
                    [],'?v3','?v4'},
               Match(X, Ts1, S1)
         end},
        {['receive', 'cr_clauses', 'end'],
         fun(Result, Ts1, S1) ->
               X = {'receive',element(2,'?v1'),'?v2'},
               Match(X, Ts1, S1)
         end}
       ], Ts, Skip, S).


The idea was to maintain the structure of the grammar as far
as possible, so that it would not be much harder to write
the parser code by hand than to write the actual yecc
grammar (the code generated from esyntax.yrl has 2.6 times
more lines of code than esyntax.yrl does; compared to the
normal yecc output, which expands it >17 times, it's a fair
improvement in that regard.) Also, the parser still operates
on one token at a time.

Another idea was that grammars like the SQL grammar and
megaco_text_parser are really pushing the limits of what's
feasible with the current yecc (my opinion.)

Enough rambling. I may be barking up the wrong tree, but if
anyone wants to try and finish it, you can have the code.

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes



Reply | Threaded
Open this post in threaded view
|

SciTE (was: Re: not a question, just a fun thing with syntax_tools)

Chris Pressey
In reply to this post by Michał Ptaszek
On Fri, 23 May 2003 12:58:39 +0100
Peter-Henry Mander <erlang> wrote:

> Hi Chris,
>
> If you're willing to recompile the source, here's the source for
> Erlang support. The files are for v1.53, but do a diff just to be sure
> my files don't walk all over things. Hopefully I haven't missed
> anything.

OK, thanks!  I'll try it out.

> The lexer colours the source file, but the folding algorithm is a bit
> primitive. It folds "case", "fun", "if" and "receive" statements, but
> I would also like it to fold function clauses too, which will require
> a better lexer and syntax analyser. I wish to use
> http://spirit.sourceforge.net which is recursive descent, easy to
> understand, and thanks to C++ templates I can practically copy the
> Erlang EBNF spec straight into C++ code. Nice.
>
> There's also user-defined folds which are marked thus:
>
> %{ fold start
> %} fold end
>
> ...and I find that's quite neat already.

If I may make a suggestion - I'd like to see folds on lists and maybe
tuples, too.  Especially in file:consult/1 format files.  Often when
you're coding in a 'data driven' style, lists can get kind of hairy,
spanning multiple lines and so forth...

Um... also, is there a way to, say, fold all funs, but just the funs?
That would be handy (sometimes I've got one function with a dozen funs
inside it (being the easiest way to use bound variables from the main
function) and they really clutter the main logic.)

> I've also enclosed the .SciteUser.properties file I use which uses
> spaces instead of tabs. (You'll notice I was using the Matlab lexer
> until I got tired of it and rolled my own.)

OK, thanks again - thanks to yvan as well for pointing this out.

> The spaces-for-tabs option is not available in any of the menus, but
> there are _so_many_ options that I think the menus would become
> impractical if they were all included!

Yeah, I didn't notice the "Edit [Local/User/Global] Options..." menu
item; this approach makes more sense now.

> Let's see if this weans you off the nedit addiction (-: Nedit doesn't
> look all that bad really, so why is it so unhealthy?

It's not actually that bad - I was exaggerating.  It is rather
heavyweight, though (Motif-based.)  I'd like to be able to jettison
OpenMotif if I can... almost everything else I use regularly (sylpheed,
dillo, gimp, &c) is GTK-based.

> The one possible
> advantage of SciTE is that it works on M$-Windows too, but why would I
> want to do that?
>
> Pete.

It's not as much a matter of 'want' as 'have to', sometimes :)

-Chris


Reply | Threaded
Open this post in threaded view
|

SciTE (was: Re: not a question, just a fun thing with syntax_tools)

Michał Ptaszek
> > If you're willing to recompile the source, here's the source for
> > Erlang support.
> OK, thanks!  I'll try it out.

Any feedback will be received with thanks :-)

> If I may make a suggestion - I'd like to see folds on lists and maybe
> tuples, too.

I believe that's in there already.

> Um... also, is there a way to, say, fold all funs, but just the funs?
> That would be handy

I don't think SciTE can selectively fold. Besides, how would that work in
the user interface? I don't think SciTE make any distinction between types
of folds.

I'm beginning to wonder if I can write a C node using ei to take advantage
of the Scintilla editor directly from Erlang...

And before anyone mentions Distel+Emacs, I reply peanuts+sledgehammers (-:
You _can_ have too much of a good thing! :-)

Pete.




Reply | Threaded
Open this post in threaded view
|

SciTE (was: Re: not a question, just a fun thing with syntax_tools)

Chris Pressey
On Mon, 26 May 2003 00:21:23 +0100
"Peter Mander" <erlang> wrote:

> > > If you're willing to recompile the source, here's the source for
> > > Erlang support.
> > OK, thanks!  I'll try it out.
>
> Any feedback will be received with thanks :-)

So far, so good.  All set up how I like it now, and the Erlang language
support works great.  nedit is now history.

> I don't think SciTE can selectively fold. Besides, how would that work
> in the user interface?

Hmmm... right-click the +/- icon, then select
  "Collapse all of this type (fun)"
from a pop-up menu...?

> I don't think SciTE make any distinction
> between types of folds.

Unfortunate, but understandable - anyway, something to bring up to the
SciTE dev team rather than here.

Thanks again,
-Chris