Re: Io on .NET?

--- In iolanguage%40yahoogroups.com">iolanguageyahoogroups.com, Steve Dekorte <steve...> wrote:
&gt; Likewise for the JavaVM, Parrot, Rubinious,
> Smalltalk VMs, etc.

In your opinion, what is the more appropriate VM for Io?

&gt; I would be interested to see an Io-like interpreter implemented in
Lua
> though.

Do you mean a Io interpreter written in Lua or a Lua-like VM for Io?

Messages in this topic (5) Reply (via web post) | Start a new topic

.

On 2008-03-17, at 12:55 AM, arkadijsha wrote:
&gt;> Likewise for the JavaVM, Parrot, Rubinious,
>> Smalltalk VMs, etc.
>;
> In your opinion, what is the more appropriate VM for Io?

Ideally, you'd want something with no concept of classes, built
entirely on dynamic messaging, with a flexible slot lookup system.

>> I would be interested to see an Io-like interpreter implemented in
> Lua
>> though.
>
> Do you mean a Io interpreter written in Lua or a Lua-like VM for Io?

An Io interpreter written in Lua and compiled with LuaJIT. One nice
side effect of a Lua implementation is that we'd get stacklessness
(and movable stacks) for free. I started tinkering with this but
haven't had time to work on it.

- Steve

Messages in this topic (6) Reply (via web post) | Start a new topic

.

On 2008-03-17, at 1:29 AM, Steve Dekorte wrote:
&gt; An Io interpreter written in Lua and compiled with LuaJIT. One nice
>; side effect of a Lua implementation is that we'd get stacklessness
> (and movable stacks) for free. I started tinkering with this but
> haven't had time to work on it.

A bit more on this:

What I was thinking of doing is implementing an Io "lite". Basically,
the same Io syntax but with less dynamic blocks and no lazy argument
semantics. Io lite's control structures would be implemented using
blocks instead of lazy evaluation of arguments, for example.

An Io lexer and parser would be written in Lua (a few pages of code)
and would produce an AST which would be re-written as Lua code but
with Io's dynamic message semantics for all ops. The basics of Io's
primitive types (Number, Sequence, List, etc) would be re-implemented
in Lua (tens of pages of code) and these would be used (not Lua's raw
types). The Object primitive Lua implementation would implement Io's
object model via Lua's metatables.

The result would be a language that had Io's simple syntax and
consistent, pure OO semantics and prototype based object model but
we'd trade some flexibility for performance (I'm guessing it could be
several times faster than Ruby, Python or Perl).

- Steve

Messages in this topic (7) Reply (via web post) | Start a new topic

.

On Mon, Mar 17, 2008 at 6:36 AM, Steve Dekorte < steve%40dekorte.com">stevedekorte.com> wrote:
&gt; On 2008-03-17, at 1:29 AM, Steve Dekorte wrote:
&gt; > An Io interpreter written in Lua and compiled with LuaJIT.
> A bit more on this:
&gt;
> What I was thinking of doing is implementing an Io "lite".

I, for one, would love to see this. Thoughts along these lines had
crossed my mind, actually. I'll contextually inject some of my
thinking here.

> An Io lexer and parser would be written in Lua (a few pages of code)
&gt; and would produce an AST which would be re-written as Lua code but
> with Io's dynamic message semantics for all ops.

The lexer/parser could leverage LPeg:
http://www.inf.puc-rio.br/~roberto/lpeg/

> The Object primitive Lua implementation would implement Io's
>; object model via Lua's metatables.

Yes, correct.

