Forum: Ruby Endless Ruby 0.0.2

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ab870531383eea6e4d9110317f5401e7?d=identicon&s=25 Caleb Clausen (Guest)
on 2009-05-29 04:51
(Received via mailing list)
endless.rb is a pre-processor for ruby which allows you to use
python-ish
indentation to delimit scopes, instead of having to type 'end' every
time.

  http://gist.github.com/117694

Basically, this makes the end keyword optional. If you leave off the
end, the preprocessor inserts an end for you at the next line indented
at or below the level of indentation of the line which started the
scope.
Since endless.rb uses RubyLexer, it should be able to handle almost
all ruby syntax.

Examples:

begin
  a
  b

begin
  a
rescue
  b
else
  d
ensure
  c

class A
  class B
    class C
      module D
        foo

def a b
  c
  d

for i in 1..10 do
  p i
  pp i

To be endless in your own code, you must first require 'endless.rb',
then load files which are written endlessly using Endless.load, rather
than the usual plain vanilla load (or require). (Endless.require isn't
written yet, sorry.)

require 'endless'
Endless.load 'my-endless-code.rb'


Changes in this release:
  Re-worked the way the def keyword is processed, to fix several bugs.
  The new way is even a little bit less hacky.
  Insert a space before implicit ends

Install:
  endless.rb is available as a gist (jest?) on github only:
  http://gist.github.com/117694
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-05-29 05:23
(Received via mailing list)
Caleb Clausen wrote:
> endless.rb is a pre-processor for ruby which allows you to use python-ish
> indentation to delimit scopes, instead of having to type 'end' every time.

Oh dear god no!

Seriously though...neat :)

- Charlie
34a7615f38496a5dafbb3e6b721c435e?d=identicon&s=25 Mohit Sindhwani (Guest)
on 2009-05-29 06:29
(Received via mailing list)
Charles Oliver Nutter wrote:
> Caleb Clausen wrote:
>> endless.rb is a pre-processor for ruby which allows you to use
>> python-ish
>> indentation to delimit scopes, instead of having to type 'end' every
>> time.
>
> Oh dear god no!
>
> Seriously though...neat :)

Both my emotions neatly summed up!

Cheers,
Mohit.
5/29/2009 | 12:28 PM.
163755a5d3a5c57bd79c4f41bdda7a22?d=identicon&s=25 Clifford Heath (Guest)
on 2009-05-29 06:47
(Received via mailing list)
Caleb Clausen wrote:
> To be endless in your own code, you must first require 'endless.rb',
> then load files which are written endlessly using Endless.load, rather
> than the usual plain vanilla load (or require). (Endless.require isn't
> written yet, sorry.)

Ouch. But this is a good candidate for using Polyglot. Just name
your files .rbe, and when you require 'endless', it registers that
extension with Polyglot to be used with the endless loader. Then
you can just "require 'fred'", and it will endless-load "fred.rbe".
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-05-29 15:28
> for i in 1..10 do
>   p i
>   pp i

wonder if do-less ruby would possible, too
 for i in 1..10
   p i
   pp i

or braceless or something

3.times |n|
 puts n


:)
-=r
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-05-29 18:30
(Received via mailing list)
On May 29, 2009, at 12:46 AM, Clifford Heath wrote:

> extension with Polyglot to be used with the endless loader. Then
> you can just "require 'fred'", and it will endless-load "fred.rbe".
>

How would this work?  Would endless.rb just load the polyglot gem
and automatically set itself up?  So all you'd need to do is require
'endless' and
then make some rbe files?
Ab870531383eea6e4d9110317f5401e7?d=identicon&s=25 Caleb Clausen (Guest)
on 2009-05-29 19:22
(Received via mailing list)
On 5/28/09, Clifford Heath <no@spam.please.net> wrote:
> Caleb Clausen wrote:
>> To be endless in your own code, you must first require 'endless.rb',
>> then load files which are written endlessly using Endless.load, rather
>> than the usual plain vanilla load (or require). (Endless.require isn't
>> written yet, sorry.)
>
> Ouch. But this is a good candidate for using Polyglot. Just name
> your files .rbe, and when you require 'endless', it registers that
> extension with Polyglot to be used with the endless loader. Then
> you can just "require 'fred'", and it will endless-load "fred.rbe".

