Nabble - io

Re: The "do" syntax

2009-11-25T22:44:46Z

On 2009-11-25, at 10:18 PM, bronxbomber92 wrote:

> Ahh. So this would be illegal?
>
> number := 1
> Foo = Object clone do (
> bar := number
> )
>
> Btw, thanks for the quick reply!

That would work if number is in the Lobby (as Object inherits from Lobby) but this wouldn't work:

test := method(
number := 1
Foo = Object clone do (
bar := number
)
)

test

Re: The "do" syntax

2009-11-25T22:18:09Z

Ahh. So this would be illegal?

number := 1
Foo = Object clone do (
bar := number
)

Btw, thanks for the quick reply!

--- In iolanguage@..., Steve Dekorte <steve@...> wrote:

>
>
> On 2009-11-25, at 9:12 PM, bronxbomber92 wrote:
>
> > I've seen the Object clone do ( ... ) syntax several times, but I don't see any documentation on it.
> >
> > I can infer that code this:
> >
> > Foo := Object clone do (
> > bar := 1
> > baz := method(bar println)
> > )
> >
> > Is Functionally equivalent to this code?
> > Foo := Object clone
> > Foo bar := 1
> > Foo baz := method(bar println)
> >
> > Are there any other hidden semantics though?
>
> The difference is that the locals context of do() is the object it is being called on - it doesn't have access to the locals in the scope that Object clone do ( ... ) is called in.
>

Re: The "do" syntax

2009-11-25T21:36:26Z

On 2009-11-25, at 9:12 PM, bronxbomber92 wrote:

> I've seen the Object clone do ( ... ) syntax several times, but I don't see any documentation on it.
>
> I can infer that code this:
>
> Foo := Object clone do (
> bar := 1
> baz := method(bar println)
> )
>
> Is Functionally equivalent to this code?
> Foo := Object clone
> Foo bar := 1
> Foo baz := method(bar println)
>
> Are there any other hidden semantics though?

The difference is that the locals context of do() is the object it is being called on - it doesn't have access to the locals in the scope that Object clone do ( ... ) is called in.

The "do" syntax

2009-11-25T21:12:59Z

I've seen the Object clone do ( ... ) syntax several times, but I don't see any documentation on it.

I can infer that code this:

Foo := Object clone do (
bar := 1
baz := method(bar println)
)

Is Functionally equivalent to this code?
Foo := Object clone
Foo bar := 1
Foo baz := method(bar println)

Are there any other hidden semantics though?

Thanks,
Jedd

Ioke

2009-11-24T22:26:57Z

(http://blip.tv/file/2229292/) 25:30 is interesting

Question:

"Usually when someone creates a new language they have something in
mind that they didn't find in another language. Why did you write Ioke"

Answer:

"I wanted to see if the focus on performance in other languages was
one of the problems with them. The goal is expressiveness. ... Ioke
is a language that I created only for me."

From http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html

"The focus of programming language research for the last thirty years
has been to combine the expressive power of high level languages like
Smalltalk and the performance of low level language like C with little
attention paid to advancing expressive power itself. The result has
been a series of languages which are neither as fast as C or as
expressive as Smalltalk. Io's purpose is to refocus attention on
expressiveness by exploring higher level dynamic programming features
with greater levels of runtime flexibility and simplified programming
syntax and semantics."

Re: self == Lobby in activate()?

2009-11-15T00:41:25Z

Steve Dekorte wrote:

> On 2009-11-14, at 10:35 AM, Mike Austin wrote:
> > I changed it to use block() and I do see different behavior -
> > nothing happens
> > at all now :)
>
> A block has to be called with the "call" method. I think what you want
> is:
>
> Test := Object clone do(
> init := method(
> self setIsActivatable(true)
> )
> activate := method(
> writeln(self == Lobby)
> ) setScope(thisContext)
> )
> test := Test clone
> test

Thanks Steve, it's working. I'm playing around with state driven code, and it
seems like it can be done:

