Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?
From: Caleb Clausen on 11 Jul 2010 16:38
On 7/11/10, Jan Lelis <prog(a)janlelis.de> wrote:
> Caleb wrote:
>> I could write a RubyLexer-based preprocessor which does this pretty
>> easily. However, I'm not terribly motivated. This doesn't seem like
>> that useful a feature to me and I've got so much else to work on....
>
> Cool :). I also want to try to implement it in some way, but at the
> earliest in about a month (also have too many things to do).

If you want help figuring out how to do this, I'll be glad to give you
advice, tho you'll have to write it. Doing something like this the
right way is going to be quite difficult unless you know where to
start, and even after that will be fairly tricky. Unless you're an
expert on parsing ruby, you need the assistance of someone (like me)
who is.

Of course, you could also do this the fragile/wrong way, using a lot
of regular expressions or something, in which case you'll probably be
able to manage it on your own.

From: Robert Klemme on 12 Jul 2010 09:56
2010/7/11 Caleb Clausen <vikkous(a)gmail.com>:
> On 7/11/10, Robert Klemme <shortcutter(a)googlemail.com> wrote:
>> On 11.07.2010 13:32, Caleb Clausen wrote:
>>> On 7/11/10, Robert Klemme<shortcutter(a)googlemail.com>  wrote:
>>>> IMHO this is not feasible: "if<condition>" is almost always followed by
>>>> a line break.  And think about
>>>
>>> Yes, but 'if' itself almost never is.
>>
>> Unfortunately the word "almost" makes this unusable for creating a
>> parser.  How do you want the parser to decide if the case at hand is one
>> of the rare cases?  Even if it would be feasible this sounds like an
>> awful hack and I'd rather not make parsing more complicated (and thus
>> slower) as it is today.
>
> The syntax change I proposed requires forbidding a construct which is
> currently legal but rarely used and considered to be poor style. What
> is wrong with that? In those few cases where someone decided to
> separate an 'if' from its condition with a newline, the code would
> have to be rewritten (inserting a backslash to make the newline soft
> is the easiest way). Such constructs should be rewritten anyway, for
> purely stylistic reasons.

I mostly agree apart from the missing aspect of efforts. Even such a
small change can cause significant other work to be done.

> This new feature, like most,  will make the parser ever so slightly
> slower. The delta is tiny and not worth mentioning.
>
> And it will make the parser a little bit more complicated; however,
> there are already many special cases and complications in the parser.
> One more is not a big deal. The philosophy of ruby's syntax overall is
> to make the parser complicated if it makes life easier for the user. I
> think this change at least ought to be considered under that
> criterion.
>
> Now if you want to argue that Jan's proposal is esthetically
> unpleasing, I won't really disagree. But just leave it at that. I hate
> it when people try to throw up a lot of rhetorical chaff when their
> real, and only valid, objection amounts to a subjective judgment call.

It's not only that. I question the balance of effort and benefit.
Since most code around does not use the new syntax, you will have to
support the old syntax as well. As long as it is not mandatory only
people benefit that use it. OTOH, there is additional effort for
backporting new code to projects that only use an old Ruby
interpreter. Given that we do not have this feature today and most
people seem to be able to write code that gets the nesting right I
wonder what the real benefit of this is given that there will be
development effort for the interpreter, test cases, documentation etc.

Uglyness was really just a side aspect although I agree I should have
made this more clear. Somehow I must have assumed that the other
points are obvious. :-)

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

From: Caleb Clausen on 12 Jul 2010 11:40
On 7/12/10, Robert Klemme <shortcutter(a)googlemail.com> wrote:
> 2010/7/11 Caleb Clausen <vikkous(a)gmail.com>:
>> And it will make the parser a little bit more complicated; however,
>> there are already many special cases and complications in the parser.
>> One more is not a big deal. The philosophy of ruby's syntax overall is
>> to make the parser complicated if it makes life easier for the user. I
>> think this change at least ought to be considered under that
>> criterion.
>>
>> Now if you want to argue that Jan's proposal is esthetically
>> unpleasing, I won't really disagree. But just leave it at that. I hate
>> it when people try to throw up a lot of rhetorical chaff when their
>> real, and only valid, objection amounts to a subjective judgment call.
>
> It's not only that. I question the balance of effort and benefit.
> Since most code around does not use the new syntax, you will have to
> support the old syntax as well. As long as it is not mandatory only

Well, it has to be optional for another reason too: it would be far to
annoying to have to type 'end if' instead of 'end' at the end of every
if statement. I for one wouldn't be willing to sacrifice ruby's
celebrated terseness in this area just to make Jan happy.

> people benefit that use it. OTOH, there is additional effort for
> backporting new code to projects that only use an old Ruby
> interpreter. Given that we do not have this feature today and most
> people seem to be able to write code that gets the nesting right I
> wonder what the real benefit of this is given that there will be
> development effort for the interpreter, test cases, documentation etc.
>
> Uglyness was really just a side aspect although I agree I should have
> made this more clear. Somehow I must have assumed that the other
> points are obvious. :-)

> I mostly agree apart from the missing aspect of efforts. Even such a
> small change can cause significant other work to be done.

Ok, now this is a valid point, and one I tend to forget about.
Complicating code makes related work products more complicated but as
a single-minded engineer I only think about the code.