This is very interesting, I could use this in RubyMacros as well. But
then that brings up another issue; what if I want to use both at once?
Aside from the trouble of actually getting the two to work together,
how does a user specify that some particular combination of
preprocessors is to be used? Extending your example, I could use .rbm
for files with macros in them, but what about files without ends and
with macros? .rbem? While Polyglot's extension registration system is
nice, I'm wanting something more sophisticated as well.

Michael Bruschkewitz wrote: (in another thread)
> At breakfast I had the idea it would be possible to implement/apply it to current file 
it by
> simply using
> "require 'tool4endH8ers.rb'" or
> "require 'languageConverter_pyi.rb'" or
> "require 'languageConverter_BASIC.rb'" or
> "require 'languageConverter_f77.rb'" or...
> "require 'applySomeOtherWeirdOptions.rb'" or...
> at the beginning of each file or at the beginning of main file.
> I'm sure some Kernel.magic would make this possible.

I'm not entirely sure, but it seems like he's saying that if you
should be able to require "languageConverter_f77.rb", and then write
the rest of the file in fortran. A bit far-fetched, but I like the
idea of being able to declare the format up at the top of the file,
perhaps with a magic comment.

> Why not think about providing a mechanism which provides this possibility?

Hmm, what about it, Clifford? Seems like an appropriate thing to add
to Polyglot....

PS: the examples on this page got damaged somehow:
http://polyglot.rubyforge.org/
Ab870531383eea6e4d9110317f5401e7?d=identicon&s=25 Caleb Clausen (Guest)
on 2009-05-29 19:23
(Received via mailing list)
On 5/29/09, Roger Pack <rogerpack2005@gmail.com> wrote:
> wonder if do-less ruby would possible, too
>  for i in 1..10
>    p i
>    pp i

You can leave off the do in for, until, and while loops already. I
usually do.

> or braceless or something
>
> 3.times |n|
>  puts n

(shudder). You realize that that one already parses like:

  3.times.|(n).|(puts n)
79f9616c279f40ef953f366dcfe38dc8?d=identicon&s=25 Suraj Kurapati (sunaku)
on 2009-05-31 03:29
Caleb Clausen wrote:
> endless.rb [...] makes the end keyword optional.

I love this idea and already implemented it for eRuby:

  http://snk.tuxfamily.org/lib/ember/#Infer-block-endings

Where '<% end %>' is more laborious to type than 'end'. :)
163755a5d3a5c57bd79c4f41bdda7a22?d=identicon&s=25 Clifford Heath (Guest)
on 2009-05-31 05:06
(Received via mailing list)
Juan Zanos wrote:
>> Ouch. But this is a good candidate for using Polyglot. Just name
>> your files .rbe, and when you require 'endless', it registers that
>> extension with Polyglot to be used with the endless loader. Then
>> you can just "require 'fred'", and it will endless-load "fred.rbe".
> How would this work?  Would endless.rb just load the polyglot gem
> and automatically set itself up?  So all you'd need to do is require
> 'endless' and then make some rbe files?

Exactly. My ActiveFacts gem implements a language called CQL.
When you require 'activefacts/cql', it does this:

require 'polyglot'
module ActiveFacts
  class CQLLoader
    def self.load(file)
      ..
    end
  end
  Polyglot.register('cql', CQLLoader)
end