Buffer := Object clone do(
full := clone

init := method(
self buffer := list()
self setIsActivatable(true)

self activate := method(
if (buffer size > 2, self setProto(full))
self
) setScope(thisContext)
)

put := method(value,
writeln("Buffer put()")
buffer append(1, 3, 3)
)

full put := method(value,
writeln("Buffer full put()")
)
)

buffer := Buffer clone
buffer put("abc")
buffer put("abc")

Mike

>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
iolanguage-digest@...
iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Re: self == Lobby in activate()?

2009-11-14T14:22:59Z

On 2009-11-14, at 10:35 AM, Mike Austin wrote:
> I changed it to use block() and I do see different behavior -
> nothing happens
> at all now :)

A block has to be called with the "call" method. I think what you want
is:

Test := Object clone do(
init := method(
self setIsActivatable(true)
)
activate := method(
writeln(self == Lobby)
) setScope(thisContext)
)
test := Test clone
test

Re: self == Lobby in activate()?

2009-11-14T10:35:21Z

Jeremy Tregunna wrote:
>
>
> This is the way method dispatch works. your test message is found in the
> Lobby, and since the Lobby can get to Object's definition of
> isActivatable and Lobby doesn't have its own, it finds it on Object, but
> since it's a method, it's dynamically scoped so self points at the
> Lobby. Change activate to a block and you'll see different behaviour.

I changed it to use block() and I do see different behavior - nothing happens
at all now :)

Test := Object clone do(
init := method(
self setIsActivatable(true)
)
activate := block(
writeln(self == Lobby)
self
)
)
test := Test clone
test

> On 2009-11-14, at 2:58 AM, Mike Austin wrote:
>
> > I'm a little confused as to why self == Lobby in a new object's
> activate() slot:
> >
> > Test := Object clone do(
> > init := method(
> > self setIsActivatable(true)
> > )
> > activate := method(
> > writeln(self == Lobby)
> > )
> > )
> > test := Test clone
> > test
> >
> > Any ideas? I'm using a recent git download, but it says Io 20090105 (??)
> >
> > Mike
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> Regards,
>
> Jeremy Tregunna
> jeremy.tregunna@... <mailto:jeremy.tregunna%40me.com>
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
iolanguage-digest@...
iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: self == Lobby in activate()?

2009-11-14T00:02:27Z

This is the way method dispatch works. your test message is found in the Lobby, and since the Lobby can get to Object's definition of isActivatable and Lobby doesn't have its own, it finds it on Object, but since it's a method, it's dynamically scoped so self points at the Lobby. Change activate to a block and you'll see different behaviour.

On 2009-11-14, at 2:58 AM, Mike Austin wrote:

> I'm a little confused as to why self == Lobby in a new object's activate() slot:
>
> Test := Object clone do(
> init := method(
> self setIsActivatable(true)
> )
> activate := method(
> writeln(self == Lobby)
> )
> )
> test := Test clone
> test
>
> Any ideas? I'm using a recent git download, but it says Io 20090105 (??)
>
> Mike
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Regards,

Jeremy Tregunna
jeremy.tregunna@...

self == Lobby in activate()?

2009-11-13T23:58:49Z

I'm a little confused as to why self == Lobby in a new object's activate() slot:

Test := Object clone do(
init := method(
self setIsActivatable(true)
)
activate := method(
writeln(self == Lobby)
)
)
test := Test clone
test

Any ideas? I'm using a recent git download, but it says Io 20090105 (??)

Mike

Re: New website design

2009-11-04T01:27:21Z

On 2009-11-03, at 11:31 PM, Justin Poliey wrote:
> The only thing I'm not a huge fan of is the mouseover effect

I've changed it to use an underline - thanks.

Re: New website design

2009-11-04T01:00:46Z

On 2009-11-03, at 10:58 PM, Rich Collins wrote:
> Maybe my eyes are starting to fail me, but fonts are a bit small
> (10px).

Good point, I've upped it to 12px.

Re: New website design

2009-11-03T23:31:55Z

I agree that the type is a little too small, the size on the original
page fit much better. I do like the new layout though. The only thing
I'm not a huge fan of is the mouseover effect, but I guess that's just
nitpicking. Good work!

