(This question assumes that the unary `*’ (used in arrays and such) is
called “splat”. If not, please translate this into something which makes
sense.)
I was wondering if there’s a reason we couldn’t splat an array into itself.
There’s no way currently to do it (no syntax for it), but would it be
impossible to do? I was thinking something like this would produce an
infinite array of ones:
a = [1, *a] # Doesn’t work because `a’ isn’t defined.
or this:
a = [1]
a << *a # Parse error.
or this:
a = [1]
a[1] = *a
a # --> [1, 1] (Of course.)
Would this be impossible because when a splat is encountered, the objects
are injected into the other array at that moment? (It seems like Ruby could
just wait on that.)
It’s just one of those things from functional programming that I don’t see
how to do in Ruby.
It tries to describe/predict how a programming language is going to be
like in a hundred years. I found it quite entertaining to read (and not
just because it references Ruby ).
V.-
(This question assumes that the unary `*’ (used in arrays and such) is
called “splat”. If not, please translate this into something which makes
sense.)
I was wondering if there’s a reason we couldn’t splat an array into itself.
There’s no way currently to do it (no syntax for it), but would it be
impossible to do? I was thinking something like this would produce an
infinite array of ones:
a = [1, *a] # Doesn’t work because `a’ isn’t defined.
or this:
a = [1]
a << *a # Parse error.
or this:
a = [1]
a[1] = *a
a # → [1, 1] (Of course.)
Would this be impossible because when a splat is encountered, the objects
are injected into the other array at that moment? (It seems like Ruby could
just wait on that.)
···
On Sat, Apr 12, 2003 at 02:41:14AM +0900, Chris Pine wrote:
It’s just one of those things from functional programming that I don’t see
how to do in Ruby.
This sounds like lazy evaluation, the kind of stuff you can find around
implemented with continuations.
It’s just one of those things from functional programming that I don’t see
how to do in Ruby.
This sounds like lazy evaluation, the kind of stuff you can find around
implemented with continuations.
Well, it might sound that way, but it really isn’t.
Lazy evaluation is much more involved and deep; I was only talking about a
difference in implementation.
For example, when I give Ruby the following:
bar = [2, 3, 4]
foo = [0, 1, *bar]
it could internally store that array just like it looks: as an array of
three elements, but also distinguishing between pointers-to-elements and
pointers-to-splats.
Of course, `foo.length’ should be still be 5; all of the implementation
would be under the hood and invisible to the programmer.
For all I know (I rarely look at the interpreter code), Ruby might do this
already! We wouldn’t be able to tell. The only real difference that I see
is that this underlying implementation would allow for infinite arrays. inspect' would be a little tricky, and loops would need to be detected (but inspect’ already does this, so it wouldn’t be too big of a leap).
Well, now that I think about it, perhaps it wouldn’t be of much use without
lazy evaluation. I could still get the array_of_ones[500] with the above
implementation, but I wouldn’t be able to write a function to pairwise add
infinite arrays, for example, and get an array_of_twos.
Would continuations really allow this sort of thing? I don’t see how you
would use continuations to give you lazy evaluation or infinite arrays.
As a workaround you can always nest arrays, infinitely so if you wish. I
think your first example was
a = [1, *a]
Well, you can’t do that, but you can write:
a = [1]
a << a
in which case you get an infinite recursive structure, except it’s
[1, [1, [1, .... ]]]
instead of
[1, 1, 1, .....]
Not only inspect but other parts of ruby handle this properly, e.g.
irb(main):010:0> a.flatten!
ArgumentError: tried to flatten recursive array
from (irb):10:in `flatten!’
And I guess:
bar = [2, 3, 4]
foo = [0, 1, bar]
p foo.flatten
is sort of like the example you gave above. In fact, perhaps you could
define class Splat < Array
which would let you do
foo = [0, 1, Splat.new(bar)]
and modify Array#each so that it iterates over (flattens) the elements of a
Splat automatically…
Regards,
Brian.
···
On Sat, Apr 12, 2003 at 05:39:05AM +0900, Chris Pine wrote:
This sounds like lazy evaluation, the kind of stuff you can find around
implemented with continuations.
Well, it might sound that way, but it really isn’t.
Lazy evaluation is much more involved and deep; I was only talking about a
difference in implementation.
For example, when I give Ruby the following:
bar = [2, 3, 4]
foo = [0, 1, *bar]
it could internally store that array just like it looks: as an array of
three elements, but also distinguishing between pointers-to-elements and
pointers-to-splats.
You can even do:
a = [1]
a << a
p a # => [1, […]]
p a[1] # => [1, […]]
p a[1][1] # => [1, […]]
p a[1][1][1] # => [1, […]]
a.flatten
# => ArgumentError: tried to flatten recursive array
Such recursion could be detected if a.id == a[i].id or the location
of a.index(a).
-austin
– Austin Ziegler, austin@halostatue.ca on 2003.04.11 at 17:59:28
···
On Sat, 12 Apr 2003 05:39:05 +0900, Chris Pine wrote:
This sounds like lazy evaluation, the kind of stuff you can find around
implemented with continuations.
Well, it might sound that way, but it really isn’t.
Lazy evaluation is much more involved and deep; I was only talking about a
difference in implementation.
[…]
Well, now that I think about it, perhaps it wouldn’t be of much use without
lazy evaluation. I could still get the array_of_ones[500] with the above
implementation, but I wouldn’t be able to write a function to pairwise add
infinite arrays, for example, and get an array_of_twos.
Would continuations really allow this sort of thing? I don’t see how you
would use continuations to give you lazy evaluation or infinite arrays.
Generators provide some kind of restricted lazy evaluation (an arguably,
infinite arrays).
I don’t think there will be any languages at all.
Instead you have a AI-agent which you can instruct by speaking
plain english to it and it will then do all the required
programming (you can relax):
you could ask the AI-agent to build your favorite program for you
build ruby-version2 with bytecode support.
write some good documentation.
mmm… maybe I could sell this idea ?
···
On Sun, 13 Apr 2003 20:35:40 +0200, Stefan Scholl wrote:
On 2003-04-11 20:36:32, Damphyr wrote:
The Hundred-Year Language
It tries to describe/predict how a programming language is going to be
like in a hundred years.
Some time ago I read ‘Auf zwei Planeten’ (‘On two planets’ probably
known as ‘Two planets’, the title of the 1971 US edition) by Kurd
Lasswitz, a Science-Fiction story originally published in 1897. It
clearly shows the limitations of extrapolations of technical
development, leave alone scientific breakthroughs - the book contains
violations (not circumventions) of Einstein’s theories of relativity.
To put it that way: We have no idea of what computers will look in a
hundred years from now. We do not even know what principles they will
be based upon. They may be
optical and use nonlinear effects
quantum-mechanical and use probability effects
biological and will be able to make mistakes and have a mind of
their own
will be something like syntrons (*)
not exist (because mankind ceased to exist or decided not to use
computers any more)
will be based on something we don’t imagine today
One should keep in mind that the principle that allow for modern
computers are not very old.
Konrad Zuses first computer was 100% mechanical. He then switched to
relays (electro-mechanics) and afterwards to tubes (electronics). The
reason why he did switch has always been the same: The principle used
did limit the power provided by the computer. A computer based on
tubes did impose many limitations on its usability. As long as
computers were based on tubes that did inevitabely mean that there
had to be a large computing center. Computers for everybody simply
were unthinkable. Then came the invention of the transistor. A
completely new techonology did start. Even the very first transistor
built in laboratory was of a size that is hard to reach by tubes.
Nowadays we are beginning to reach the limits of that technology but
who can imagine what will be in 100 years?
(*) A syntron is a fictional computing device that does occur in the
Perry Rhodan Science-Fiction series. Facing the limits of computing
technology the authors did come up with the idea that the major
limitations of todays computers are Planck’s quantum and the speed of
light that are fundamental constants of our universe. They therefore
did put the computer into an universe of it’s own - with different
fundamental constant. Who can say if we will not be able to do that
in reality? We nowadays do things that people a hundred years ago
would have supposed to be wonders (and others that they would have
called attacks but now are called ‘preventive actions’).
Besides technical limitations programming languages also depend on
our intellctual approach to problems. Nowadays we think in terms of
limited things and their properties. That is only one approach.
Another one would be seeing the world as an entity and describing how
that entity evolves.
That is not as artificial as it may seem. Such a change of approach
did take place in physics. Quantum mechanics brought us a picture of
the world that has little in common with the old mechanical approach.
The Hundred-Year Language
It tries to describe/predict how a programming language is going to be
like in a hundred years.
Who would have guessed it? It will be Lisp.
I don’t think there will be any languages at all.
Instead you have a AI-agent which you can instruct by speaking
plain english to it and it will then do all the required
···
On Mon, Apr 14, 2003 at 06:15:15AM +0900, Simon Strandgaard wrote:
On Sun, 13 Apr 2003 20:35:40 +0200, Stefan Scholl wrote:
On 2003-04-11 20:36:32, Damphyr wrote:
=============
AHA! Do you really think we will speak plain English in 100 years???
If anything, I’ll be doing Japanese by that time.
programming (you can relax):
you could ask the AI-agent to build your favorite program for you
build ruby-version2 with bytecode support.
Hopefully Rite will be out before 2100 }
write some good documentation.
This won’t be needed as we will be able to read matz’s doc directly in
Japanese
).
