I can think of an argument for making a parser simpler at the expense of
programmer convenience, and that’s the maintainability and portability
of
the implementation. Some weighing of costs seems to be necessary here -
for
example, by hacking that extra programmer convenience syntax into the
language, you might lose the ability to represent the language grammar
simply and portably. Implementing a parser for Ruby, for example, is
difficult, because there’s no grammar that you can just plug right into
a
parser and lexer generator. I’ve read accounts by people attempting to
implement Ruby interpreters where parsing seems to have been a major
stumbling block. There could be situations where that extra syntax might
just not be worth it.
Mushfeq.
On 5/20/07, [email protected] [email protected] wrote:
I can think of three examples right off the top of my head: Rails, Rake and
RSpec. There’s something really eerie about seeing code like that. You know
it works, but you can’t figure out why or how.
None of those are especially magical if you have a decent understand
of how Ruby works.
method_missing + block syntax does not necessary mean evil black magic.
On Sun, May 20, 2007 at 09:43:15PM +0900, Michael F. wrote:
Let’s try:
describe ‘myself’
it ‘should be readable’
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)
If Ruby looked like that, I’d probably not have bothered – just stuck
with Perl.
“tabs can be made forbidden (g.v.rossum himself said he’d never
supported tabs in the first place if he new what it would cauze)”
Just a bit offtopic: I personally used tabs a lot and told people
that they could adjust them to their space-likings (2 or 4), however
as I comment quite a lot, i did find myself mixing tabs and spaces
so I finally changed, avoid using tabs, and use 2 spaces now
everywhere for code. (2 spaces because i like to keep 80 chars /
line, so i can fit more into a line 
)
On Mon, May 21, 2007 at 03:53:47AM +0900, Trans wrote:
.by(text.amount)
Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I’d much rather just see more
intelligent was to catch missing “end” errors. Even if meant the
option to put “endif”, “endclass”, etc.
I’d prefer we keep the plain ol’ “end” syntax, and use editors that can
do delimiter matching as easily with “end” as with braces, brackets, or
parentheses.
On May 20, 8:43 am, “Michael F.” [email protected] wrote:
RSpec. There’s something really eerie about seeing code like that. You know
lambda
lambda{ @reader.reading }.
should change{ @reader.knowledge }.
by(text.amount)
end
end
(I take it you meant ‘if’ not ‘it’)
well?
Actually, the later is pretty dang ugly --maybe worse the the first.
However colons would help the first example quite a bit:
describe ‘myself’:
if ‘should be readable’:
lambda:
@reader.reading
.should change:
@reader.knowledge
.by(text.amount)
Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I’d much rather just see more
intelligent was to catch missing “end” errors. Even if meant the
option to put “endif”, “endclass”, etc.
T.
T.
On May 20, 3:00 pm, Chad P. [email protected] wrote:
@reader.knowledge
.by(text.amount)
Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I’d much rather just see more
intelligent was to catch missing “end” errors. Even if meant the
option to put “endif”, “endclass”, etc.
I’d prefer we keep the plain ol’ “end” syntax, and use editors that can
do delimiter matching as easily with “end” as with braces, brackets, or
parentheses.
Yes, that would be nice, but I’ve yet to see an editor do it.
T.
I agree that I would like the end statements to become more specific -
at least optionally… I hate when you have a long class file and you
get the dreaded Unexpected end of file, expecting END or something…
and you have no idea where in the 200 lines you forgot to insert an end,
or you left a brace hanging on the line above an end or what not. Even
if we didn’t mandate endif, we could let end do what it does, but with
an optional argument (end if, end class, end def) - I would use these,
and the interpreter would thus be able to catch the error a lot closer
to the source – class not closed at line 50 is more helpful then end of
file at line 230…
Stian
On Sun, 20 May 2007 09:43:00 +0200, Robert K.
[email protected] said:
On 19.05.2007 20:48, M. Edward (Ed) Borasky wrote:
I don’t like to make the reader or parser work any harder than
necessary just for the convenience of the coder.
I would understand why you would want to make the reader’s job easier
- but the parser? That’s just a piece of software and I believe
that we should always strive to make software easier to use for
humans not machines.
In general, I agree. But I don’t want to ignore parsers completely -
the easier a language is to parse, the easier it is for people to
develop tools to work with the language, making programmers’ lives
easier. I’m pretty sure that one of the reasons why there aren’t many
C++ refactoring tools is because the language is incredibly difficult
to parse, for example.
David C.
[email protected]
On May 18, 3:50 pm, “Austin Z.” [email protected] wrote:
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).
Vim does this just fine.
Really? Not the vim I’m using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I’m in either. Worse, if I close a bracket,
and the opening of it is outside the “page”, it does not tell me what
the opening statement was. So… no, I’d say it definitively fails
and is worse than emacs.
Or perhaps there’s a setting I missed?
On 5/20/07, gga [email protected] wrote:
Really? Not the vim I’m using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I’m in either. Worse, if I close a bracket,
and the opening of it is outside the “page”, it does not tell me what
the opening statement was. So… no, I’d say it definitively fails
and is worse than emacs.
Or perhaps there’s a setting I missed?
It’s probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you’d use vim!
On May 21, 9:12 am, “Gregory B.” [email protected] wrote:
It’s probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you’d use vim!
Someone wrote a macro (or whatever it is called) for gvim that
automatically inserts an “end” statement whenever you enter a keyword
that requires an “end”.
for example:
type:
“if cond” and press return
the cursor goes to the next line and an “end” statement appears on the
subsequent line with the proper indentation.
if cond
# cursor at start of this line.
end
On Monday, May 21 2007, Austin Z. wrote:
I have TextMate (but don’t use it), and I’m pretty sure it can do the
same. I’ve heard good things about Kate from Linux users, too.
Indeed, Kate is great (although not as good as what I’veseen/heard about
Textmate) butit certainly doesn’t highlight do…end combinations, only
the
standard [], {}, etc. It may be possible to add support for it,
however.
-Ben
On 2007-05-20 20:45:59 -0700, gga [email protected] said:
types. And most editors can easily find matching braces. No editor I
and the opening of it is outside the “page”, it does not tell me what
the opening statement was. So… no, I’d say it definitively fails
and is worse than emacs.
Or perhaps there’s a setting I missed?
% works, but I’m using a ruby-matchit plugin I found on vim.org. I’m
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.
On 5/20/07, gga [email protected] wrote:
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).
Vim does this just fine.
Really? Not the vim I’m using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I’m in either. Worse, if I close a bracket,
and the opening of it is outside the “page”, it does not tell me what
the opening statement was. So… no, I’d say it definitively fails
and is worse than emacs.
Or perhaps there’s a setting I missed?
I don’t use the cream settings. I use vim with the Ruby settings
available on RubyForge. Now, automatic highlighting isn’t present
(e.g., the same way you get with {}), but you can hit “%” to jump
between matching pairs. It isn’t for everyone, either, but the folding
available with vim does more for me being certain of matched pairs
than anything else (if it doesn’t fold properly, it isn’t likely to
compile properly).
I have TextMate (but don’t use it), and I’m pretty sure it can do the
same. I’ve heard good things about Kate from Linux users, too.
-austin
On 6/1/07, Rick DeNatale [email protected] wrote:
% works, but I’m using a ruby-matchit plugin I found on vim.org. I’m
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.
% in vim does something related to what he’s asking for, but it
doesn’t automatically highlight the matching token when the cursor
lands on it’s mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn’t have to scroll to do so.
Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen
HTH,
Keith
On 6/1/07, Erik H. [email protected] wrote:
On 2007-05-20 20:45:59 -0700, gga [email protected] said:
Really? Not the vim I’m using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks.
% works, but I’m using a ruby-matchit plugin I found on vim.org. I’m
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.
% in vim does something related to what he’s asking for, but it
doesn’t automatically highlight the matching token when the cursor
lands on it’s mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn’t have to scroll to do so.
Personally, I don’t miss it much.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
If you install the Vim/Ruby (http://vim-ruby.rubyforge.org/) plugins
it’ll work with % and do/end.
Also, if you
:set sm
it will highlight briefly the opening of a block by the cursor going
there and back really quickly AND setting the opening and closing
markers in a different color.
There are some options with sm (showmatch) that I don’t recall. Do
:help showmatch
in Vim for details.
My experience with Vim is that if you can think of ANYTHING for Vim to
do, chances are someone thought of it and created a plugin for it
(yes, you can play tetris and sokoban with vim →
(search results : vim online).
If you haven’t, I’d suggest checking the scripts section in vim.org
(scripts : vim online). Also, use the search
(search : vim online) to look for plugins.
HTH
Jerry.
I love indentations too…
Check out my project for Ruby space convention 
http://lazibi.rubyforge.org
It’s code generation.
Jinjing Wang wrote:
I love indentations too…
Check out my project for Ruby space convention
http://lazibi.rubyforge.org
It’s code generation.
You don’t need to do code generation, at least in the way you have done
it. I posted a solution way back up this thread that does not require
the creation of intermediate files to load.
In foo.rb
require ‘pyrb.rb’
END
def foo:
[1,2,3,4].each do |i|:
puts i
[1,2,3,4].each do |j|:
puts i
if i == 2 :
puts “foo”
else:
puts “bar”
foo
See
http://xtargets.com/snippets/posts/show/68
for the details.