On Wed, Nov 4, 2009 at 1:58 AM, Rich Collins <richcollins@...> wrote:

> Maybe my eyes are starting to fail me, but fonts are a bit small
> (10px).
>
> On Nov 3, 2009, at 5:01 PM, Andreas Schipplock wrote:
>
>> looks clean, so it's good. I like the mouseover "effect" :).
>>
>> --
>> Kind regards,
>> Andreas Schipplock.
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Re: Package/environment management

2009-11-03T23:00:44Z

I think you should group some addons into a standard library. People
using Io for the first time might be put off that they need to figure
out how to "iopackage stevedekorte/socket" to fetch a url.

On Nov 3, 2009, at 5:08 PM, Steve Dekorte wrote:

>
> On 2009-11-02, at 9:57 PM, Justin Poliey wrote:
> > http://github.com/oleganza/iopackage/
> > IoPackage is a package management system that works on Git
> > repositories, and I don't doubt it could work with other packages
> > too. It hasn't been touched since February, so I think it's going
> > stale. Maybe a totally new project is best here?
> >
> > http://github.com/jdp/boid
> > Boid is an environment management system that works like
> virtualenv (http://pypi.python.org/pypi/virtualenv
> > ). What it does is create isolated environments of Io packages,
> > making it so you can use multiple versions of a package in different
> > scenarios depending on your needs.
>
> I agree that one is needed and like the idea of it integrated with
> github. For example, you could type:
>
> iopackage johnsmith/foobar
>
> and it would grab it from:
>
> git://github.com/johnsmith/foobar
>
> compile and install it. Git versions/branches could also be supported,
> etc. If we can get the basics working, I'd be happy to move all the
> current addons into their own guthub repos.
>
> Thoughts?
>
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:iolanguage-digest@...
mailto:iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: New website design

2009-11-03T22:58:53Z

Maybe my eyes are starting to fail me, but fonts are a bit small
(10px).

On Nov 3, 2009, at 5:01 PM, Andreas Schipplock wrote:

> looks clean, so it's good. I like the mouseover "effect" :).
>
> --
> Kind regards,
> Andreas Schipplock.
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:iolanguage-digest@...
mailto:iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Package/environment management

2009-11-03T17:08:21Z

On 2009-11-02, at 9:57 PM, Justin Poliey wrote:

> http://github.com/oleganza/iopackage/
> IoPackage is a package management system that works on Git
> repositories, and I don't doubt it could work with other packages
> too. It hasn't been touched since February, so I think it's going
> stale. Maybe a totally new project is best here?
>
> http://github.com/jdp/boid
> Boid is an environment management system that works like virtualenv (http://pypi.python.org/pypi/virtualenv
> ). What it does is create isolated environments of Io packages,
> making it so you can use multiple versions of a package in different
> scenarios depending on your needs.

I agree that one is needed and like the idea of it integrated with
github. For example, you could type:

iopackage johnsmith/foobar

and it would grab it from:

git://github.com/johnsmith/foobar

compile and install it. Git versions/branches could also be supported,
etc. If we can get the basics working, I'd be happy to move all the
current addons into their own guthub repos.

Thoughts?

Re: New website design

2009-11-03T17:01:24Z

looks clean, so it's good. I like the mouseover "effect" :).

--
Kind regards,
Andreas Schipplock.

New website design

2009-11-03T16:46:31Z

The old nav was slot to traverse, so I tried to put all the links on
one page:

http://iolanguage.com/

feedback welcome

Can't get Yajl bindings to work

2009-11-03T12:30:39Z

I've outlined the whole problem here:
http://github.com/stevedekorte/io/issues#issue/7

Basically, I did a clean pull of Io, a clean pull of Yajl, then made and installed them both. When referencing Yajl in Io, Io gives an error about not being able to find libyajl.so.1. Steve then said I probably have to run ldconfig, which then results in ldconfig giving me errors about libiovmall.so. Anyone have a solution?