Now you can require 'fred', and CQLLoader gets to load "fred.cql"
(assuming that "fred.rb" isn't found first). The CQL is translated
into Ruby module and class definitions which are then eval'ed.

Same deal with Treetop. When you require 'treetop', it requires
Polyglot, and does this:

Polyglot.register(["treetop", "tt"], Treetop)

where the Treetop class has a self.load method.

Clifford Heath.
163755a5d3a5c57bd79c4f41bdda7a22?d=identicon&s=25 Clifford Heath (Guest)
on 2009-05-31 05:15
(Received via mailing list)
Caleb Clausen wrote:
>> Ouch. But this is a good candidate for using Polyglot. Just name
>> your files .rbe, and when you require 'endless', it registers that
>> extension with Polyglot to be used with the endless loader. Then
>> you can just "require 'fred'", and it will endless-load "fred.rbe".
>
> This is very interesting, I could use this in RubyMacros as well. But
> then that brings up another issue; what if I want to use both at once?

I think you'd need to create a custom loader that knows how to load the
file having combined syntax.

When Nathan Sobo created Treetop, one of his hopes was that Ruby
could eventually incorporate PEG parsing technology and add his "rule"
keyword. Because PEG parsers are composable, this would allow you to
define new parse rules within a Ruby program, which would integrate
fully into the existing Ruby grammar, or be used to introduce new
sub-languages that mesh in nicely... My take on that was then to
extend Kernel.require so that each file extension used a different
top-level parse rule *from within the combined grammar*, and you have
a full meta-language framework... That's kinda what Polyglot is about.

It's kinda what you're talking about below, but done "properly".

> Aside from the trouble of actually getting the two to work together,
> how does a user specify that some particular combination of
> preprocessors is to be used? Extending your example, I could use .rbm
> for files with macros in them, but what about files without ends and
> with macros? .rbem? While Polyglot's extension registration system is
> nice, I'm wanting something more sophisticated as well.

Rails went with chained processors, like file.html.erb, etc. Polyglot's
loader isn't currently defined to read the input file and yield content
for a subsequent loader, but chaining like that is a possible extension.

> I'm not entirely sure, but it seems like he's saying that if you
> should be able to require "languageConverter_f77.rb", and then write
> the rest of the file in fortran. A bit far-fetched, but I like the
> idea of being able to declare the format up at the top of the file,
> perhaps with a magic comment.
>
>> Why not think about providing a mechanism which provides this possibility?
>
> Hmm, what about it, Clifford? Seems like an appropriate thing to add
> to Polyglot....

It's certainly possible. How would one loader pass output to the next?
I wouldn't want to create the intermediate content as files.

> PS: the examples on this page got damaged somehow:
> http://polyglot.rubyforge.org/

Thanks, I'll look at it.

Clifford Heath.
Ab870531383eea6e4d9110317f5401e7?d=identicon&s=25 Caleb Clausen (Guest)
on 2009-05-31 18:53
(Received via mailing list)
On 5/30/09, Clifford Heath <no@spam.please.net> wrote:
>> This is very interesting, I could use this in RubyMacros as well. But
>> then that brings up another issue; what if I want to use both at once?
>
> I think you'd need to create a custom loader that knows how to load the
> file having combined syntax.

Typically, yes. And that's the biggest challenge. (If you're lucky,
you might be able to make earlier stages of the pipeline tolerant
enough to just pass through new syntax which they don't understand.)

> When Nathan Sobo created Treetop, one of his hopes was that Ruby
> could eventually incorporate PEG parsing technology and add his "rule"
> keyword. Because PEG parsers are composable, this would allow you to
> define new parse rules within a Ruby program, which would integrate
> fully into the existing Ruby grammar, or be used to introduce new
> sub-languages that mesh in nicely... My take on that was then to

That's cool, even if I have no idea how this composable grammar would
work. I have similar goals with RubyMacros, which right now is still
very far from that level of flexibility. I actually
hope macros will be a somewhat more approachable interface to the same
idea.

> extend Kernel.require so that each file extension used a different
> top-level parse rule *from within the combined grammar*, and you have
> a full meta-language framework... That's kinda what Polyglot is about.
>
> It's kinda what you're talking about below, but done "properly".

I can see the attraction of not needing to parse and unparse things
all the time.

> It's certainly possible. How would one loader pass output to the next?
> I wouldn't want to create the intermediate content as files.

Maybe a pipe? I suggest it reluctantly since I don't think my own
tools can use a pipe. Ruby is complicated, and it's nice to be able to
seek back and forth in the input stream. I don't see what's wrong with
a temp file; it's better than a string. Or you can define some kind of
api for connecting preprocessors, but I can't see the advantage of it
over one of those three possibilities.
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-05-31 21:06
Sounds really cool so far, have to test it heavily before I can make an
"informed" opinion (other than right now that I think this rocks. Having
as many options available as possible is always good IMO before
"deciding" on something, in general.)
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-05-31 21:21
Got a problem, perhaps one of you knows how to resolve (note, I did not
use gems but rather installed rubylex 0.7.5 from the tarball):


rubylexer/rulexer.rb:36:in `require': no such file to load --
sequence/indexed (LoadError)
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-05-31 21:23
Ok this is my last remark for some time, else I might appear as spamming
for which I apologize.

I have found sequence, it is on rubyforge too.

Here is the link for others to find it, in case they mightneed it:
  http://rubyforge.org/frs/?group_id=2317&release_id=25335
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-06-01 15:40
Caleb Clausen wrote:
> endless.rb is a pre-processor for ruby which allows you to use
> python-ish
> indentation to delimit scopes, instead of having to type 'end' every
> time.
>
>   http://gist.github.com/117694
>
> Basically, this makes the end keyword optional.

One thought might be to name is "end implied" or "end optional" since
you can still use end :)

Speaking of which, did J Haas ever come up with a way to do

b = case y
  when 3
    4
  end if true

without using an end keyword?

-=r
68a08995ddf9b3f8a0b562ed0baf63af?d=identicon&s=25 Michael Bruschkewitz (Guest)
on 2009-06-04 16:10
(Received via mailing list)
"Caleb Clausen" <vikkous@gmail.com> schrieb im Newsbeitrag > Michael
Bruschkewitz wrote: (in another thread)
>
> I'm not entirely sure, but it seems like he's saying that if you
> should be able to require "languageConverter_f77.rb", and then write
> the rest of the file in fortran.

That's exactly may idea, until next required "converter"... or some end
marker.
It wold be similar to eval_f77 << END_OF_F77CODE ...
Core question remaining: Who writes those converters?

Also:
F77 (or some other compiled langauge) converter could, for example,
automatically wrap and compile the source and create a dynamic library
which
is used through standard require functionality.

This could easily be done by some aliasing for require:
def new_require s
    if s.ends_with? '.f77'
        temporary_lib_name = wrap_compile_and_link s
        old_reqiuire s
    end
end

Get the idea?
All what's needed is to write wrappers for other languages and to speed
up
the process, maybe by checksumming the sources and putting checksum into
lib.
And probably, some problems to be dealt with run-time-lib-initialization
of
the langauges.

Maybe Polyglot does similar things? (Had no time to check - need to
rescue
my child from school now.)
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-04 18:02
(Received via mailing list)
On 4 Jun 2009, at 15:10, Michael Bruschkewitz wrote:
>>> at the beginning of each file or at the beginning of main file.
>>> I'm sure some Kernel.magic would make this possible.
>>
>> I'm not entirely sure, but it seems like he's saying that if you
>> should be able to require "languageConverter_f77.rb", and then write
>> the rest of the file in fortran.
>
> That's exactly may idea, until next required "converter"... or some
> end marker.
> It wold be similar to eval_f77 << END_OF_F77CODE ...
> Core question remaining: Who writes those converters?

I can't help but wonder why bother when you could just write F77 code,
compile it and then use either ruby/dl or ruby-ffi to call it directly
from ruby.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
68a08995ddf9b3f8a0b562ed0baf63af?d=identicon&s=25 Michael Bruschkewitz (Guest)
on 2009-06-06 23:05
(Received via mailing list)
"Eleanor McHugh" <eleanor@games-with-brains.com> schrieb im Newsbeitrag
news:9153164A-BE75-41DB-9774-9C898C90102B@games-with-brains.com...
> On 4 Jun 2009, at 15:10, Michael Bruschkewitz wrote:

>> That's exactly may idea, until next required "converter"... or some
>> end marker.
>> It wold be similar to eval_f77 << END_OF_F77CODE ...
>> Core question remaining: Who writes those converters?
>
> I can't help but wonder why bother when you could just write F77 code,
> compile it and then use either ruby/dl or ruby-ffi to call it directly
> from ruby.

I just want to remove the need for dealing with all those
interface-issues.
If I understood ruby-ffi description, there is a need to know which
types/byte sizes are used in the interface. Further sequence and
alignment.
Also there is a need for knowing how F77 (weird example, I know) handles
parameters, global data, function names etc.

Using converters:
If there is one developer (ex.: mathematician) which knows F77 and
another
developer which knows Ruby are working in one team - none of both would
need
to know how dynamic libraries are created or what a dynamic library in
detail is or if they exist on that particular used platform at all. The
converter could hide all this knowledge, thus allowing the developers to
concentrate on the solution of project-related problems.

This interface knowledge is not related to particular projects, but to
languages. There is only the need for some common interface format. How
interfaces are exported/imported could be completely transparent to the
developer. Such an converter needs to be created only once per language.


Michael B.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-07 19:05
(Received via mailing list)
On 6 Jun 2009, at 22:05, Michael Bruschkewitz wrote:
> another developer which knows Ruby are working in one team - none of
> only once per language.
This is a naive assumption as it ignores the fact that many languages
either have loose standards or no standard at all, therefore the
amount of work required to implement such converters could be many
orders of magnitude greater than that required to learn an FFI
extension such as ruby/dl or ruby-ffi.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
68a08995ddf9b3f8a0b562ed0baf63af?d=identicon&s=25 Michael Bruschkewitz (Guest)
on 2009-06-08 01:05
(Received via mailing list)
"Eleanor McHugh" <eleanor@games-with-brains.com> schrieb im Newsbeitrag
news:EB9CAC98-287B-4BBC-8FFF-3C829F38C47E@games-with-brains.com...
> orders of magnitude greater than that required to learn an FFI
> extension such as ruby/dl or ruby-ffi.

I would not expect the converters to be complete at all. They could just
issue a error message when user tries to use features which are
currently
not supported (by converter or by peer language).

Converters would need to be implemented only once per language and
platform.
By one small team which needs strong knowledge about interface issues
for
this particular language and platform only.

The ruby/dl or ruby-ffi is a different approach, accessing existing
libraries. My thoughts were more RAD-like, hiding existence or
representation details of libraries from the developers.
Maybe I couldn't explain my idea completely, try again:
My assumption was to first create some sort of meta-interface, let's
call it
X. (Similiar to COM or CORBA but probably more general - don't know if
COM
or CORBA currently support some sort of closures, for example.)
So you would need to convert (1) from Ruby to X and (2) from X to F77 to
access F77 function from Ruby. Given other project convert (1) from Ruby
to
X and (3) from X to COBOL to access COBOL function from Ruby. It would
be
even possible to convert (2) from F77 to X and (1) from X to Ruby to
implement Ruby-Scripting into F77.
No need to know how to create DLL's or Shared Objects in F77 or COBOL.
(Have
you ever read the Solaris-Docu for creating shared objects - thousands
of
possibilities for errors and flaws.)

The ruby/dl or ruby-ffi approach still needs interface knowledge in
every
inter-language team. Although it reduces complexity of creating
C-extensions
in Ruby enormeously.
It is also limited to the use of dynamic libraries, maybe additionally
depending on OS-platform and possibly memory models. (Plz correct me if
I'm
mistaken.)

Hope I could explain my idea now.

Michael B.
A20f57356110f62f93f7555a4bbb96af?d=identicon&s=25 KDr2 (Guest)
on 2009-06-08 07:45
(Received via mailing list)
oh no...no....
This topic is locked and can not be replied to.