> The basics of Io's primitive types (Number, Sequence, List, etc) would
&gt; be re-implemented in Lua (tens of pages of code) and these would be
> used (not Lua's raw types).

I was envisioning thin 'wrapper' like things that used the generalized
object system and leveraged Lua's types 'under the hood'...

> The result would be a language that had Io's simple syntax and
> consistent, pure OO semantics and prototype based object model...

That also runs anywhere Lua runs. (!)

My opinion:
I am personally very attracted to Io's lazy argument evaluation, I
would like to see this preserved in the Lua implementation. To me,
this means preserving the call object inside of methods/blocks, and
the ability to choose when (and how) the argument messages are
evaluated. It seems this functionality would be difficult to build in
without basically reimplementing the Io interpreter/runtime in Lua.
But, it sounds like you've got something else in mind. (?)

I'd be super interested to hear more of your thoughts on this, Steve.

Regards,
-Harold

Messages in this topic (8) Reply (via web post) | Start a new topic

.

On 2008-03-17, at 10:54 AM, Stefan O'Rear wrote:
&gt; How about just using call-by-name? That is to say, ALL arguments are
> implicitly enclosed in blocks. Have method(x, foo) generate code that
>; calls the block, so in the non-lazy case it's as usual. Sure it would
&gt; carry some cost, but Io Lite sounds static enough to build a useful
&gt; compiler for, and compiler technology for dealing with call-by-name
> and
> related conventions efficiently already exists.

It's a clever idea, but I'd expect something like a 4x drop in
performance for this technique. I guess we'd need to do some tests to
get real numbers. For me, giving up on the full dynamic semantics
isn't attractive unless the performance is extremely good.

Messages in this topic (10) Reply (via web post) | Start a new topic

.

On 2008-03-17, at 10:45 AM, Harold Hausman wrote:
&gt;> The basics of Io's primitive types (Number, Sequence, List, etc)
>>; would
&gt;> be re-implemented in Lua (tens of pages of code) and these would be
>&gt; used (not Lua's raw types).
>
> I was envisioning thin 'wrapper' like things that used the generalized
> object system and leveraged Lua's types 'under the hood'...

Yes, that's what I was thinking. What I meant is that no Io lite
operation above the primitive wrappers would be on a raw Lua data type
- everything op would be a dynamic message send.

>> The result would be a language that had Io's simple syntax and
>> consistent, pure OO semantics and prototype based object model...
>
>; That also runs anywhere Lua runs. (!)
>
> My opinion:
> I am personally very attracted to Io's lazy argument evaluation, I
> would like to see this preserved in the Lua implementation. To me,
> this means preserving the call object inside of methods/blocks, and
> the ability to choose when (and how) the argument messages are
> evaluated. It seems this functionality would be difficult to build in
> without basically reimplementing the Io interpreter/runtime in Lua.
>; But, it sounds like you've got something else in mind. (?)

Right, the idea of Io lite is to give up lazy eval and Io's higher
level block semantics in exchange for good performance.

- Steve

Messages in this topic (11) Reply (via web post) | Start a new topic

.

On 17-Mar-08, at 4:31 PM, Steve Dekorte wrote:

>
&gt; On 2008-03-17, at 10:45 AM, Harold Hausman wrote:
&gt;>> The result would be a language that had Io's simple syntax and
>>> consistent, pure OO semantics and prototype based object model...
>>
>> That also runs anywhere Lua runs. (!)
>>
>> My opinion:
>> I am personally very attracted to Io's lazy argument evaluation, I
>&gt; would like to see this preserved in the Lua implementation. To me,
>> this means preserving the call object inside of methods/blocks, and
>> the ability to choose when (and how) the argument messages are
>> evaluated. It seems this functionality would be difficult to build in
>&gt; without basically reimplementing the Io interpreter/runtime in Lua.
>;> But, it sounds like you've got something else in mind. (?)
>
>
&gt; Right, the idea of Io lite is to give up lazy eval and Io's higher
&gt; level block semantics in exchange for good performance.

Not to be pedantic here, but messages are eagerly evaluated in Io even
if their contents are not evaluated. What Io has better described as
deferred evaluation, though not 100% accurate either. But lazy has a
whole other meaning.

>
>
> - Steve
&gt;
>
>
>; =
> =
> ======================================================================
> Groups related to iolanguage
> =
> =
> ======================================================================
>
> self-interest (25 common members)
> http://groups.yahoo.com/group/self-interest?v=1&amp;t=ipt&;ch=email&amp;pub=groups&slk=aftr0&amp;sec=recg
> Programming Languages/Object Oriented: This list is for discussion
> of the Self object ori...
&gt;
> extremeprogramming (23 common members)
> http://groups.yahoo.com/group/extremeprogramming?v=1&t=ipt&ch=email&pub=groups&amp;slk=aftr1&sec=recg
&gt; Programming Languages/Object Oriented: Discussion of Extreme
> Programming practices and pr...
&gt;
> testdrivendevelopment (23 common members)
> http://groups.yahoo.com/group/testdrivendevelopment?v=1&t=ipt&ch=email&;pub=groups&slk=aftr2&sec=recg
> Computers & Internet/Software: We discuss the theory and practice of
> test-driven ...
>
> Firebird-Java (20 common members)
> http://groups.yahoo.com/group/Firebird-Java?v=1&;t=ipt&;ch=email&amp;pub=groups&slk=aftr3&amp;sec=recg
> Computers & Internet/Programming Languages: Discussion list for Open
> Source development of Jav...
&gt;
> concatenative (18 common members)
> http://groups.yahoo.com/group/concatenative?v=1&;t=ipt&;ch=email&amp;pub=groups&slk=aftr4&;sec=recg
> Computers & Internet/Programming Languages: The best introduction to
> this subject is at the Jo...
&gt;
>
> ------------------------------------
&gt;
> Yahoo! Groups Links
&gt;
>
>

Messages in this topic (12) Reply (via web post) | Start a new topic

.

On Mar 17, 2008, at 1:37 PM, Jeremy Tregunna wrote:

> Not to be pedantic here, but messages are eagerly evaluated in Io even
>; if their contents are not evaluated. What Io has better described as
> deferred evaluation, though not 100% accurate either. But lazy has a
> whole other meaning.

I was wondering which boat I fell off of ;)
Lazy eval has a very specific meaning to me too-

Anyway- I thought I'd add my commentary because it might be more
relevant to "future direction&quot; kinds of discussions- it's focused
around "why I don't use or recommend Io as a language/platform for
internal/external commercial development"- and there's really only 2
reasons:

1) everything is multi-proc/core these days, and the handling of that
in Io is still in question-
Distributed Objects are the master solution, but at this point I
simply cannot endorse Io to build an app that can only use one of my
CPUs/cores
(the app in question is a hardcore network client+;server, meant to
push 1gbps+ per instance)
(correct me if I'm wrong here about threading etc, I haven't been
following things as closely as usual)