Thanks
Justin

Re: Package/environment management

2009-11-03T11:02:25Z

On Mon, Nov 2, 2009 at 11:50 PM, Danya Alexeyevsky <me.dendik@...> wrote:
> I'd rather support the idea of IOIMPORT (but I'd prefere it to be
> called IOPATH to be consistent with PATH, LD_LIBRARY_PATH,
> PYTHON_PATH, --ClassPath, etc). Approach with one directory with
> symlinks works well for systems administrator, but does not work if
> you have globally installed Io, you don't have root access and still
> want to add some addons.

You are mistaken; you still need IOPATH to use the symlinked approach
too. You can still have a centralized IOPKGS path and a user-specific
IOPKGS (or environment-specific, as others suggest). Link those paths
into IOPATH as appropriate.

These need not be competing systems.

--
Samuel A. Falvo II

Re: Package/environment management

2009-11-02T23:50:37Z

On Tue, Nov 3, 2009 at 9:14 AM, Samuel A. Falvo II <sam.falvo@...> wrote:
> On Mon, Nov 2, 2009 at 9:57 PM, Justin Poliey <jdp34@...> wrote:
>> What does everyone think?
>
> I haven't looked at the above, but I'm smitten with the approach
> GoboLinux manages its own packages, and it could be applied to other
> environments too.

I totally agree with Justin that Io _Needs_ a more flexible package
managment system.

I'd rather support the idea of IOIMPORT (but I'd prefere it to be
called IOPATH to be consistent with PATH, LD_LIBRARY_PATH,
PYTHON_PATH, --ClassPath, etc). Approach with one directory with
symlinks works well for systems administrator, but does not work if
you have globally installed Io, you don't have root access and still
want to add some addons.

-- Danya.

Re: Package/environment management

2009-11-02T23:44:31Z

> I haven't looked at the above, but I'm smitten with the approach
> GoboLinux manages its own packages, and it could be applied to other
> environments too.
>
> Let's imagine we define an environment variable IOPKGS, which points
> to the base path for all things Io-package related.
>
> Then, for any given Io package P, you have ${IOPKGS}/P/${P_VERSION} as
> a containing directory for the various source files and necessary
> subdirectories (e.g., in the case of GoboLinux, you see bin, etc, lib,
> usr, etc. in here).
>
> Then, each has a symbolic link ${IOPKGS}/P/current which points to
> ${IOPKGS}/P/${P_VERSION_OF_YOUR_CHOICE}
>
> In this manner, you are able to maintain as many different versions of
> P as you want.

And that works amazingly. But what if you want to have a specific
environment where a package depends on a specific older version of
another package though? You should be able to set up sandboxes for
each configuration.

I have to admit that my main concern when thinking about all this was
not necessarily packages in terms of tools and programs, but more like
pure-Io modules with the occasional binary. The current state of
making Io modules isn't very good, I feel it should be much easier.

> Next, we define a single directory containing symbolic links to all
> the installed packages' binaries.

Exactly, but instead of a multitude of symlinks to each individual
binary, how about a symlink to the path that contains all the
binaries, i.e., $IOPKGS/active/bin, where /active/ is a symlink to a
specific environment/sandbox.

> The package management system defines scripts (Io or shell, it doesn't
> really matter) which refreshes these symbolic links. This lets Io
> look in a _single_ directory for all installed packages, while
> preserving the ability to manage packages on their own terms.

I was thinking that would be $IOPKGS/active/io, with a directory
structure a little like:

Foo.io
Foo/
Subfile.io
AnotherSubfile.io
Bar.io
Bar/
Subfile.io

Allowing Foo.io and Bar.io to include those relative files with
doRelativeFile, and the importer would search for the Foo and Bar
protos in that $IOPKGS/active/io top-level.

Cheers
Justin

Re: Package/environment management

2009-11-02T22:14:43Z

On Mon, Nov 2, 2009 at 9:57 PM, Justin Poliey <jdp34@...> wrote:
> What does everyone think?