Additionally, I now see that there are some ambiguities around the
keyword 'do' which would have to be worked through before my proposal
could be implemented. So for example, this is valid currently:

something begin
42
end do
foo
end

But with the proposed new syntax, the 'end do' would be interpreted as
an attempt to end a do block. I'm not sure what, if anything, can be
done about this, or if it's just an issue that can be ignored.

From: Jan Lelis on 12 Jul 2010 12:59
> [...] I question the balance of effort and benefit.
> Since most code around does not use the new syntax, you will have to
> support the old syntax as well. As long as it is not mandatory only
> people benefit that use it. OTOH, there is additional effort for
> backporting new code to projects that only use an old Ruby
> interpreter.

The backporting effort for 99% of the cases: code.gsub /end~(class|
module|def|begin|if|unless|while|until|for|do|case)/, 'end'


> Given that we do not have this feature today and most
> people seem to be able to write code that gets the nesting right I
> wonder what the real benefit of this is given that there will be
> development effort for the interpreter, test cases, documentation etc.

Of course, you are able to write code with the right nesting, else it
wouldn't run ;). That doesn't mean, that it is easy to write or read.

> Uglyness was really just a side aspect although I agree I should have
> made this more clear. Somehow I must have assumed that the other
> points are obvious. :-)

Is it really that ugly? I want to emphasize that the additions would be
optional. I really think of using it only, when there are three ore more
consecutive ends. But then, it is really helpful (please also see the
example at bottom).

> [...] Even such a
> small change can cause significant other work to be done.

That is true :/

> If you want help figuring out how to do this, I'll be glad to give you
> advice, tho you'll have to write it. Doing something like this the
> right way is going to be quite difficult unless you know where to
> start, and even after that will be fairly tricky. Unless you're an
> expert on parsing ruby, you need the assistance of someone (like me)
> who is.

Thank you for this nice offer. I would gladly take it :) [but as I said,
I have much to to do, so it would be possible at the earliest in about a
month].

But we still have different opinions about whether the syntax would
involve punctuation. I think with it, the code is better readable in
cases like this:

def test
while 1
puts (1..9).each_slice(3).map do |slice|
sum = slice.inject do |acc, ele|
acc + ele
end

if sum > 6
42
else
99
end~if
end~do.join ','
end~while
end


From: Bob Nadler on 12 Jul 2010 14:34
On Mon, Jul 12, 2010 at 12:59 PM, Jan Lelis <prog(a)janlelis.de> wrote:
>> [...] I question the balance of effort and benefit.
>> Since most code around does not use the new syntax, you will have to
>> support the old syntax as well.  As long as it is not mandatory only
>> people benefit that use it.  OTOH, there is additional effort for
>> backporting new code to projects that only use an old Ruby
>> interpreter.
>
> The backporting effort for 99% of the cases: code.gsub /end~(class|
> module|def|begin|if|unless|while|until|for|do|case)/, 'end'
>
>
>> Given that we do not have this feature today and most
>> people seem to be able to write code that gets the nesting right I
>> wonder what the real benefit of this is given that there will be
>> development effort for the interpreter, test cases, documentation etc.
>
> Of course, you are able to write code with the right nesting, else it
> wouldn't run ;). That doesn't mean, that it is easy to write or read.
>
>> Uglyness was really just a side aspect although I agree I should have
>> made this more clear.  Somehow I must have assumed that the other
>> points are obvious. :-)
>
> Is it really that ugly? I want to emphasize that the additions would be
> optional. I really think of using it only, when there are three ore more
> consecutive ends. But then, it is really helpful (please also see the
> example at bottom).
>
>> [...] Even such a
>> small change can cause significant other work to be done.
>
> That is true :/
>
>> If you want help figuring out how to do this, I'll be glad to give you
>> advice, tho you'll have to write it. Doing something like this the
>> right way is going to be quite difficult unless you know where to
>> start, and even after that will be fairly tricky. Unless you're an
>> expert on parsing ruby, you need the assistance of someone (like me)
>> who is.
>
> Thank you for this nice offer. I would gladly take it :) [but as I said,
> I have much to to do, so it would be possible at the earliest in about a
> month].
>
> But we still have different opinions about whether the syntax would
> involve punctuation. I think with it, the code is better readable in
> cases like this:
>
> def test
>  while 1
>    puts (1..9).each_slice(3).map do |slice|
>      sum = slice.inject do |acc, ele|
>        acc + ele
>      end
>
>      if sum > 6
>        42
>      else
>        99
>      end~if
>    end~do.join ','
>  end~while
> end
>
Hi,
I know it's a bit of a contrived example, and I'm not advocating a version
of "Ruby Golf" here, but if I saw this method in some code I was maintaining
I would refactor it to something like:

def test
while 1
puts (1..9).each_slice(3).map do |slice|
sum = slice.inject { |acc, ele| acc + ele }
sum > 6 ? 42 : 99
end.join(',')
end
end

...or even better, move the "summing" to another method...

def test
while 1
puts (1..9).each_slice(3).map do |slice|
calculate_sum > 6 ? 42 : 99
end.join(',')
end
end

def calculate_sum(items)
items.inject { |acc, ele| acc + ele }
end

I think most cases where the end~if syntax is "necessary" would be better off
(e.g. more readable) with a healthy dose of refactoring.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?