2) the Addon scope is "strange"- I don't like the delineation there- I
think that a firm division needs to be thought about-
As in: "The core language provides network functionality via libevent,
it is maintained and you can rely on it" - if it's there, it needs to
be solid- and if it's not? Well then just give me super-easy access
directly to some external C lib.
To me, the Addons just provide another layer of complexity that I
shouldn't have to deal with- I want a core language and a core
functionality and beyond that I expect to make use of external libs-
the Addons just obfuscate things for me-

x) related to that, one bug that I discovered in Io was the C-lib
loader/handler not handling a void pointer from C-land correctly, and
eating memory voraciously- any C libs I would use for commercial
things are going to be heavily documented and can probably be relied
upon, but it's things like that that make me nervous- to me, a clean
functional 100% reliable C interface is key

-SS

Messages in this topic (13) Reply (via web post) | Start a new topic

.

On Mon, Mar 17, 2008 at 2:37 PM, Jeremy Tregunna < jtregunna%40blurgle.ca">jtregunnablurgle.ca> wrote:
&gt; On 17-Mar-08, at 4:31 PM, Steve Dekorte wrote:
&gt; > On 2008-03-17, at 10:45 AM, Harold Hausman wrote:
&gt; >>&gt; The result would be a language that had Io's simple syntax and
> >>&gt; consistent, pure OO semantics and prototype based object model...
> >>
> >> That also runs anywhere Lua runs. (!)
> >>
> >> My opinion:
> >> I am personally very attracted to Io's lazy argument evaluation, I
> >> would like to see this preserved in the Lua implementation. To me,
> >> this means preserving the call object inside of methods/blocks, and
> >> the ability to choose when (and how) the argument messages are
> >> evaluated. It seems this functionality would be difficult to build in
> >> without basically reimplementing the Io interpreter/runtime in Lua.
>; >> But, it sounds like you've got something else in mind. (?)
> >
>; >
>; > Right, the idea of Io lite is to give up lazy eval and Io's higher
&gt; > level block semantics in exchange for good performance.
>
> Not to be pedantic here, but messages are eagerly evaluated in Io even
>; if their contents are not evaluated. What Io has better described as
> deferred evaluation, though not 100% accurate either. But lazy has a
> whole other meaning.
>

Hi Jeremy,

Thanks for being pedantic. I was merely trying to use the same
terminology Steve was using to make sure I understood what he was
suggesting. This is probably the last mailing list in the world that
you'd have to explain this use of the word 'lazy'

Whatever you want to call it, don't take it away, it's my favorite part of Io.

-Harold

Messages in this topic (14) Reply (via web post) | Start a new topic

.