I haven't looked at the above, but I'm smitten with the approach
GoboLinux manages its own packages, and it could be applied to other
environments too.

Let's imagine we define an environment variable IOPKGS, which points
to the base path for all things Io-package related.

Then, for any given Io package P, you have ${IOPKGS}/P/${P_VERSION} as
a containing directory for the various source files and necessary
subdirectories (e.g., in the case of GoboLinux, you see bin, etc, lib,
usr, etc. in here).

Then, each has a symbolic link ${IOPKGS}/P/current which points to
${IOPKGS}/P/${P_VERSION_OF_YOUR_CHOICE}

In this manner, you are able to maintain as many different versions of
P as you want.

Next, we define a single directory containing symbolic links to all
the installed packages' binaries.

The package management system defines scripts (Io or shell, it doesn't
really matter) which refreshes these symbolic links. This lets Io
look in a _single_ directory for all installed packages, while
preserving the ability to manage packages on their own terms.

The only disadvantage to this system, as described, is its dependency
on POSIX filesystem semantics. You can work around this by, for
example, replacing that "big dump of symlinks" directory described
above with a simple text file, with each line pointing to a package
binary, etc.

Subdirectories would be supported, of course, so if you have
${IOPKGS}/P/bin/blah/foo.io, your symbolic link will point to
blah/foo.io and not just foo.io. This eases namespace management.

--
Samuel A. Falvo II

Package/environment management

2009-11-02T21:57:56Z

There needs to be a much better way to manage Io packages, at least those that are Io-based. It's still pretty annoying to go through the whole make addons/make install process for developing addons with C source, but there needs to be an easier way to manage Io packages that use pure Io.

Here are some already existing projects:

http://github.com/oleganza/iopackage/
IoPackage is a package management system that works on Git repositories, and I don't doubt it could work with other packages too. It hasn't been touched since February, so I think it's going stale. Maybe a totally new project is best here?

http://github.com/jdp/boid
Boid is an environment management system that works like virtualenv (http://pypi.python.org/pypi/virtualenv). What it does is create isolated environments of Io packages, making it so you can use multiple versions of a package in different scenarios depending on your needs.

I also had the idea that IOIMPORT environment variable should be respected by Importer, and directories in that variable will be added to the search path for Io imports. There is already a pull request waiting for that.

What does everyone think?

io

2009-11-02T10:32:21Z

JIT compilers offer slow startup - each method must be compiled before executing. Hot-spot offers quick startup - interpretation until methods are compiled. On compilers: LLVM is so quick, it is used for OpenCL.

Re: Re: Thought for the future of Io

2009-11-02T08:19:13Z

On 2009-11-02, at 11:15 AM, Friedrich Dominicus wrote:

> Another pointer which would be interesting, any tries
> undertaken to compile Io to "native" code?

This is what I'm doing with LLVM right now. Compiler emits LLVM IR,
second phase code generation takes that IR, and with the help of LLVM,
emits machine code, which can then be linked into a standalone binary,
or library.

> Regards
> Friedrich

Re: Re: Thought for the future of Io

2009-11-02T08:15:19Z

Steve Dekorte <steve@...> writes:

> On 2009-11-02, at 5:41 AM, Friedrich Dominicus wrote:
>> Have you tried it?
>
> Are you referring to LuaJIT 2, implementing Io in Lua, or implementing
> Io In Javascript?
In this case LuaJIT2, but I would be curious also how a Io/JavaScript
may look. Another pointer which would be interesting, any tries
undertaken to compile Io to "native" code?

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Re: Re: Thought for the future of Io

2009-11-02T08:04:58Z

I want ahead of time compilation. So we can implement Io in itself,
and get a resulting binary, which the interpreter can then be built
in. It's either LLVM, roll my own (not going to do that) or emit GNU
assembler source for N processors (don't want to do that either). LLVM
at least gives me a way to emit just LLVM IR, and have the LLVM tools
emit the processor specific assembly which can then be linked into
machine code ahead of time.

On 2009-11-02, at 11:02 AM, Steve Dekorte wrote:

>
> On 2009-11-02, at 6:29 AM, Jeremy Tregunna wrote:
>> I looked at lua as an implementation language even before c or c++.
>> couldn't get the llvm bindings to build. :(
>
> What's the goal that llvm is needed for? If you want small size and/or
> high speed, Lua's vm+jit seems to fit the bill.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Re: Thought for the future of Io

2009-11-02T08:02:41Z

On 2009-11-02, at 6:29 AM, Jeremy Tregunna wrote:
> I looked at lua as an implementation language even before c or c++.
> couldn't get the llvm bindings to build. :(

What's the goal that llvm is needed for? If you want small size and/or
high speed, Lua's vm+jit seems to fit the bill.

Re: Re: Thought for the future of Io

2009-11-02T06:29:02Z

I looked at lua as an implementation language even before c or c++.
couldn't get the llvm bindings to build. :(

Regards,

Jeremy Tregunna
Mobile: +1 (519) 498-8299

Sent from my iPhone

On 2009-11-02, at 7:53 AM, Steve Dekorte <steve@...> wrote:

>
> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Re: Thought for the future of Io

2009-11-02T06:19:11Z

On 2009-11-02, at 5:41 AM, Friedrich Dominicus wrote:
> Have you tried it?

Are you referring to LuaJIT 2, implementing Io in Lua, or implementing
Io In Javascript?

Re: Re: Thought for the future of Io

2009-11-02T05:41:21Z

Steve Dekorte <steve@...> writes:

> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.
Have you tried it?

Regards
Friedrich

Re: Re: Thought for the future of Io

2009-11-02T05:39:33Z

Currently only x86 CPUs are supported. x64 support is in the works.
Other architectures will follow with sufficient demand and/or
sponsoring.

http://luajit.org/faq.html

On Mon, 2009-02-11 at 04:53 -0800, Steve Dekorte wrote:
> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.

--
--gh

Re: Re: Thought for the future of Io

2009-11-02T04:53:57Z

Looking to alternative implementations of Io, at ~1/3 the speed of C,
LuaJIT is looking pretty good:

http://lua-users.org/lists/lua-l/2009-10/msg01098.html

A Lua implementation of Io would remove the complexity of having to
implement a garbage collector and would allow us to use Lua's more
extensive set of bindings. It might also pave the way toward a
Javascript implementation at some point.

Re: Digest Number 1840

2009-11-01T22:47:38Z

Steve Dekorte <steve@...> writes:

> On 1 Nov 2009, at 12:40 am, Friedrich Dominicus wrote:
>>> ... I've seen at least one article, which says that Obj-C is what C++
>>> should have been.
>> That's absolutly something I would subscribe immediatly.
>
> Me too. I actually would have implemented Io in Objective-C if
> Objective-C was cross platform. (Btw, I know about the gnu Objective-
> C but it really isn't compatible with Apple's and I doubt it ever
> will be.)
Yes I'm afraid that's the case. But gnus objective C seems to work quite
similiar on every platform. But (this probably has to be written BUT),
the IDE support outside the Mac OS X is "near" non-existant. Please
don't tell me ProjectManager is the "answer".

>
>> Agreed Io has it's own kind of problems but it's really one of the
>> most
>> beatiful languages out there. I wish I had known it 11 years ago,
>> while
>> we were working on our own language. If we had known Io we surely
>> could
>> have tried to make it "compilable", and it would have been nice. I'm
>> sure.
>
> Thanks! What is that language you were working on?

It was named Q
http://www.q-software-solutions.de/q/index.shtml

It was thought as a follow-up to Eiffel with streng separation of
commands and queries. The queries should have been pure functional.
To that time I thought OO is the best invention since sliced bread and
that Eiffel is the "right" thing. To my shame I have to conclude, I'd
better had been fluent in Smalltalk, Common Lisp. Yes I've looked into
many languages but I ignored the "dynamically" typed ones. That wasn't
very clever. But that's not the most unclever point. My idea was that
people would be willing to buy software on Linux also. Oh boy, how could
one be so mistaken...

Regards
Friedrich