[ICR-1 to 34] Some Io Change Requests

[Brian Mitchell]

Hi everyone,

I've compiled a list over time of things about Io I would like to see
change, features I would like and so on. Bellow are a few of them.
These are really informal and kind of messy but they are better than
nothing. I should put this on the wiki but I am short on time right
now. I will start numbering at 1 so we can refer to them in shorthand
in future times, so please carefully number yours if you do submit any
ICRs.

I have not had time to proof read the following so keep it in mind:

ICR-1 Nil renamed to nil

I propose that Nil should be renamed to nil. This makes it clear that
is should be treated as a value. There has been much talk on IRC about
this already so I won't repeat it.

ICR-2 support richer method names

I propose that we allow ? as a last character in a method name.

I think this leads to more clarity of your intent. isNil would become
nil? for example. Comparing the two it is _very_ clear that nil? is a
question being asked. This would probably lead to more clarity in code
and make conditional statements more readable.

Optional extension to this would also allow ! at the end but the
semantics of this aren't as clear.

ICR-3 set function return self

I propose we unify all set functions (i.e. setFooBar and setQux) to
either return self or to return nil.

This will make behavior more predictable and build some stronger
idioms for Io. self is currently used in most places so it would be
painless to choose that as the return. nil would also work if we
decide that set chaining is a bad practice.

Alternatives would include returning the value set.

ICR-4 IO type hierarchy

I propose we clean up the I/O objects into clearer objects and prototypes.

Currently we are overloading things like File to also control standard
in/out/err. It also makes it hard to check that a type can do I/O but
not specifically what kind. Sockets, Files, Streams, Test Mocks could
all share IO as a basic prototype. This might simplify some of the
interfaces also: File slotNames sort give this:

Io> File slotNames sort
==> asBuffer, asSeq, asString, at, atPut, close, docs, exists, flush,
foreach, groupId, isAtEnd, isDirectory, isLink, isPipe, isRegularFile,
isSocket, isUserExecutable, lastAccessDate, lastDataChangeDate,
lastInfoChangeDate, mode, moveTo, name, open, openForAppending,
openForReading, openForUpdating, path, popen, position,
protectionMode, readBufferOfLength, readLine, readLines,
readStringOfLength, readToBufferLength, remove, rewind, setPath,
setPosition, size, standardError, standardInput, standardOutput, stat,
temporaryFile, truncateToSize, userId, with, write

Notice the large number of isXYZ methods. These could be removed and
made into something like this:

mySocketObject hasProto(Socket)

This will also allow us to add in new I/O features easily in the
future without putting too much burden on File. The hierarchy could be
composed of IO with Buffer and Stream as subs. Then Socket could sub
Stream (no seeking), and File could sub Buffer (seek offered for
example).

ICR-5 do with no arguments

I propose we allow do to take no arguments.

When I code I sometimes throw a bare bones skeleton up. Using stuff like:

Foo := Object clone do(
)

waiting to be filled in. At other times I might want to comment out
something. Commenting out do and having my code templates force me to
type do an unholy number of times has bugged me. Why not change do to
be more friendly and allow zero arguments?

This would be more sugar but I don't see what it is harming.

ICR-6 repeatTimes rename to times

I would like repeatTimes to be renamed to times. I think the current
name is long an isn't elegant for short and clear looping code:

5 repeatTimes( "foo" println )
5 times( "foo" println )

One reads out loud as "Five repeat times, print a line with foo". The
other is similar but more clear: "Five times, print a line with foo".

This is for usability and readability. It not only sounds better but
is much shorter to type. Loops and iterators or things that should
stay light so they don't grow beyond a safe threshold. Small names and
easy translational semantics ensures that the programmer will not be
as easily confused.

ICR-7 repeatTimes with counter

I propose we add an optional count argument to repeatTimes.

When we have a loop it is nice to have a counter in the loop. We
commonly use the for loop to accomplish such things. The for loop is
an ugly artifact (see ICR-8) that make many things unclear.

5 repeatTimes(x, x println)
0
1
2
3
4

This seems to a be a natural behavior.

ICR-8 Remove for loop

I propose we remove the for loop from the language or at least deprecate it.

This one is controversial to some but I will try to lay the case
clearly. The for loop is currently used for different types of
iteration. Two of the types include iteration of a collection and
repetition of a task.

Repetition of a task can easily be handled using constructs like
times, upto, downto, while, until, and so on. These are very powerful
expression but they also are very clear. They each say exactly what
their purpose is while a for loop needs deeper inspection to come to
the same conclusion. There are no for-loop-patterns I know of that are
hard or ugly using alternative mechanisms.

Iteration of collections is another point. I will hit this one very
closely with my other ICRs so I won't give too many examples except to
say that for is a really crummy way to iterate over elements.

In closing I would like to say that for is an archaic structure from
old languages that should be ready to die by now. There is no
requirement that we keep the for loop so why do we? }:-)

ICR-9 foreach renamed to each with some small changes.

I propose that we add internal iterators to all of our collection
objects using each which is very similar to foreach and remove
foreach.

We have a large number of collection types and these are bound to grow
rapidly over time. As we start to use these we will find that we need
to iterate over the elements in the collection with flexible style. If
we added each to our collections we would accomplish a large portion
of what we would need to layer new functionality like mapping and
filtering (or even list comprehension). Right now we have foreach (bad
name) on List which does something _very_ similar though it adds in
the index as a number. I would propose we use the name each and remove
the index unless there are enough arguments to support it when called.
The index would either be an integer count or a key for a key value
pair. Other structures might also make use of this. This is basically
like foreach but a little smarter.

Internal iterators are fine for most activity (I could use some made
up 90% ratio here) but they are sometimes not enough. Sometimes
external iterators are needed. One example is iterating multiple
collections in parallel. In these cases most languages decide to
support external iterators as the basic requirement and build internal
iterators out of them. Io is not like this because we have coroutines
which can handle conversion of an internal iterator to an external
one. Writing an internal iterator is usually easier than writing an
external one so why not make someone else to the work. :) I will cover
this point in another ICR.

ICR-10 Iterator type and iterator returns

I propose that any iterators without parameters instead return a new
Iterator object.

This object would be passable and could be used in the capacity of an
external iterator. It would provide an activation method that would
resume iteration only after it is passed arguments.

twoTimes := 2 times
twoTimes(x, x print)
01
twoTimes("OOH" print)
OOHOOH

someOtherThing := list(42, 24, 42) each
someOtherThing(x, x print)
422442

e := someOtherThing external
while(e hasNext?, e value print; e next)
422442

These are examples of the iterators and how one could convert to an
external iterator. This gives us extreme power for building high order
functions and more customized loops (read again: we don't need for
loops).

ICR-11 hasProto and kindOf

I propose we add kindOf to Object.

Right now hasProto checks not only the ancestors but the current
object. The name is misleading because self is not in the protos list.
Why not have hasProto just check the protos list and kindOf check self
and call hasProto (or check itself if you want). This just makes it a
little more clear of what is included for the check.

ICR-12 upTo and downTo

I propose we add upTo and downTo as basic loop structures.

These are useful things when you need to go over a specific range of integers:

3 upTo(5,x, x print)
345
3 upTo(3, x, x print)
3
3 upTo(2, x, x print)
3 downTo(4, x, x print)
3 downTo(1, x, x print)
321
3 downTo(3, x, x print)
3

These examples give a good idea of how these would work. It is just a
little more expressive than times.

Optional and alternative: define to which would detect direction of
the range. I would like to see all tree (upto, downto, and to)
included.

Optional: The names could be made all low caps because of length.
(also see my Camel to Underscore ICR).

ICR-13 until

I propose we add until to the language as a new loop structure.

As I've said before, clear loops are important. while( cond isNil,
...) is not as nice as until( cond, ....). This is just a step towards
clarity in flow control.

ICR-14 unless

I propose we add unless to the language as a new conditional.

if( cond isNil, ...) is not as clear as unless( cond, ...). I would
like to see this added so we can avoid ugly conditions.

ICR-15 Booleans

I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.

Right now we have nil overloaded to represent too many things. Like
Lisp this can become ambiguous over time and does not aid in clarity
of intent. Sometimes we also need a non nil return value that
represents something that would be true. An example of this would be
the isNil message. isNil return Lobby which has nothing to do with the
call, it just happens to be something that is treated as true. If find
this messy and poor design. False and true would only help to clear up
comparisons. Seeing Nil returned right now doesn't help as much as
seeing false as you now know more about the source of the value.

Alternative: Only add true. Nil can continue to work as both emptiness
and false.

ICR-16 Expression return values

I propose that all expressions return their lastly evaluated part.

This is already done for the most part. I just want to make it a
standard practice. Things like each and times would return the last
iterations value. This is useful when doing conditionals that rely on
many values and an early break or a positive return will help you
decide on how to manage the condition.

ICR-17 Slot lifetimes and nil

I propose that slots are nil by default and are removed when set to nil.

Right now we have quite a few slot operations: newSlot, removeSlot,
setSlot, getSlot, and updateSlot. We could consolidate and remove the
need to newSlot and removeSlot.

setSlot("a", 1)
setSlot("b", 2)
slotNames sort
a, b

setSlot("a", nil)
slotNames sort
b

ICR-18 Not in booleans

I propose we add not for boolean expressions.

We currently have and and or but no not. This would complete the
symmetry and give us something nicer than isNil (or nil?). Not would
also be appropriate for boolean expressions if we add true and false.
Again the intent is more clear with not.

not foo or bar // very clean short circuit evaluation. familiar to
other languages

ICR-19 Comparable

I propose we add a Comparable proto that would act like a mixin.

Objects that can be compaired with >, <, >=, <=, ==, and between?. If
we add this to collections that support the comparison operator (<=>)
we could accomplish this for generic code. Very simple addition of
sorting and other operations that come for free once we implement <=>.
<=> (a.k.a the spaceship operator), would return zero on equality, 1
when given an argument that is larger than self, and -1 when given an
argument smaller than itself.

l := list(1,2,3,0)
l max print
3
l sort print
0, 1, 2, 3

This mainly serves to aid code reuse and custom user collections and
minimize then number of methods that need to be written each time (one
for many).

ICR-20 Enumerable

I propose we add a Enumerable proto that would act like a mixin.

Enumerable would supply generic methods for things like size, any?,
all?, collect, find, find_all, include?, inject, min, max, sort, zip,
etc... all by providing just the each method on a collection and for a
few, the <=> method.

Again this is for code reuse and rapid building of new collection types.

ICR-21 ===

I propose we add === (a.k.a. the similar to operator).

This operator would be nice when we want to know if something is
similar to another thing. In this case it would be just like hasProto
but with checks on == first.

This is just a convenient operator for case expressions and the like
(see some of my other ICRs). == is a pain to use in these cases if you
want to mach either a value or a type of object.

ICR-22 !=

I propose we add != as a synonym to not(left) ==(right). The compiler
would translate it like it does to := and =.

It is a nice feature that shortens some code. If you don't add unless
and until I would consider these with high priority. It also server a
purpose in custom control structures and iterators.

l := 1 upTo(10) each asList
l filter(x, (x % 2) != 0) print
13579

ICR-23 case expression

I propose we have a case expression that uses the === operator in
selection. It would execute only one block (no fall through) and have
one default case called else.

case(expr,
when 1
...
when 2, 3
...
when IO, FooBarObject
...
when 4, QuxObject, "abc", list(1,2,3)
...
else
...
)

This would make some conditions nicer. It is modeled after ruby if you
need a reference on rules. Note the syntax has open commas. This would
require my ", like cons" ICR.

Alternative syntax:

case(expr
) when(1,
...
) when(2, 3,
...
) when(IO, FooBarObject,
...
) when(4, QuxObject, "abc", list(1,2,3),
...
) else(
...
)

I we don't have this I will probably add it myself anyway. I just
think it is nice enough for the core.

ICR-24 "," cons

I propose we make , and official operator that takes only one argument
with one target (no recursion and in C).

, is like a list cons operator (i.e. like : in Haskell) but for
argument lists more specifically. If we add this to object then we can
construct the arguments list (see ICR-25 and ICR-26 for more info on
the list and my opinions). This would also allow us to do currying or
argument lists :). I think this would be one of the most powerful
features in Io removing the need for really complicated macros to
support nice custom operator syntaxes. I would put this ICR in high
priority.

ICR-25 Argument object type

I propose we make arguments to a function be a special clone of list
that allows for more interactivity.

This would allow us to implement "," on the Argument object to cons
correctly and it would also allow for things like, easy check for
keyword arguments, and other argument introspection methods.

Alternative: Include Arguments as a proto to the instance of a list.

ICR-26 Argument delegation and splat

I propose we have an easier way to delegate all or parts of our argument lists.

When I want to be able to do something like this:

m1 := method(...)
m2 := method(foo, bar, qux, # qux is a list
m1(qux splat) # call with the list splat into place for each argument
)

m2(1,2, list(3,4)) calls m1(3,4) instead of m1(list(3,4)) because of
splat on a list.

ICR-27 thisMessage interface cleanup

I propose some renaming of the thisMessage interface.

Rename thisMessage to this. It is talking about the message or
execution at that point in time so it makes sense (it will confuse C++
guys but who cares, this is not bound by what others do). It will
provide much nice access. Right now meta-programming code is hard to
read because of the long phrases like thisMessage.

this args. a quick way to access arguments. arguments it just too much to type.

That is about it for now. It is just too hard to make a nice var-arg
method right now and heavy looking at that.

ICR-28 better argument handling

I propose that we change how we handle arguments to methods and block,

Right now if I want to have a method that takes a few explicit
arguments and a few optional arguments I have to use the thisMessage
object for all of it. Also, if I want lazy arguments and explicit
declaration I still have to use thisMessage. thisMessage makes sense
but right now it does not support these scenarios very well. I hope to
see this change with the help of a few annotations in a method:

m1 := method(
arg a, b
lazy c
rest d
code(
...
)
)

m1(1,2,foo,4,bar,6)

in the scope of code(..) a = 1, b = 2, c = message(foo), rest =
message(4), message(bar), message(6)

Something to this style where the method gives some locals that are
methods to do the heavy lifting. The result is a method that is
constructed once rather than multiple times, that also has nice
argument semantics. This has some nice potential for optimizations.

I would love to see something like this but better ideas about going
about it would be welcome.

ICR-29 block to function or lambda

I propose we rename block to something less confusing.

I think this would free our capability to discuss code as blocks would
be a generic term for things like methods and lambdas. We could even
leave Block as a generic type that is build off of with method(...)
and lambda(...) as convenience expressions. Io has the capability to
support things like dynamic scoping so leaving the door open would
probably be a good idea. lambda is more traditional but people with
less FP background will not be familiar with it. function or func
could serve as alternative names if lambda is not chosen.

ICR-30 activation

I propose that there be an easy and immediate way of activating
objects, including anonymous blocks.

Right now we can't activate a block without naming it or making a
special constructor (AFAIK). I would like to restore the ability to do
explicit activation on a block:

block(x, x print)(1)
1

I think this ability is useful as the block can actually be used to
get internal information like thisMessage (it is a nice feature for
meta-programming). I don't see how this makes handling the object any
harder. This is not the same as quag's lambda in the wiki PasteBin.

ICR-31 symbols

I propose we have a standard way to address common objects without
causing evaluation (and subsequent activation). Symbols provide this:

b := block( ... )
// Try to pass the block:
foo(getSlot("b")) # messy :(

--- new style ---
b := block( ... )
foo('b)

This would compile into:

b := block( ... )
foo(symbol("b")) # symbol would create the new object

Once the argument is sent to a doMessage then it is evaluated as a
real message. This is very similar to Lisp macros (in fact it is
inspired from them). It gives us the power of lazy arguments in more
than just a method call. I highly recommend this for inclusion.

We could also extend this and allow things like:

getSlot('b) # as a shorhand

ICR-32 macros

I propose we add macro(...) for real support for automated transforms.

This method would make a lot of simple transformations really easy. It
would work like the following:

m := macro(x, x*x) # really simple example

foo := method(x, m(x+1))

There are two main options from this point on: have method
automatically expand macros or leave it to be lazy expansion done only
once on the first invocation. The latter is the easiest and would
involve simple self replacement. This is just a simple way we can have
some nice syntactic shortcuts in our programs. There are probably more
uses. I will probably elaborate why this is really nice to have when I
have more time.

ICR-33 expand

I propose that we add expand() to Io. It would expand macros with an
option argument for the number of levels to expand.

This is a nice congruency with macro(). If we have one we should have the other.

ICR-33 inspect

I propose that objects implements inspect when they want custom
introspective output and that Object have a default inspect method and
that the interactive REPLs use this for object display.

This would free us from asString output that might be more appropriate
for other cases. It also is tailored to a specific use: the developer.
These strings would need to be compact (minimal number of new lines),
and show a large amount of object information. Example of what I came
up with a little while ago:

Object clone do( a := Object clone do( type := "Foo"), b := self, c :=
2, d := list(1,2,3)) inspect

#<Object:0x1107020 a=#<Foo:0x1109130>, b=#<Object:0x1107020 ...>, c=2,
d=[1,2,3]>

This output is short and is "relatively" readable. It could be made
more readable but at the cost of space (some objects would be too
large and more annoying to print). As you notices the type tags would
be used and things like lists and numbers would have their own
implementation of inspect.

ICR-34 Camel vs. Underscore

I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

This is another one that will probably live on to be quite
controversial. Very controversial. In fact I really am worried that
this will be dismissed because people are just too used to one style
or another. I will try to make the case clear for why we would be
better off with both.

I grew up on camel case. For years I thought it was the superior way
to go. using _ just seemed to space things out longer then they needed
to be. That changed a few years ago as i started to learn ruby and the
ideas behind their code style. First of all is reading:

HowEasyCanYouReadThis
vs.
how_easy_can_you_read_this

The extra chars in length are a small price to pay for the advance in
that. I don't want to hear arguments against this one as I bet I could
give a double blind experiment that would show which one we can read
easier. The idea is to give separation. The way our minds detects
patterns means it is more likely to pick it up without looking at each
character then the camel cased one. This raises our speed and accuracy
when looking at the code. I will hold an experiment on this if any of
you want to detest the claims made. If you think one is easier than
the other, you should give it some time.

Another point is the fact that we differentiate between Protos and messages:

myMessage
Message

Very little visual for the difference between an name and a Proto
object. The line is fuzzy for what one sees. If we had code like:

MyObject := Object clone do(
each := method(...)
count_external_entries := method(...)
ExternalEntry := Object clone do(...)
)

It is clear what each slot is for. Either a method, a simple value or
an embedded Object that can be used as a prototype. It makes it easy
for other people to see code and go aha because of the large naming
style gap (rather than one letter only).

Another reason: I vote for it ;). j/k. I think we should seriously
consider it for real reasons. Nice code is very important to me. It is
one reason I don't use Perl.

---->8----

Ok. That does it for one day. I have even more (yes. many more) but
these are the ones that came to mind first.

Please have give me any real feedback you have on these. I will post
them to a wiki sometime soon unless someone beats me to it. I can also
elaborate on the topics more if needed.

Thanks for listening,
Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Mike Austin]

I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.

I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.

foo := method (a, b) (
a * b
)

while (n < 0) (
writeln(n = n + 1)
)

And for can be converted to a range, a more collection oriented syntax:

range(1, 20) each(n) (
writeln(n)
)

I'm not very fond of "times" as in "5 times(...))" because a number should not
now how to iterate, it's just a number. I think Smalltalk tries to cram to
much functionality into objects sometimes.

Mike



------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

Post by Mike Austin
I'm not very fond of "times" as in "5 times(...))" because a number should not
now how to iterate, it's just a number. I think Smalltalk tries to cram to
much functionality into objects sometimes.

Actually I think some objects should know there successive values.
letters, numbers and so on. I think this is a good thing.

5 succ print
6
6 prev print
5

Thanks for the reply. I will be posting some more over then next few days.

Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Bob Ippolito]

Post by Brian Mitchell

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I
won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

I really like that syntax... it's a lot more familiar and likely
easier to get right without all those strangely placed commas.

-bob

[Brian Mitchell]

Post by Bob Ippolito

Post by Brian Mitchell

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

I really like that syntax... it's a lot more familiar and likely
easier to get right without all those strangely placed commas.
-bob

I guess we could teach the parser that sequential ()'s are to be
joined as if they were currying the arguments.

Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[John Nowak]

Post by Brian Mitchell
I guess we could teach the parser that sequential ()'s are to be
joined as if they were currying the arguments.

Eh.. foo(a, b, c, d) == foo(a, b)(c)(d)? I donno. It would confuse
mathematical expressions I'd suggest.

Since you have to put a string in quotes anyway and you can't have
spaces in slot names, surely the commas are unnecessary? For blocks
of code, you'd just use another set of parens. In the example below,
it shows how you can do an else if without any then() or else()
business, and without hard to spot commas:

if((x == 1) (
foo(a)
bar(b)
) (
foo(b)
bar(a)
))

I mean... I like it. I'm sure I'm the only one though.

- John

[Mike Austin]

Post by Brian Mitchell

Post by Bob Ippolito

Post by Brian Mitchell

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

I really like that syntax... it's a lot more familiar and likely
easier to get right without all those strangely placed commas.
-bob

I guess we could teach the parser that sequential ()'s are to be
joined as if they were currying the arguments.

setSlot("", method (...))

Mike

[Brian Mitchell]

Post by Mike Austin

Post by Brian Mitchell

Post by Bob Ippolito

Post by Brian Mitchell

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

I really like that syntax... it's a lot more familiar and likely
easier to get right without all those strangely placed commas.
-bob

I guess we could teach the parser that sequential ()'s are to be
joined as if they were currying the arguments.

setSlot("", method (...))
Mike

Oh yes. I've forgotten. Quag has used that trick a few times.

Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Donovan Preston]

Post by Bob Ippolito

Post by Brian Mitchell

Post by Mike Austin
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)

The syntax is ok. I just am wondering how easy it would be to modify
and hook into. Also how fast we could actually migrate to that.

I really like that syntax... it's a lot more familiar and likely
easier to get right without all those strangely placed commas.

The one thing I would suggest is using words to separate the parens,
like "then" does for if:

foo := method(a, b) does (
a * b
)

while (n < 0) do (
writeln(n = n + 1)
)

Not sure what to suggest for the range each example, though.

dp



------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Quag]

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.
foo := method (a, b) (
a * b
)
while (n < 0) (
writeln(n = n + 1)
)
range(1, 20) each(n) (
writeln(n)
)
I'm not very fond of "times" as in "5 times(...))" because a number should not
now how to iterate, it's just a number. I think Smalltalk tries to cram to
much functionality into objects sometimes.

At one point I had a modified version of my code formatter
(http://pipapo.org/iowiki/PasteBin/formatCode) that spat out code in
this style. If anyone is interested I could try to dig it up again.

Jonathan.

[John Nowak]

Post by Mike Austin
I agree with a lot of your comments, and disagree on some. I won't get into
them now, but I'd like to mention a few things about the syntax.
I like the newer style if () then (), and I think it should be
incorporated
into while() foreach(), and even method(). Having the body be one of the
arguments looks funny to me - it feels like I'm coding in Excel macros.

(while (< n 0)
(writeln (set! n (n + 1))))

Ta!

The only problem I have with how Io puts the "body" in as an argument
is something like this:

if(cond,
a
b
c
)

if(cond,
a
b,
c
)

That second command which denotes "else" is just damn hard to notice
sometimes in big blocks of code.

- John




------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Christian Thaeter]

Post by Brian Mitchell
ICR-2 support richer method names
I propose that we allow ? as a last character in a method name.
I think this leads to more clarity of your intent. isNil would become
nil? for example. Comparing the two it is _very_ clear that nil? is a
question being asked. This would probably lead to more clarity in code
and make conditional statements more readable.
Optional extension to this would also allow ! at the end but the
semantics of this aren't as clear.

where is a richer macro system so that we can have text-only verbose
names (helpful when serializing Io code to some text format) and macros
which do the translations from standard/extended syntax to core syntax?
After all I like the idea above, but it should be optional.

Post by Brian Mitchell
ICR-3 set function return self
I propose we unify all set functions (i.e. setFooBar and setQux) to
either return self or to return nil.

ack, self! again macros setFooBar --> setSlot("FooBar",.. ?

apropo: The Felix Language has the semantics that 'Procedures' (return
no value) may have side-effects, Functions (returning some value) must
be side-effect free, (functions and procedures might be mixed of course,
see felix.sf.net). I might add another class of Callables "Predicates"
which return only true or false an have no side effects. Thinking about
this is very amazing could we map this somehow onto Io? :)

Post by Brian Mitchell
ICR-4 IO type hierarchy
I propose we clean up the I/O objects into clearer objects and prototypes.
Currently we are overloading things like File to also control standard
in/out/err. It also makes it hard to check that a type can do I/O but
not specifically what kind. Sockets, Files, Streams, Test Mocks could
all share IO as a basic prototype. This might simplify some of the

Long time ago I proprosed a 'freeze' scheme with a prototype in Io:
http://www.pipapo.org/pipawiki/Io/Freeze (Should be implemented within
the VM for real or?). This gives a nice barrier against unintended abuse
of prototypes/objects.

Post by Brian Mitchell
ICR-5 do with no arguments
I propose we allow do to take no arguments.
Foo := Object clone do(
)

Foo := Object clone do(
unimplemented
)

//where unimplemented is defined somewhat like
Lobby unimplemented = block(
Exception raise("unimplemented","Object not yet implemented")
)

Post by Brian Mitchell
ICR-8 Remove for loop
I propose we remove the for loop from the language or at least deprecate it.

I am waiting for proper tail-recursion / last-call-optimization
handling. With that (and maybe macros) we can reimplement all imperative
control constructs in a functional manner. Since users can then
implement their own kinds of control constructs, Io can have very basic
ones within the core and extended ones as loadable module.

Post by Brian Mitchell
ICR-12 upTo and downTo
ICR-13 until
ICR-14 unless

See ICR-8 .. tail recursion.

Post by Brian Mitchell
ICR-15 Booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.

ack, consider the 'Predicates' idea from above.

maybe a isTrue function (err 'true?') which does the usual conversions
from primitive types (0, 0.0, "", are false; anything else is true)

Post by Brian Mitchell
ICR-18 Not in booleans
I propose we add not for boolean expressions.

... Predicate logic :)

Post by Brian Mitchell
not foo or bar // very clean short circuit evaluation. familiar to
other languages

I dont like that, i would like sorted/ordered logic more explicit .. mhm
ok i am Prolog fan .. Io won't benefit from differences here :(

Post by Brian Mitchell
ICR-19 Comparable
ICR-20 Enumerable

nice

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).
This operator would be nice when we want to know if something is
similar to another thing. In this case it would be just like hasProto
but with checks on == first.
This is just a convenient operator for case expressions and the like
(see some of my other ICRs). == is a pain to use in these cases if you
want to mach either a value or a type of object.

How to define 'similarity'? Imo, this is bad for generic programming
since other programmers might have different opinions on similarity
yielding vague defined interfaces. === looks like a very strict form of
equality to me, if you really want it make it =|=,=~=,~=~ or such

Post by Brian Mitchell
ICR-22 !=
I propose we add != as a synonym to not(left) ==(right). The compiler
would translate it like it does to := and =.

No exceptions please ... x != y -> x !=(y)
setSlot("!=",predicate(y,(self == y) not))

Post by Brian Mitchell
ICR-23 case expression
I propose we have a case expression that uses the === operator in
selection. It would execute only one block (no fall through) and have
one default case called else.

case is a history artifact in C to supply jump-tables

I would rather like some matching facility:

match(expr,
=(1) -> ...
=(1) | =(2) -> ...
regex(".*foo.*") -> ...
)

Don't take that syntax serious, just an fast idea, not worked out.

.. Mhhm doesn't that look a bit like apply(func, ((expr,func),...))

Post by Brian Mitchell
) else(

back to Predicates ... 'else' is a method on Bool

Bool else = method(call, if(self value == false, call))

... but 'call' is lazy evaluated ...

Post by Brian Mitchell
ICR-28 better argument handling
I propose that we change how we handle arguments to methods and block,
Right now if I want to have a method that takes a few explicit
arguments and a few optional arguments I have to use the thisMessage
object for all of it. Also, if I want lazy arguments and explicit
declaration I still have to use thisMessage. thisMessage makes sense
but right now it does not support these scenarios very well. I hope to

gotcha here is lazy :) .. how about matching here too? In Io's case this
should be fairly optional but enforced if present, so one is free to add
robustness to a dynamic language.

Some ideas I had for a not yet existent language (semantic, not syntax)

Method := Object clone freeze

ArgList := List clone

ArgList of := //check some constraints

ArgList as := //filter/convert parts of a Arglist


ArgList getArg := method(
Object of type(Method),
Name of (type(Symbol) and Object hasNotSlot(Name)), //assertion
Handler_Constraint of function,
code := (
ifelse(Handler_Constraint == nil,
Object setSlot(Name, self popHead)
,
Object setSlot(Name, Handler_Constraint)
)
)
)

ArgList freeze

m1 := method( // m1 := Method clone
a, // getArg(args,m1,a,nil)
b of type(Bool), // getArg(args,m1,b,of type(Bool))
c of function, // lambda/lazy
e as List, // convert the (remains of) ArgList to a List
code := ( // code is a setSlot operation?
...
)
)

Note: this is quite sketching here and not very detailed, i hope you
understand the ideas and ignore the errors I made :)

Post by Brian Mitchell
ICR-29 block to function or lambda
I propose we rename block to something less confusing.

function()
predicate()
procedure()
method()

Post by Brian Mitchell
ICR-34 Camel vs. Underscore
I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

sounds sane.

consider http://www.pipapo.org/pipawiki/Io/ReservedNames too.

Post by Brian Mitchell
---->8----
Ok. That does it for one day. I have even more (yes. many more) but
these are the ones that came to mind first.

ugh ... good night now, sorry that I only made some hasty response, I
don't have much time these days.

I like most of your ideas and almost dislike none. Good Work!

Many of those proposals should become a requirement for Io 1.0 when
accepted. I would like to say that the Io people need to adopt/setup
some sane infrastructure where one can really work with. I do my best to
provide the bzr repo and set up a crude bug tracker on my iowiki
unfortunally there is no much response so far on those action which is a
but unmotivating. These things should be fixed with priority imo.

Christian Thäter

[Donovan Preston]

Post by Brian Mitchell

Post by Brian Mitchell
ICR-5 do with no arguments
I propose we allow do to take no arguments.
When I code I sometimes throw a bare bones skeleton up. Using
Foo := Object clone do(
)

Foo := Object clone do(
unimplemented
)
//where unimplemented is defined somewhat like
Lobby unimplemented = block(
Exception raise("unimplemented","Object not yet implemented")
)

I just put Nil inside the do block. I wouldn't mind allowing empty
blocks to do, though.

Foo := Object clone do (
Nil
)

"do nothing"

dp

[Brian Mitchell]

Post by Christian Thaeter

Post by Brian Mitchell
ICR-2 support richer method names
I propose that we allow ? as a last character in a method name.
I think this leads to more clarity of your intent. isNil would become
nil? for example. Comparing the two it is _very_ clear that nil? is a
question being asked. This would probably lead to more clarity in code
and make conditional statements more readable.
Optional extension to this would also allow ! at the end but the
semantics of this aren't as clear.

where is a richer macro system so that we can have text-only verbose
names (helpful when serializing Io code to some text format) and macros
which do the translations from standard/extended syntax to core syntax?
After all I like the idea above, but it should be optional.

I see that as a naive feature. It is like python's __add__ which
doesn't really mean add everywhere, just most places. It could be like
foo! == foo_bang but we don't gain much from that. (If I understand
what you said).

Post by Christian Thaeter

Post by Brian Mitchell
ICR-3 set function return self
I propose we unify all set functions (i.e. setFooBar and setQux) to
either return self or to return nil.

ack, self! again macros setFooBar --> setSlot("FooBar",.. ?
apropo: The Felix Language has the semantics that 'Procedures' (return
no value) may have side-effects, Functions (returning some value) must
be side-effect free, (functions and procedures might be mixed of course,
see felix.sf.net). I might add another class of Callables "Predicates"
which return only true or false an have no side effects. Thinking about
this is very amazing could we map this somehow onto Io? :)

I am not sure it fits directly into the core way of doing things but I
am an advocate of multi-paradigm languages. I think it would probably
be enough to allow experimentation with this.

On another note, I have put a lot of thought into reforming setters
and getters but haven't hit anything solid yet. I might post about it
in a day or two.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-4 IO type hierarchy
I propose we clean up the I/O objects into clearer objects and prototypes.
Currently we are overloading things like File to also control standard
in/out/err. It also makes it hard to check that a type can do I/O but
not specifically what kind. Sockets, Files, Streams, Test Mocks could
all share IO as a basic prototype. This might simplify some of the

http://www.pipapo.org/pipawiki/Io/Freeze (Should be implemented within
the VM for real or?). This gives a nice barrier against unintended abuse
of prototypes/objects.

Not in my opinion. I do think there are cases where a reference should
fail to copy. CFunction is a good example of this. Many depend on
object local data that is stored internally. Copying a reference to
one of these should fail, for both sanity and security reasons. Maybe
we could have some layers like that. I will be posting about this and
some other slot stuff later.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-5 do with no arguments
I propose we allow do to take no arguments.
Foo := Object clone do(
)

Foo := Object clone do(
unimplemented
)
//where unimplemented is defined somewhat like
Lobby unimplemented = block(
Exception raise("unimplemented","Object not yet implemented")
)

I might as well just put Nil or something in there. It is for
easy/fast editing. Otherwise I would put raise right in the body (more
to come on exceptions too :) ).

Post by Christian Thaeter

Post by Brian Mitchell
ICR-8 Remove for loop
I propose we remove the for loop from the language or at least deprecate it.

I am waiting for proper tail-recursion / last-call-optimization
handling. With that (and maybe macros) we can reimplement all imperative
control constructs in a functional manner. Since users can then
implement their own kinds of control constructs, Io can have very basic
ones within the core and extended ones as loadable module.

You hit on one I was saving for my next round of possible features,
automatic and transparent tail recursion. I think recursion is nice,
but it should be known that coroutines are still more powerful that
recursion especially for flow control constructs.

I would like to ask for continuations but I know some would vote
against that. I am not going to force this one.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-12 upTo and downTo
ICR-13 until
ICR-14 unless

See ICR-8 .. tail recursion.

:) these are easy with tail recursion as an implementation BUT they
are much nicer abstracted out before hand. In fact, they probably
would be used enough to warrant it as a built-in feature of Io. We
need something basic that works out of the box (i.e. not as minimalist
as scheme).

Post by Christian Thaeter

Post by Brian Mitchell
ICR-15 Booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.

ack, consider the 'Predicates' idea from above.
maybe a isTrue function (err 'true?') which does the usual conversions
from primitive types (0, 0.0, "", are false; anything else is true)

Lisp had that sort of concept in a number of systems and all of the
material I've read has said it leads to confusion and ambiguation.
what should 1 == 1 return? true. It has nothing to do with 1 or
something like Lobby. same goes for false. It is a *descriptive*
system I am sick of languages that don't know how to describe things
precisely with out reinvention of the wheel. This is the idea behind
times, upto, downto, unless, and untill.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-18 Not in booleans
I propose we add not for boolean expressions.

... Predicate logic :)

predicate logic is still something I don't think fits directly into
Io. It is a powerful thing but it still is to complex for a simple
language. I think it starts to require too many new paradigms while
basic booleans could be easily ignored or even wired in for a more
complex system.

Post by Christian Thaeter

Post by Brian Mitchell
not foo or bar // very clean short circuit evaluation. familiar to
other languages

I dont like that, i would like sorted/ordered logic more explicit .. mhm
ok i am Prolog fan .. Io won't benefit from differences here :(

Short-circuit evaluation is nice for strict languages and can make
some code much shorter.

(I am not against seeing prolog implement inside of Io ;) just not as
Io please).

Post by Christian Thaeter

Post by Brian Mitchell
ICR-19 Comparable
ICR-20 Enumerable

nice

Just stealing from Ruby here. :)

Post by Christian Thaeter

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).
This operator would be nice when we want to know if something is
similar to another thing. In this case it would be just like hasProto
but with checks on == first.
This is just a convenient operator for case expressions and the like
(see some of my other ICRs). == is a pain to use in these cases if you
want to mach either a value or a type of object.

How to define 'similarity'? Imo, this is bad for generic programming
since other programmers might have different opinions on similarity
yielding vague defined interfaces. === looks like a very strict form of
equality to me, if you really want it make it =|=,=~=,~=~ or such

I guess. I find it nice for pattern matching in things like case
expression. It allows for a different grain of matching while == is
too absolute in many cases.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-22 !=
I propose we add != as a synonym to not(left) ==(right). The compiler
would translate it like it does to := and =.

No exceptions please ... x != y -> x !=(y)
setSlot("!=",predicate(y,(self == y) not))

The idea is that you could implement == and get != for free.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-23 case expression
I propose we have a case expression that uses the === operator in
selection. It would execute only one block (no fall through) and have
one default case called else.

case is a history artifact in C to supply jump-tables
match(expr,
=(1) -> ...
=(1) | =(2) -> ...
regex(".*foo.*") -> ...
)
Don't take that syntax serious, just an fast idea, not worked out.
.. Mhhm doesn't that look a bit like apply(func, ((expr,func),...))

maybe case should be select or match but the construct is still useful
IMHO. If and unless only go so far. I also think you are bringing in
to much syntax again. That is the type of thing to be added by the
developer not the language in this case (IMO).

Post by Christian Thaeter

Post by Brian Mitchell
) else(

back to Predicates ... 'else' is a method on Bool
Bool else = method(call, if(self value == false, call))
... but 'call' is lazy evaluated ...

Interesting. I am still not sold on it. :)

Post by Christian Thaeter

Post by Brian Mitchell
ICR-28 better argument handling
I propose that we change how we handle arguments to methods and block,
Right now if I want to have a method that takes a few explicit
arguments and a few optional arguments I have to use the thisMessage
object for all of it. Also, if I want lazy arguments and explicit
declaration I still have to use thisMessage. thisMessage makes sense
but right now it does not support these scenarios very well. I hope to

gotcha here is lazy :) .. how about matching here too? In Io's case this
should be fairly optional but enforced if present, so one is free to add
robustness to a dynamic language.
Some ideas I had for a not yet existent language (semantic, not syntax)
Method := Object clone freeze
ArgList := List clone
ArgList of := //check some constraints
ArgList as := //filter/convert parts of a Arglist
ArgList getArg := method(
Object of type(Method),
Name of (type(Symbol) and Object hasNotSlot(Name)), //assertion
Handler_Constraint of function,
code := (
ifelse(Handler_Constraint == nil,
Object setSlot(Name, self popHead)
,
Object setSlot(Name, Handler_Constraint)
)
)
)
ArgList freeze
m1 := method( // m1 := Method clone
a, // getArg(args,m1,a,nil)
b of type(Bool), // getArg(args,m1,b,of type(Bool))
c of function, // lambda/lazy
e as List, // convert the (remains of) ArgList to a List
code := ( // code is a setSlot operation?
...
)
)
Note: this is quite sketching here and not very detailed, i hope you
understand the ideas and ignore the errors I made :)

I think matching is a good thing but I am against method overloading
in most cases for Io (just doesn't seem to fit). Maybe you could give
more reason behind this approach to win me over.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-29 block to function or lambda
I propose we rename block to something less confusing.

function()
predicate()
procedure()
method()

method is used. function doesn't give much of a hint. lambda is odd
enough that you look it up once, learn it, and then use it without
confusion. procedure is probably way off the mark.

Post by Christian Thaeter

Post by Brian Mitchell
ICR-34 Camel vs. Underscore
I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

sounds sane.
consider http://www.pipapo.org/pipawiki/Io/ReservedNames too.

I don't think that link works for me. I decided to post about the
naming style as it is my last chance to cause change before 1.0. I
will still be happy with Io but the names will always feel like a
misfeature to me otherwise :)

I would never have these enforced though. Just guidelines for code.

Post by Christian Thaeter

Post by Brian Mitchell
---->8----
Ok. That does it for one day. I have even more (yes. many more) but
these are the ones that came to mind first.

ugh ... good night now, sorry that I only made some hasty response, I
don't have much time these days.
I like most of your ideas and almost dislike none. Good Work!

I am sure I will be posting some stuff that you will disagree with in
the coming days. I've got 100+ ICRs right now with little time to
write them all.

Post by Christian Thaeter
Many of those proposals should become a requirement for Io 1.0 when
accepted. I would like to say that the Io people need to adopt/setup
some sane infrastructure where one can really work with. I do my best to
provide the bzr repo and set up a crude bug tracker on my iowiki
unfortunally there is no much response so far on those action which is a
but unmotivating. These things should be fixed with priority imo.

I look forward to using the repo but I've just had a huge cramp on my
time with work.

I hope I didn't sound too negative with your ideas. I think they would
be viable if it could be broken down to very elementary components.
Maybe you could provide a library that would be officially bundled?

I do have more as I've already said. I hope to move through them but I
will be posting on the wiki [1] and giving summary notice on this
list. That way I can track status progress and give updates.

Also, I will be around on freenode IRC as binary42 in the #io channel.
Anyone should feel free to drop in around normal waking hours for the
MDT time zone to discuss anything with more realtime constraints.

Thanks,
Brian.

[Erik Max Francis]

Post by Brian Mitchell
ICR-1 Nil renamed to nil

What is the real value in this? Nil is a proto, whether or not you want
to treat it like one.

Post by Brian Mitchell
ICR-3 set function return self

What methods are you thinking of that don't currently follow this
convention?

Post by Brian Mitchell
Notice the large number of isXYZ methods. These could be removed and
mySocketObject hasProto(Socket)

Most if the is... methods do not simply check the proto, so I don't
think this makes sense for its own sake.

Post by Brian Mitchell
ICR-6 repeatTimes rename to times
I would like repeatTimes to be renamed to times. I think the current
5 repeatTimes( "foo" println )
5 times( "foo" println )

It looks the same to me. repeatTimes at least has the virtue of
including a verb, making it clear what is happening. Shortening clear
names is not a good thing; shorter names don't simplify code, they
complicate it.

Post by Brian Mitchell
ICR-8 Remove for loop

This is silly. There are plenty of times that you want to iterate over
a sequence of counting numbers. That the idiom perhaps looks different
in different languages doesn't mean that it makes Io's for loop "archaic."

Post by Brian Mitchell
ICR-12 upTo and downTo

Uh, how's this different from having a for? Except that for is actually
readable and easily recognizable to anyone.

Post by Brian Mitchell
ICR-15 Booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.
Right now we have nil overloaded to represent too many things.

This doesn't make sense. Nil is the only false value in Io. Everything
else is true. There's no "overloading" going on here. I wouldn't
object to introducing an explicit truth value, but if you're
hard-pressed for a true value, self will always suffice. Or Object, if
you're really desperate.

This suggestion implies to me that the suggestor doesn't quite
understand how true and false work in Io.

Post by Brian Mitchell
ICR-22 !=
I propose we add != as a synonym to not(left) ==(right). The compiler
would translate it like it does to := and =.

This seems to betray some additional confusion. There already is a !=
slot in Object that is properly overridden by protos when relevant.
Under what circumstances does it not work?

not(left) ==(right) would be (not left) != right, which clearly is not
correct here, anyway.

Post by Brian Mitchell
ICR-34 Camel vs. Underscore
I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

This is pure style and tedious. If Steve preferred underscore syntax to
camel case, don't you think he would have done it that way to start with?

Without going through every single proposal point by point, the vast
majority of these seem to be purely stylistic issues, and since they're
already done another way, I see no reason to change them. If those were
Steve (and others') stylistic preferences, they would have already been
done that way.
--
Erik Max Francis && ***@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
My heart is pure as the driven slush.
-- Tallulah Bankhead



------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Erik Max Francis

Post by Brian Mitchell
ICR-1 Nil renamed to nil

What is the real value in this? Nil is a proto, whether or not you want
to treat it like one.

right. BUT it is still used more like a value that a proto. It makes
no sense to capitalize it either.

Post by Erik Max Francis

Post by Brian Mitchell
ICR-3 set function return self

What methods are you thinking of that don't currently follow this
convention?

setSlot is the only one that come to mind right now. I would like it
to be adopted as a nice rule. This doesn't involve many changes.

Post by Erik Max Francis

Post by Brian Mitchell
Notice the large number of isXYZ methods. These could be removed and
mySocketObject hasProto(Socket)

Most if the is... methods do not simply check the proto, so I don't
think this makes sense for its own sake.

I think you are confused by my proposal.

Post by Erik Max Francis

Post by Brian Mitchell
ICR-6 repeatTimes rename to times
I would like repeatTimes to be renamed to times. I think the current
5 repeatTimes( "foo" println )
5 times( "foo" println )

It looks the same to me. repeatTimes at least has the virtue of
including a verb, making it clear what is happening. Shortening clear
names is not a good thing; shorter names don't simplify code, they
complicate it.

I strongly disagree with that. Good code uses some sort of huffman
coding technique. Things that are used often become shorter. Things
used less often are longer. If anything it should be timesRepeat for
proper use. I don't use repeatTimes much because it is a pain to type
out and very hairy in the code (it takes up otherwise readable space).
times would help this.

Post by Erik Max Francis

Post by Brian Mitchell
ICR-8 Remove for loop

This is silly. There are plenty of times that you want to iterate over
a sequence of counting numbers. That the idiom perhaps looks different
in different languages doesn't mean that it makes Io's for loop "archaic."

I think you haven't used any real loops yet then. I am serious about
not having needed or used a for loop in well over a year in anything
except C and Java (because they lack powerful expression).

When you want to count numbers why not make it more apparent using
some sort of range expression? I think this is a very weak positive
argument for the for loop.

Really. Give me some code that you think is a good case for a for loop
and I bet I can improve it. It is like an ugly runt and it was
invented for old languages with crummy high level capabilities (thus I
called it archaic).

Post by Erik Max Francis

Post by Brian Mitchell
ICR-12 upTo and downTo

Uh, how's this different from having a for? Except that for is actually
readable and easily recognizable to anyone.

Not really different. It shows how one can have specific code that you
can write. Other pick up. Read. Understand. It is really why for loops
are a *bad thing*. They don't encode an ounce of intent.

Post by Erik Max Francis

Post by Brian Mitchell
ICR-15 Booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.
Right now we have nil overloaded to represent too many things.

This doesn't make sense. Nil is the only false value in Io. Everything
else is true. There's no "overloading" going on here. I wouldn't
object to introducing an explicit truth value, but if you're
hard-pressed for a true value, self will always suffice. Or Object, if
you're really desperate.

Nil is the "false" value but Nil is also used as an empty value. I
call that overloading: "multiple uses of Nil". I am suggesting a very
*simple* addition to make some things result in non-relevant values.
Lobby still has nothing to to with isNil.

Post by Erik Max Francis
This suggestion implies to me that the suggestor doesn't quite
understand how true and false work in Io.

I understand them well. In fact, probably more than you ;) Ok. Now we
are even. :)

On a lighter side I would suggest you read this:
http://cs-www.cs.yale.edu/homes/dvm/nil.html

Post by Erik Max Francis

Post by Brian Mitchell
ICR-22 !=
I propose we add != as a synonym to not(left) ==(right). The compiler
would translate it like it does to := and =.

This seems to betray some additional confusion. There already is a !=
slot in Object that is properly overridden by protos when relevant.
Under what circumstances does it not work?
not(left) ==(right) would be (not left) != right, which clearly is not
correct here, anyway.

Oh. I've got an error here :)

not (left == right). sorry about that one. I am just saying that it
should be expanded with not in this case. Sorry again.

Post by Erik Max Francis

Post by Brian Mitchell
ICR-34 Camel vs. Underscore
I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

This is pure style and tedious. If Steve preferred underscore syntax to
camel case, don't you think he would have done it that way to start with?

Don't you think I would have used underscore style to start with? No.
I didn't really know or understand it for a while. Now I do. There is
a dimension in this world called time. Events do not fall into a
singularity in that dimension.

Post by Erik Max Francis
Without going through every single proposal point by point, the vast
majority of these seem to be purely stylistic issues, and since they're
already done another way, I see no reason to change them. If those were
Steve (and others') stylistic preferences, they would have already been
done that way.

I will grant it is very stylistic but it that not an important factor?
I always hear people criticize Perl's line-noise... I think it is
something to be discussed not thrown away. The way I look at it is:

Is there any reason to use X. Is there any reason to use Y. Then
compare the lists. I find this approach is important at this point
because Io is in a state where change is not a hard thing so an
argument about "change" is kind of short sighted. Anyway, if you would
like to disagree please do so. Otherwise I don't see your point. I
will only repeat that I think consistence and quality of style is an
important thing. I don't want to have to remember if library X uses
camel or underscore styles (it saves brain power as Akira Tanaka was
saying in his RubyConf05 presentation).

Brain power... hmm. now that is something to conserve for the right things.

[Deep breath]

Ok. Now that I've replied, please know that is you think I am totally
backwards you can create an alternate by putting together an ICR or
come join me on IRC for a chat. :)

Brian.

[Erik Max Francis]

Post by Brian Mitchell

Post by Erik Max Francis

Post by Brian Mitchell
ICR-1 Nil renamed to nil

What is the real value in this? Nil is a proto, whether or not you want
to treat it like one.

right. BUT it is still used more like a value that a proto. It makes
no sense to capitalize it either.

You'd have to make clear what you mean here. Everything in Io is a
proto, a slot somewhere, and a "value" (whatever that means). That
doesn't explain why Nil should be spelled in lowercase.

The only analogous things in Io which are lowercase like that are list
and vector, but those are factories, not at all like Nil.

Post by Brian Mitchell
I think you are confused by my proposal.

Many of the slots in the output that you pasted that start with is... do
not involve checking protos.

Post by Brian Mitchell
I strongly disagree with that. Good code uses some sort of huffman
coding technique. Things that are used often become shorter. Things
used less often are longer.

While there may even be such a tendency, that does not mean in a
language like Io, which I think has both conciseness and clarity going
for it, that giving things shorter names is a useful goal in and of itself.

Post by Brian Mitchell
If anything it should be timesRepeat for
proper use. I don't use repeatTimes much because it is a pain to type
out and very hairy in the code (it takes up otherwise readable space).
times would help this.

It's a pain to type repeatTimes, but not timesRepeat? Seeing

count repeatTimes(...)

is "hairier" than

count times(...)

? That doesn't make any sense at all to me. This is a really silly
style issue, particularly when you think switching the order of the
words is fine. Most of the slot names that cause actions in Io start
with a verb, so repeatTimes is the right way to go. Just because it
_could_ be shorter doesn't mean it _could_ be. Clarity is the goal, not
brevity.

Post by Brian Mitchell
I think you haven't used any real loops yet then. I am serious about
not having needed or used a for loop in well over a year in anything
except C and Java (because they lack powerful expression).

I haven't used any real loops. Uh, okay, whatever floats your boat.

The fact is, it's a common idiom. Iterating over counting numbers is
something that's done in every language, whether it requires an explicit
(counting) for loop. Iterating over range/xrange in Python is not at
all uncommon.

Post by Brian Mitchell
When you want to count numbers why not make it more apparent using
some sort of range expression? I think this is a very weak positive
argument for the for loop.

Sometimes you actually need to count over numbers. How else would you
compute Fibonacci numbers, for instance?

Post by Brian Mitchell
Really. Give me some code that you think is a good case for a for loop
and I bet I can improve it. It is like an ugly runt and it was
invented for old languages with crummy high level capabilities (thus I
called it archaic).

...

Post by Brian Mitchell
Not really different. It shows how one can have specific code that you
can write. Other pick up. Read. Understand. It is really why for loops
are a *bad thing*. They don't encode an ounce of intent.

This seems totally silly to me. You say for loops are archaic, that
they can always be better written with other forms, and then suggest
upTo/downTo as means of achieving _that exact same end_. If all you
mean is that there were _other, more obscure_ ways you could write for
loops, I wouldn't hesitate to agree with you. But that doesn't mean
that it's a good idea.

for(i, 1, 10, i println)

is going to be an instantly recognizeable control structure to anyone
remotely familiar with programming ("archaic" or not).

1 upTo(10, i println)

is going to look awfully strange. Again, this is a pure style
suggestion, but you can't get in style changes through the back way by
suggesting that they're something else.

Post by Brian Mitchell
Nil is the "false" value but Nil is also used as an empty value. I
call that overloading: "multiple uses of Nil". I am suggesting a very
*simple* addition to make some things result in non-relevant values.
Lobby still has nothing to to with isNil.

This is what nil means is languages which have the concept of "nil" as
the sole false sentinel. This isn't overloading, it's fundamentally
what a nil means. Nil is a special object, and is the only object that
qualifies as false. All other objects qualify as true. Therefore you
can use any value in a true context, and Nil (and only Nil) in a false
context. That also necessarily means that Nil can be used in the
absence of any other (useful) object, since it's explicitly set aside as
a sentinel. This isn't overloading, it's one and the same.

The addition of a False sentinel completely destroys the meaning of Nil.

Post by Brian Mitchell
http://cs-www.cs.yale.edu/homes/dvm/nil.html

That applies to Common Lisp. Nil is not the empty list in Io (and nil
is not necessarily the empty list in other Lisp languages like Scheme).
"Don't care" values are rare in Io, because people like to chain
messages, and the common thing to use there is to return self, so that
case doesn't apply either. Finally, Io doesn't have the concept of
symbols as contrasted to strings as Common Lisp does, so that's another
one of those points that doesn't apply. The fourth and final point,
that Nil is means false, is the only one that applies, and is obviously
true. So a Common Lisp analysis doesn't apply at all to Io.
Congratulations on being able to use Google to look up articles on nil,
though.

Besides, "X Considered Harmful" articles are a dime a dozen these days.
Even if it completely applied, that doesn't mean everyone agrees with
it. That the person who wrote the article wishes things were
differently doesn't mean that his complaints are valid or that others
agree with him.

Post by Brian Mitchell
Oh. I've got an error here :)
not (left == right). sorry about that one. I am just saying that it
should be expanded with not in this case. Sorry again.

Did you see the part about != already being a slot in Object that works
just fine?

Post by Brian Mitchell
I will grant it is very stylistic but it that not an important factor?
I always hear people criticize Perl's line-noise... I think it is

No. Style is one of the least important factors. Consistency is the
most important, and Io already has almost all of that even without any
explicit style enforced from without.

Post by Brian Mitchell
Ok. Now that I've replied, please know that is you think I am totally
backwards you can create an alternate by putting together an ICR or
come join me on IRC for a chat. :)

I've already said why I thought most of your ideas weren't good. I
don't see the need to create an "ICR" (which you apparently just made
up, but nothing wrong with that) to defend an existing style against
stylstic changes that, I suspect, have little chances of actually being
adopted.
--
Erik Max Francis && ***@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
The basis of optimism is sheer terror.
-- Oscar Wilde



------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Erik Max Francis

Post by Brian Mitchell
I think you are confused by my proposal.

Many of the slots in the output that you pasted that start with is... do
not involve checking protos.

The checking or protos is something that would replace things like
isSocket, isPipe, and so on. Things like isLink and isDirectory are
not really benefited by an IO object hierarchy. I thought my example
was clear about this, maybe not. I will be posting more details on
this one, including specifics about the hierarchy.

Post by Erik Max Francis

Post by Brian Mitchell
I strongly disagree with that. Good code uses some sort of huffman
coding technique. Things that are used often become shorter. Things
used less often are longer.

While there may even be such a tendency, that does not mean in a
language like Io, which I think has both conciseness and clarity going
for it, that giving things shorter names is a useful goal in and of itself.

It think that things we want to encourage regular use of should have
extra help in accessibility. This might include shorter names in many
cases. If we want to encourage idioms where we make heavy use of block
passing for example, we would want to look at my symbols ICR. "times"
feels short to me but still perfectly understandable.

Post by Erik Max Francis

Post by Brian Mitchell
If anything it should be timesRepeat for
proper use. I don't use repeatTimes much because it is a pain to type
out and very hairy in the code (it takes up otherwise readable space).
times would help this.

It's a pain to type repeatTimes, but not timesRepeat? Seeing

It is still a pain but I am addressing the confusing order of verb and
noun in this case.

Post by Erik Max Francis
count repeatTimes(...)
is "hairier" than
count times(...)
? That doesn't make any sense at all to me. This is a really silly
style issue, particularly when you think switching the order of the
words is fine. Most of the slot names that cause actions in Io start
with a verb, so repeatTimes is the right way to go. Just because it
_could_ be shorter doesn't mean it _could_ be. Clarity is the goal, not
brevity.

I think it makes more sense when attached to real code. I sometimes
want to use a result of a loop like that so I might have an attached
message that makes perfect sense to have on one line but won't be
because I've all of the sudden have a long name that takes me longer
to read. I call this hairier because it just adds more. It feels like
having to put type declarations on things that don't need them
(example would be in another language) or not having do() in Io.

Foo := Object clone
Foo a := method(..)
Foo b := method(..)
Foo c := method(..)

I do feel the result of that. Maybe I am not the fast reader and the
amazing typist you might be. The idea is that I shouldn't be penalized
for using something like that just because someone didn't mind the
length. I do mind.

Post by Erik Max Francis

Post by Brian Mitchell
I think you haven't used any real loops yet then. I am serious about
not having needed or used a for loop in well over a year in anything
except C and Java (because they lack powerful expression).

I haven't used any real loops. Uh, okay, whatever floats your boat.
The fact is, it's a common idiom. Iterating over counting numbers is
something that's done in every language, whether it requires an explicit
(counting) for loop. Iterating over range/xrange in Python is not at
all uncommon.

Then how come I can get along fine w/o it? I don't see how this is
needed above any other feature. Ranges are a viable replacement for
the for loop. I would like to see someone submit an ICR on that.

Post by Erik Max Francis

Post by Brian Mitchell
When you want to count numbers why not make it more apparent using
some sort of range expression? I think this is a very weak positive
argument for the for loop.

Sometimes you actually need to count over numbers. How else would you
compute Fibonacci numbers, for instance?

1) tail recursion
2) generators using a collection with memoization
3) many many more. There are probably hundreds of ways to compute Fibs.

I really don't see how using a for loop helps or make a cleaner and
clearer implementation of Fibonacci.

If you want to iterate over Fibonacci numbers then you probably should
consider that we can easily build a generator and use each in internal
iteration style.

Post by Erik Max Francis

Post by Brian Mitchell
Really. Give me some code that you think is a good case for a for loop
and I bet I can improve it. It is like an ugly runt and it was
invented for old languages with crummy high level capabilities (thus I
called it archaic).

...

I know I sound very irrational from your point of view but I would
like to show you my point of view better if I could. I really do not
see what can't be done in the absence of the for loop yet.

Post by Erik Max Francis

Post by Brian Mitchell
Not really different. It shows how one can have specific code that you
can write. Other pick up. Read. Understand. It is really why for loops
are a *bad thing*. They don't encode an ounce of intent.

This seems totally silly to me. You say for loops are archaic, that
they can always be better written with other forms, and then suggest
upTo/downTo as means of achieving _that exact same end_. If all you
mean is that there were _other, more obscure_ ways you could write for
loops, I wouldn't hesitate to agree with you. But that doesn't mean
that it's a good idea.
for(i, 1, 10, i println)
is going to be an instantly recognizeable control structure to anyone
remotely familiar with programming ("archaic" or not).
1 upTo(10, i println)
is going to look awfully strange. Again, this is a pure style
suggestion, but you can't get in style changes through the back way by
suggesting that they're something else.

The point here is we are building up descriptive language. We are now
moving our problem to a point where we can take our description and
build up to it rather than down to things like for. I would like to
see something that is more like declaring its intent that using a for
loop. Again, if you don't like this maybe generator and range
iteration would work for you.

Post by Erik Max Francis

Post by Brian Mitchell
Nil is the "false" value but Nil is also used as an empty value. I
call that overloading: "multiple uses of Nil". I am suggesting a very
*simple* addition to make some things result in non-relevant values.
Lobby still has nothing to to with isNil.

This is what nil means is languages which have the concept of "nil" as
the sole false sentinel. This isn't overloading, it's fundamentally
what a nil means. Nil is a special object, and is the only object that
qualifies as false. All other objects qualify as true. Therefore you
can use any value in a true context, and Nil (and only Nil) in a false
context. That also necessarily means that Nil can be used in the
absence of any other (useful) object, since it's explicitly set aside as
a sentinel. This isn't overloading, it's one and the same.
The addition of a False sentinel completely destroys the meaning of Nil.

I don't think that is completely right. if nil really means that then
why don't we rename that to false? Now you might see what I mean.

Post by Erik Max Francis

Post by Brian Mitchell
http://cs-www.cs.yale.edu/homes/dvm/nil.html

That applies to Common Lisp.

CL has just about every feature so it is usually a relevant place to
turn to for an example.

Post by Erik Max Francis
Nil is not the empty list in Io (and nil
is not necessarily the empty list in other Lisp languages like Scheme).
"Don't care" values are rare in Io, because people like to chain
messages, and the common thing to use there is to return self, so that
case doesn't apply either.

Rare? I thought Io was supposed to be flexible. Now I can't use nil
and I need to invent another type. Booleans seemed a nice place to
invent than here.

Post by Erik Max Francis
Finally, Io doesn't have the concept of
symbols as contrasted to strings as Common Lisp does, so that's another
one of those points that doesn't apply.

It does have messages. In fact a nextMessage could be Nil for example.
If this displaying a value of false? I don't think so.

Post by Erik Max Francis
The fourth and final point,
that Nil is means false, is the only one that applies, and is obviously
true.

I don't know if it does. We have too many places that it doesn't mean
anything boolean.

Post by Erik Max Francis
So a Common Lisp analysis doesn't apply at all to Io.

I think it could apply even if I couldn't refute your points. Io is
wide open for customization. CL features aren't out of order.

Post by Erik Max Francis
Congratulations on being able to use Google to look up articles on nil,
though.

:) I find google a great tool but for reference I got that from a blog
at anarchaia.org that I read regularly.

Post by Erik Max Francis
Besides, "X Considered Harmful" articles are a dime a dozen these days.

So true. I would agree on this but points should be made if only to
start the process of thinking.

Post by Erik Max Francis
Even if it completely applied, that doesn't mean everyone agrees with
it.

I hold you to that right. I just want to keep mine, so please don't be
offended when I try to defend it.

Post by Erik Max Francis
That the person who wrote the article wishes things were
differently doesn't mean that his complaints are valid or that others
agree with him.

Right. CL is an interesting world where implementations regularly
offer optional features to remedy things like this.

Post by Erik Max Francis

Post by Brian Mitchell
Oh. I've got an error here :)
not (left == right). sorry about that one. I am just saying that it
should be expanded with not in this case. Sorry again.

Did you see the part about != already being a slot in Object that works
just fine?

Yes. I note that my version has slightly different runtime semantics.
One is a method (Object '!=), the other is more like syntax sugar or a
macro (my ICR).

Post by Erik Max Francis

Post by Brian Mitchell
I will grant it is very stylistic but it that not an important factor?
I always hear people criticize Perl's line-noise... I think it is

No. Style is one of the least important factors. Consistency is the
most important, and Io already has almost all of that even without any
explicit style enforced from without.

I wouldn't ever enforce style. That spoils a language. I would heavily
suggest a style and make sure the core language is consistent. I think
you might disagree with my proposed style but I think we both hold the
same idea behind all of that.

Post by Erik Max Francis

Post by Brian Mitchell
Ok. Now that I've replied, please know that is you think I am totally
backwards you can create an alternate by putting together an ICR or
come join me on IRC for a chat. :)

I've already said why I thought most of your ideas weren't good.

Ok. I just don't want to hear someone continue to complain about
something I could probably explain easily in realtime chat. This is
not just targeted at you.

Post by Erik Max Francis
I
don't see the need to create an "ICR" (which you apparently just made
up, but nothing wrong with that) to defend an existing style against
stylstic changes that, I suspect, have little chances of actually being
adopted.

I did make up ICRs. I have heard proposals repeated over many times.
Being able to refer to a specific ICR was a solution to this. It also
serves future purpose. Steve might reject one on conditions. A new
revision can be made that meets the conditions. In the new ICR you
could refer to it as replacing, fixing, combining, and/or requiring
other specific ICRs.

I wouldn't take Io's current position for granted. Io has gone under
large changes in the past and will be certain to make any more soon if
Steve decides to do so as 1.0 will set things in stone for a while.
Telling me that you don't want to make ICRs just tells me that you
don't see room for any change (which is fine with me) or that you
don't care. If the latter is true, please don't bother debating about
these ICRs. I have put thought into these and some of them I have
already decided against after productive feed back. I am doing this in
Io's interest, not for personal gain (though I do make it open that I
am most possibly giving opinions on things -- which might still help).

Thanks,
Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Erik Max Francis]

Post by Brian Mitchell
It think that things we want to encourage regular use of should have
extra help in accessibility. This might include shorter names in many
cases. If we want to encourage idioms where we make heavy use of block
passing for example, we would want to look at my symbols ICR. "times"
feels short to me but still perfectly understandable.

It is still plenty short and is still understandable. Proposing
timesRepeat as an alternative indicates that this is purely a style issue.

Post by Brian Mitchell
I think it makes more sense when attached to real code. I sometimes
want to use a result of a loop like that so I might have an attached
message that makes perfect sense to have on one line but won't be
because I've all of the sudden have a long name that takes me longer
to read. I call this hairier because it just adds more. It feels like
having to put type declarations on things that don't need them
(example would be in another language) or not having do() in Io.

I don't see how this has anything to do with changing repeatTimes to
times. If you feel that it's still readable and short, that's fine.
Others may feel differently. Either way, it's style, not substance, and
the current solution is already perfectly acceptable.

Post by Brian Mitchell
Then how come I can get along fine w/o it? I don't see how this is
needed above any other feature. Ranges are a viable replacement for
the for loop. I would like to see someone submit an ICR on that.

Explain to me, then, why you think for should be removed but upTo/downTo
should be added. They're exactly the same control structure which you
insist is unnecessary. The difference being for is easily recognizable
to even a novice programmer.

Post by Brian Mitchell
I don't think that is completely right. if nil really means that then
why don't we rename that to false? Now you might see what I mean.

Because Nil isn't just false. Didn't you read what I said?

Post by Brian Mitchell
CL has just about every feature so it is usually a relevant place to
turn to for an example.

Except, as I pointed out, that article isn't relevant to Io's use of Nil.

Post by Brian Mitchell
Rare? I thought Io was supposed to be flexible. Now I can't use nil
and I need to invent another type. Booleans seemed a nice place to
invent than here.

I have no idea what this means. The logical thing to return in a
method, in the absence of any required return value, is self. If it's
intended to be a Boolean, then return self for true and Nil for false.
This is what Nil means in Io. I see no reason to change it, and
suggesting to add True and False implies to me a misunderstanding of how
"true" and "false" work in Io. _Everything_ other than Nil is true in
Io, and only Nil and nothing else is false. Adding an additional false
sentinel misses the point.

Post by Brian Mitchell
Yes. I note that my version has slightly different runtime semantics.
One is a method (Object '!=), the other is more like syntax sugar or a
macro (my ICR).

Why is there any need for "syntactic sugar" here? != is an operator,
and so can be used in x != y situations with impunity. What is the need
for changing its status? It already works exactly as you desire (with
the correction to your original formula). What is the benefit of
changing it?

Post by Brian Mitchell
I wouldn't ever enforce style. That spoils a language. I would heavily
suggest a style and make sure the core language is consistent. I think
you might disagree with my proposed style but I think we both hold the
same idea behind all of that.

You are suggesting changing the internal identifiers of all methods in
the Io library. I'd say that's trying to enforce a style.

Post by Brian Mitchell
I did make up ICRs. I have heard proposals repeated over many times.
Being able to refer to a specific ICR was a solution to this. It also
serves future purpose. Steve might reject one on conditions. A new
revision can be made that meets the conditions. In the new ICR you
could refer to it as replacing, fixing, combining, and/or requiring
other specific ICRs.

At this point the Io community is so small that you're probably best off
proposing what you want and starting discussion and seeing where it
goes. If it looks positive, or if you don't care, implement it and send
Steve the patch. If he likes it he'll accept it. If he doesn't he
won't. It's ultimately up to him, as well it should be; programming
languages designed by committee end up being kitchen sink nightmares.
There should ultimately be one person in charge that decides what's
right for the language and what's not, although of course he should be
receptive to input.

Many of your ideas are interesting, like macros. So implement them,
fiddle with them, and see how they turn out! If they're well received
they'll end up in the language in some fashion, maybe; if not, they
won't. It seems like that's how most of the current functionality
(beyond what Steve wrote himself of course) got into Io.

The majority of your proposals seem to me to be purely stylistic issues.
Every programmer has to come up with their own style, and there's
nothing wrong with it; but Io already appears to me to have a strong
sense of style and I see no reason to change it, especially as moving
toward a 1.0 at the end of the year will demand effort be put in more
substantive places.
--
Erik Max Francis && ***@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Whoever named it necking was a poor judge of anatomy.
-- Groucho Marx



------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Erik Max Francis

Post by Brian Mitchell
It think that things we want to encourage regular use of should have
extra help in accessibility. This might include shorter names in many
cases. If we want to encourage idioms where we make heavy use of block
passing for example, we would want to look at my symbols ICR. "times"
feels short to me but still perfectly understandable.

It is still plenty short and is still understandable. Proposing
timesRepeat as an alternative indicates that this is purely a style issue.

I am not proposing that. I said it would be a better alternative if
times is not chosen. It might be but if you count the number of
characters on the name it has 11 character. "times" is only 5. over
50% smaller. To make my comparison more clear, the average length of
method names on object is: 6.7 characters. Number's average is: 6.8.

As this shows it is quite a bit longer than the average Io function. I
would call this sufficient evidence that this is a long name when
comparing to current convention.

I am beginning to think that you don't like using repeatTimes as it is
right now and would rather stick to your for loop. Are you really
fighting the name change or do you want repeatTimes removed?

Post by Erik Max Francis

Post by Brian Mitchell
I think it makes more sense when attached to real code. I sometimes
want to use a result of a loop like that so I might have an attached
message that makes perfect sense to have on one line but won't be
because I've all of the sudden have a long name that takes me longer
to read. I call this hairier because it just adds more. It feels like
having to put type declarations on things that don't need them
(example would be in another language) or not having do() in Io.

I don't see how this has anything to do with changing repeatTimes to
times. If you feel that it's still readable and short, that's fine.

Yes. I do feel that it does make it easier for me to read. Have you
ever been annoyed by someone who names variable overly verbose for
example?

Post by Erik Max Francis
Others may feel differently. Either way, it's style, not substance, and
the current solution is already perfectly acceptable.

Style is substance. It is an important aspect of programming and
should never be ignored. This is the type of argument used when
avoiding an actual solution because not everyone has the same style.
Well, I think Io has style and that this fits it.

Post by Erik Max Francis

Post by Brian Mitchell
Then how come I can get along fine w/o it? I don't see how this is
needed above any other feature. Ranges are a viable replacement for
the for loop. I would like to see someone submit an ICR on that.

Explain to me, then, why you think for should be removed but upTo/downTo
should be added.

I've gone over this one before. To quote myself:

-->8--
The only plus is the fact that you are being more specific about what
you are trying to accomplish.
-->8--

This is the one way to do it. The other would be with ranges. I still
am not convinced that a for loop is a natural way to express things.

Post by Erik Max Francis
They're exactly the same control structure which you
insist is unnecessary. The difference being for is easily recognizable
to even a novice programmer.

No. They are have labels and do a very specific thing. You are not
getting beyond the level of algorithms in this discussion. I called up
my data who only knows programming from punch card FORTRAN
experiences. I asked him what he thought for and upTo meant (reading
what to write aloud). In this experiment (admittedly not really
scientific) he was able to pinpoint iteration over a range on integers
with upTo while for was confused with conditionals.

My sister, who is young (elementary school age), has been playing with
squeak. She has been able to create very interesting constructions w/o
ever using a for loop. One of the language tools used includes a range
tool just like upTo and downTo.

So if they manage with out it, why can't we? Are we to good to _stoop_
to the level of a basic programmer or is it that we never bothered to
realize that the concept is actually useful?

I would say the latter is the sad case of todays languages. granted
that is opinion speaking.

Post by Erik Max Francis

Post by Brian Mitchell
I don't think that is completely right. if nil really means that then
why don't we rename that to false? Now you might see what I mean.

Because Nil isn't just false. Didn't you read what I said?

... I did. to quote:

-->8--
This is what nil means is languages which have the concept of "nil" as
the sole false sentinel. This isn't overloading, it's fundamentally
what a nil means. Nil is a special object, and is the only object
that qualifies as false. All other objects qualify as true.
Therefore you can use any value in a true context, and Nil (and only
Nil) in a false context. That also necessarily means that Nil can be
used in the absence of any other (useful) object, since it's
explicitly set aside as a sentinel. This isn't overloading, it's one
and the same.

The addition of a False sentinel completely destroys the meaning of Nil.
-->8--
and
-->8--
The fourth and final point, that Nil is means false, is the only one
that applies, and is obviously true.
-->8--

I will grant that you never said it is only false directly but you
said it doesn't count in any of the other examples so I assume you
mean that there is only one meaning. My reply to you again would be:

The idea _would_ be to destroy nil and a false value semantically. In
the case where we would destroy nil as a sentinel of false:

I think that is wrong. I've used many languages like this and nil
suites the purpose fine. I often us it as Matz said on the Ruby ML
recently:

-->8--
"nil" denotes underlying assumption (<=> to return an integer value)
is not met. Ruby sometimes use nil as a small error indicator.

matz.
-->8--

Giving that context, it shows where false and nil can have a good
reason to be different things. (If you are familiar with Ruby it might
help understanding this).

Post by Erik Max Francis

Post by Brian Mitchell
CL has just about every feature so it is usually a relevant place to
turn to for an example.

Except, as I pointed out, that article isn't relevant to Io's use of Nil.

And as you snipped out. I've given counter arguments. You need to
learn to go by something a little higher level that literal meaning. I
think you know what I am getting at. The concepts can be substituted
in for the article. It is a simple thing to do. Please, sit back and
attempt to see why I posted the article. There must be some aspect of
it.

Post by Erik Max Francis

Post by Brian Mitchell
Rare? I thought Io was supposed to be flexible. Now I can't use nil
and I need to invent another type. Booleans seemed a nice place to
invent than here.

I have no idea what this means.

It means I think you are limiting me to what nil can represent, there
by forcing me to create new objects. In any case this would happen w/o
false but I could minimize my need and confusion by creating false in
the first place.

Post by Erik Max Francis
The logical thing to return in a
method, in the absence of any required return value, is self.
If it's
intended to be a Boolean, then return self for true and Nil for false.
This is what Nil means in Io.

Lets make this part clear. Once and for all. Nil might mean false. It
is not false so it can't be absolute. One example is the one I gave
above. We could have a case where we want to denote a "not applicable"
or such.

I obviously know that you mean that I should interpret Nil as false in
this Boolean context. What I have been trying to say this whole time
is that it removes any doubt or need to check the context, if I have
false. Clear code. At least for me.

Post by Erik Max Francis
I see no reason to change it, and
suggesting to add True and False implies to me a misunderstanding of how
"true" and "false" work in Io.

I know how things work. In fact I've pointed out a few bugs to get it
to work correctly from how it is now. Please, I know what Object and
Nil can represent. I am only saying that we could be specific about
this.

Post by Erik Max Francis
_Everything_ other than Nil is true in
Io, and only Nil and nothing else is false.

Yes.. I think this entire list knows the _current_ status of boolean
logic in Io.

Post by Erik Max Francis
Adding an additional false
sentinel misses the point.

The point? Let me try to sum you up now as best as I can:

Io already is capable of boolean logic because it has Nil as a false
sentinel. Nil is able to take on this meaning in specific contexts to
give the programmer a way to distinguish the predicate of a boolean
expression. Adding false adds no value to Io and might even fracture
the unified concept of Nil. There are no cases where Nil needs to be
distinguished between a boolean context and any other one. Since all
objects are true we have no need for true either. We can easily return
self in these cases to represent a "true" outcome. Keeping Io free
from too many alternate definitions is a good thing and follows the
spirit of Io.

If I got that right I would like to add a little side to it on my own
reply to it:

I think that the contexts can be ambiguous. Rather than have only one
option I wanted to open it up for more options to give me flexibility
in how I describe things in my code (i.e. "am I returning an empty
value or a boolean value here"). This is the only reason I see to add
false. I can decouple my function from where it is used and not worry
about semantics of a return. As far as true goes, I did give the Nil
isNil example. This is a small case but it is clear that self cannot
be returned nor any immediately relevant object. We could decide
Object to be the candidate for this. I propose that we have a true
object, True/true/T/ThisObjectIsASentinelForTrue. These would give us
a completely logical return for isNil and possibly a new return for
comparisons. nil == nil -> T. Very clear meaning IMO.

Post by Erik Max Francis

Post by Brian Mitchell
Yes. I note that my version has slightly different runtime semantics.
One is a method (Object '!=), the other is more like syntax sugar or a
macro (my ICR).

Why is there any need for "syntactic sugar" here? != is an operator,
and so can be used in x != y situations with impunity. What is the need
for changing its status? It already works exactly as you desire (with
the correction to your original formula). What is the benefit of
changing it?

The main reason I have for this is so it actually means not( l == r )
in all cases. If I override != or remove slots (or protos in some
cases), I lose the definition. There is a reason Io still has a slot
called removeAllProtos. This just keeps the code working at the cost
of making it mean something sane.

Post by Erik Max Francis

Post by Brian Mitchell
I wouldn't ever enforce style. That spoils a language. I would heavily
suggest a style and make sure the core language is consistent. I think
you might disagree with my proposed style but I think we both hold the
same idea behind all of that.

You are suggesting changing the internal identifiers of all methods in
the Io library. I'd say that's trying to enforce a style.

I say we stop using the word style ;). It is a shortcut to saying: I
don't think we can debate this.

The consistent behavior using a macro would allow me to change more
without rooting back to a large number of slots on Object. An
alternative would be to partition Object into other modules which are
included as protos deemed useful to have on the basic object.

Post by Erik Max Francis

Post by Brian Mitchell
I did make up ICRs. I have heard proposals repeated over many times.
Being able to refer to a specific ICR was a solution to this. It also
serves future purpose. Steve might reject one on conditions. A new
revision can be made that meets the conditions. In the new ICR you
could refer to it as replacing, fixing, combining, and/or requiring
other specific ICRs.

At this point the Io community is so small that you're probably best off
proposing what you want and starting discussion and seeing where it
goes.

I did it for future use and for the fact that it makes things easier
to work with over long periods of time. I don't want these discussions
to be lost effort spent in the future. These will be recorded things
that we can look back on for reference, ideas, or information.

Post by Erik Max Francis
If it looks positive, or if you don't care, implement it and send
Steve the patch.

I like this approach too. Unfortunately most of my stuff breaks
regularly as Io changes too fast. Steve's rsync works for pulling
source but we really need an SCM to manage this efficiently. I know
this has been a hot topic. We do have a versioning mechanism right now
but it doesn't really give it back to Steve, it just throws in out on
a bzr repo is all. If we could clean up this process I would be happy
to implement these as testable features.

Post by Erik Max Francis
If he likes it he'll accept it. If he doesn't he
won't. It's ultimately up to him, as well it should be; programming
languages designed by committee end up being kitchen sink nightmares.

Not always, but I agree on the one person decides part. The main thing
I am trying to do is stir discussion. To be honest, I've decided I
like Io w/o false. Why do I keep fighting it? Because I think it has
brought up new points of interest each iteration. I still think we
should add true in some for but that is another discussion.

Post by Erik Max Francis
There should ultimately be one person in charge that decides what's
right for the language and what's not, although of course he should be
receptive to input.

He should listen but I respect Steve's silence in many of these cases. :)

Post by Erik Max Francis
Many of your ideas are interesting, like macros. So implement them,
fiddle with them, and see how they turn out!

Sure thing! I need some time so do be patient. I am currently working
on cleaning up my macro proposal into a new ICR as my first one was
poorly written and had little reasoning attached. But, again, time is
time. :) I have other non-experimental projects for Io including an
automated introduction to Io using Io, a new REPL, and few
enhancements to the parser and compiler. Some of these are on hold for
bug issues or unmade decisions.

Post by Erik Max Francis
If they're well received
they'll end up in the language in some fashion, maybe; if not, they
won't.

I might come over to people as a very stiff personality, but this is
just from the thick skin I've developed over the years from
participating in projects like this. I would rather take action and
learn from a mistake than shut-up and hope things work out. I might
even stir up some emotion from some but this is usually a side effect
of discussing really important issues. I've learned a lot from all of
you.

Post by Erik Max Francis
It seems like that's how most of the current functionality
(beyond what Steve wrote himself of course) got into Io.

I honestly don't see many getting into Io, though I will continue to
at least act optimistic for the sake of the argument. Some of them
might be good candidates for third party libraries, others might be in
the core but optionally included by code. Others might never see the
light of day. Again, I am trying to stir things up before we say 1.0.
I don't want any regrets if we can avoid them.

Post by Erik Max Francis
The majority of your proposals seem to me to be purely stylistic issues.

Languages are stylistic ways of describing process. We should really
avoid that word though. =]

In all reality I understand the pragmatism in having something work
rather than something be tuned for something. It is a matter of style
but it is also something that makes one language differ from another.

Post by Erik Max Francis
Every programmer has to come up with their own style, and there's
nothing wrong with it; but Io already appears to me to have a strong
sense of style and I see no reason to change it, especially as moving
toward a 1.0 at the end of the year will demand effort be put in more
substantive places.

I am really looking forward to ending my rampages over these topics,
but my care for Io is stronger that my laziness. :)

Some updates to include: I am working on setting up a real web app to
handle ICRs in a very similar way to how RCRs (rcrchive.net) are
handled. I hope this pans out but I do have one thing that I still
need: a host. I can host it but my DSL line isn't exactly upper class
service or the kind of thing that is dependable. Volunteers are
welcome.

Thanks,
Brian.

[Erik Max Francis]

Post by Brian Mitchell
I am beginning to think that you don't like using repeatTimes as it is
right now and would rather stick to your for loop. Are you really
fighting the name change or do you want repeatTimes removed?

No, I have no idea where you got that from.

You're not arguing for what the method should have been named in the
first place. You're now arguing to change it given that 1. it's
perfectly clear and 2. everyone is used to it. That is what I am
arguing against.

Post by Brian Mitchell
Style is substance.

Since in programming those words mean the opposite of each other, I
think that's the basis of most of my objections to your proposals.
Style is _not_ nearly as important as you think it is. Getting to a 1.0
release, however, is.

Post by Brian Mitchell
And as you snipped out. I've given counter arguments. You need to
learn to go by something a little higher level that literal meaning.

I pointed out why the article was not relevant. It made the case that
the use in Common Lisp is too overloaded because it's used for four
different things. I pointed out how three of those don't apply to Io.
That means it's not overloaded in Io, and the fundamental basis of the
article is not relevant.

Post by Brian Mitchell
The main reason I have for this is so it actually means not( l == r )
in all cases. If I override != or remove slots (or protos in some
cases), I lose the definition. There is a reason Io still has a slot
called removeAllProtos. This just keeps the code working at the cost
of making it mean something sane.

Are you really suggesting that != should become a macro so that people
can removeAllProtos if they want to? Under what circumstances would
they deliberately do this and _not_ want to explicitly replace behavior
that was originally in their protos if they want to still use it?

Besides, if they removeAllProtos, == isn't going to work either, so
making != fallback to the opposite of == as a macro still would be broken.

One of the advantages of not having these things as macros with
understood functionality means that you can use them for whatever you
want. An Io programmer can choose to use == and != differently if they
wish. What you're suggesting ties them inexorably together for no
substantially good reason (since the != defined in Object already
defaults to something useful). Besides, where does it end? Why
wouldn't you add >, <, <=, >= to that? Why not link + and -? Pretty
soon you'd have a complex web of operators that would prevent customization.

Post by Brian Mitchell
I say we stop using the word style ;). It is a shortcut to saying: I
don't think we can debate this.

No, it is a shortcut to saying I think these issues are far less
important than you do. Stylistic issues like the ones you're proposing
are inherently subjective, which means that there are really no strong
objective arguments to be made for them, and so it comes down to a
matter of opinion.

Post by Brian Mitchell
Not always, but I agree on the one person decides part. The main thing
I am trying to do is stir discussion.

Well, you obviously are ... You just need to be prepared when people
disagree, even strongly. I keep bringing up style issues is not as a
put-down, but as a reminder that when you bring these things up, there
is no "right" answer.

The most important issue with programming style is consistency. Io
already has that very strongly (in fact, stronger than many "mature"
languages"). Once you get the fundamentals, the rest boils down to
opinion. Especially when facing a 1.0 release, an opinion to change
something that's already consistent and understandable loses out to an
opinion to leave it alone, in my book.

[Brian Mitchell]

On 11/10/05, Erik Max Francis <max-***@alcyone.com> wrote:
... snip ...

Post by Erik Max Francis
Erik Max Francis

This is quickly becoming a bull-shit throwing contest to be frank. We
have both repeated our views many times but you still happen to need
to rephrase yourself or twist my words. I've quoted, my own passages
to show how this is getting nowhere. Lets leave this be for the good
of the community.

You know well that I want times and I know well you oppose it. Our
views seem incompatible at the very least. I brought this up because
of this but I think the threshold has been met. I am ceasing my
participation in this particular sub-thread.

Thanks,
Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Jeremy Tregunna]

Post by Erik Max Francis

Post by Brian Mitchell
I am beginning to think that you don't like using repeatTimes as it

is

Post by Brian Mitchell
right now and would rather stick to your for loop. Are you really
fighting the name change or do you want repeatTimes removed?

No, I have no idea where you got that from.
You're not arguing for what the method should have been named in the
first place.  You're now arguing to change it given that 1. it's
perfectly clear and 2. everyone is used to it.  That is what I am
arguing against.

Your second assumption is absolutely wrong. Personally, I have a script
called "sanity.io" which has things like this (just as an example):

Number times := Number getSlot("repeatTimes")

I do this to other methods as well because I'm just not used to the
names. Eventually I'll get used to it, but in this last year, I havn't.

Post by Erik Max Francis

Post by Brian Mitchell
I say we stop using the word style ;). It is a shortcut to saying: I
don't think we can debate this.

No, it is a shortcut to saying I think these issues are far less
important than you do.  Stylistic issues like the ones you're
proposing
are inherently subjective, which means that there are really no strong
objective arguments to be made for them, and so it comes down to a
matter of opinion.

I agree completely.

Post by Erik Max Francis

Post by Brian Mitchell
Not always, but I agree on the one person decides part. The main

thing

Post by Brian Mitchell
I am trying to do is stir discussion.

Well, you obviously are ... You just need to be prepared when people
disagree, even strongly.  I keep bringing up style issues is not as a
put-down, but as a reminder that when you bring these things up, there
is no "right" answer.
The most important issue with programming style is consistency.  Io
already has that very strongly (in fact, stronger than many "mature"
languages").

This is something I must disagree with (specifically, that Io is more
consistent than many "mature languages"), and leave it at that.

Post by Erik Max Francis
--
Erik Max Francis

--
Jeremy Tregunna
***@blurgle.ca

"The three most dangerous things in the world are a programmer with a
soldering iron, a hardware type with a program patch and a user with an
idea." -- Rick Cook

[Rainer Deyke]

Post by Erik Max Francis

Post by Brian Mitchell
ICR-1 Nil renamed to nil

What is the real value in this? Nil is a proto, whether or not you want
to treat it like one.

How do you define "a proto"? I define it as an object that can be
cloned, can be used as a prototype for another object, but is never used
in any other way. This contrasts to "a normal object", which can be
cloned, can be used as a prototype for another object, but can also be
used in other ways.
--
Rainer Deyke - ***@eldwood.com - http://eldwood.com





------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Erik Max Francis]

Post by Rainer Deyke
How do you define "a proto"? I define it as an object that can be
cloned, can be used as a prototype for another object, but is never used
in any other way. This contrasts to "a normal object", which can be
cloned, can be used as a prototype for another object, but can also be
used in other ways.

Nil can certainly be cloned. It just doesn't have much purpose.
Semantic distinctions aside, in Io, there really is no fundamental
distinction between all these things, so nitpicking which should be
capitalized and which shouldn't doesn't make much sense to me.
Certainly I see no reason to _change_ it.

Protos are capitalized, and protos are the equivalent of types. Nil is
a type and also a sentinel. The only types which aren't capitalized are
things like list and vector, but these are factories that return objects
whose protos are List and Vector, so that doesn't apply to Nil either.

[Rainer Deyke]

Post by Erik Max Francis

Post by Rainer Deyke
How do you define "a proto"? I define it as an object that can be
cloned, can be used as a prototype for another object, but is never used
in any other way. This contrasts to "a normal object", which can be
cloned, can be used as a prototype for another object, but can also be
used in other ways.

Nil can certainly be cloned.

So can '5' and 'list'. Everything can be cloned. The key point of my
definition is that a proto can *only* be cloned (or otherwise added to
an object's proto list) and is never used in any other way. This is an
important distinction.

Consider this. 'List' is the prototype of all lists. That means that
it has all of the methods that lists have. However, it is not
(semantically speaking) a list. Even though it has all list methods, it
is not semantically meaningful to call these methods. It is a special
object that has methods which can be inherited, but should not be called
directly. It is "a proto" - an object that can be cloned, but should
not have its other methods called. We mark this special status by
capitalizing its first letter.

Now consider 'Nil'. It does not have the same special status. Unlike
'List', which is not a list, 'Nil' *is* a nil. It is, in fact, the only
nil. Calling the 'isNil' method on 'Nil' is very much semantically
meaningful. I would even go so far is to say that inheriting the
'isNil' method from 'Nil' subverts the intention of that method. 'Nil'
is not "a proto" - it is an object that is intended to be used directly,
without first creating an instance.

[June Kim]

Post by Rainer Deyke

Post by Erik Max Francis

Post by Rainer Deyke
How do you define "a proto"? I define it as an object that can be
cloned, can be used as a prototype for another object, but is never used
in any other way. This contrasts to "a normal object", which can be
cloned, can be used as a prototype for another object, but can also be
used in other ways.

Nil can certainly be cloned.

So can '5' and 'list'. Everything can be cloned. The key point of my
definition is that a proto can *only* be cloned (or otherwise added to
an object's proto list) and is never used in any other way. This is an
important distinction.
Consider this. 'List' is the prototype of all lists. That means that
it has all of the methods that lists have. However, it is not
(semantically speaking) a list. Even though it has all list methods, it
is not semantically meaningful to call these methods. It is a special
object that has methods which can be inherited, but should not be called
directly. It is "a proto" - an object that can be cloned, but should
not have its other methods called. We mark this special status by
capitalizing its first letter.
Now consider 'Nil'. It does not have the same special status. Unlike
'List', which is not a list, 'Nil' *is* a nil. It is, in fact, the only
nil. Calling the 'isNil' method on 'Nil' is very much semantically
meaningful. I would even go so far is to say that inheriting the
'isNil' method from 'Nil' subverts the intention of that method. 'Nil'
is not "a proto" - it is an object that is intended to be used directly,
without first creating an instance.

When I first met Io I tried to carry the class-based oop paradigm into
Io, but I wanted to feel what Io's world is and I am now very happy
that I learned a lot of things from getting out of the class-based
paradigm box.

What I learned from prototype-based paradigm and Io is that it is
often more beneficial if I don't distinguish between class and
instance.

I don't try to distinguish between a "proto"(or a stamp to print out
copies) and the real objects that do the job, and I think, I get
better design. Removing(or relaxing) the distinction gave me more
power and flexibility, and better codes. (my java coding style changed
as well)

I think of FooBar as a "class" and after a while I find out I can use
it as an "instance" as well. In the beginning of coding, I think of
fooBar as an "instance" and later I find out I can use it as a "class"
as well. Now I think of the "proto" as you call, an exemplar. Why not
call methods on the exemplar?

[Jason Grossman]

Post by Rainer Deyke
Consider this. 'List' is the prototype of all lists. That means that
it has all of the methods that lists have. However, it is not
(semantically speaking) a list. Even though it has all list
methods, it
is not semantically meaningful to call these methods. It is a special
object that has methods which can be inherited, but should not be called
directly.

One of the main points of a prototype-based language is that every
object can and should (in some circumstances) be called directly.
There's nothing wrong with

Io> List append("a") append("b")
==> a, b


(Elaboration: Of course that's not what you'd always want to do,
since all descendants of List would then have "a" and "b" as
members. But that will sometimes be exactly what you want, for
either of at least two reasons and probably many more:

1. Your particular problem might require all lists to have certain
default members.

2. You might be doing a quick hack and want to save having to make
up, or type, a new object name. I sometimes use Io interactively and
want to open exactly one input file. Then I just use File to refer
to it, instead of having to clone File and decide what to call the
clone.)


Jason

[Rainer Deyke]

Post by Jason Grossman
One of the main points of a prototype-based language is that every
object can and should (in some circumstances) be called directly.
There's nothing wrong with
Io> List append("a") append("b")
==> a, b

Yes there is: it breaks the invariants of other code that relies on 'List'.

Maybe 'List' wasn't the best example. Consider the following
(hypothetical) example instead: a window object represents a window in
the underlying operating system. All window objects share the 'Window'
prototype. The 'Window' prototype does not represent a window in the
underlying operating system. It is therefore not a window object,
despite having all of the methods of a window object.

Post by Jason Grossman
(Elaboration: Of course that's not what you'd always want to do,
since all descendants of List would then have "a" and "b" as
members. But that will sometimes be exactly what you want, for
1. Your particular problem might require all lists to have certain
default members.

There is no such problem.

Post by Jason Grossman
2. You might be doing a quick hack and want to save having to make
up, or type, a new object name. I sometimes use Io interactively and
want to open exactly one input file. Then I just use File to refer
to it, instead of having to clone File and decide what to call the
clone.)

This is a very poor practice, and will lead to trouble if you ever need
to open a second file. If you feel the motivation to do this, then
perhaps the Io API for opening files as new file objects needs to be
streamlined.

[Jason Grossman]

Post by Rainer Deyke

Post by Jason Grossman
2. You might be doing a quick hack and want to save having to make
up, or type, a new object name. I sometimes use Io interactively and
want to open exactly one input file. Then I just use File to refer
to it, instead of having to clone File and decide what to call the
clone.)

This is a very poor practice

We don't agree. In itself that doesn't matter. What does matter is
that it's exactly this ability of prototype-based languages that
differentiates them from class-based ones. So I really don't think
Steve is going to make it illegal. There are arguments against
having everything be a prototype, and if you buy those arguments you
might be happier using e.g. Python or Smalltalk

Jason


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Mike Austin]

Post by Rainer Deyke

Post by Erik Max Francis

Post by Rainer Deyke
How do you define "a proto"? I define it as an object that can be
cloned, can be used as a prototype for another object, but is never used
in any other way. This contrasts to "a normal object", which can be
cloned, can be used as a prototype for another object, but can also be
used in other ways.

Nil can certainly be cloned.

So can '5' and 'list'. Everything can be cloned. The key point of my
definition is that a proto can *only* be cloned (or otherwise added to
an object's proto list) and is never used in any other way. This is an
important distinction.
Consider this. 'List' is the prototype of all lists. That means that
it has all of the methods that lists have. However, it is not
(semantically speaking) a list. Even though it has all list methods, it
is not semantically meaningful to call these methods. It is a special
object that has methods which can be inherited, but should not be called
directly. It is "a proto" - an object that can be cloned, but should
not have its other methods called. We mark this special status by
capitalizing its first letter.

List *is* a list. It's the prototypical object, a singleton if you will.
Objects that use it as a prototype are building on this singleton.

Post by Rainer Deyke
Now consider 'Nil'. It does not have the same special status. Unlike
'List', which is not a list, 'Nil' *is* a nil. It is, in fact, the only
nil. Calling the 'isNil' method on 'Nil' is very much semantically
meaningful. I would even go so far is to say that inheriting the
'isNil' method from 'Nil' subverts the intention of that method. 'Nil'
is not "a proto" - it is an object that is intended to be used directly,
without first creating an instance.

Again, Nil is a prototypical Nil object. It's a value, or it can be used as a
prototype. In the case of Nil, it's not very useful.


Mike

[Jason Grossman]

Post by Mike Austin
Again, Nil is a prototypical Nil object. It's a value, or it can be used as a
prototype. In the case of Nil, it's not very useful.

Right. But then one might wonder, if it's not very useful, why
consider it a prototype at all? The answer, I think, is this: making
it look like Nil shouldn't be used as a prototype would make the
language documentation more complicated and less elegant. And being
simple, elegant and therefore holdable in one's mind all at once is
one of Io's main goals.

Jason

[Jason Grossman]

Post by Jason Grossman
being
simple, elegant and therefore holdable in one's mind all at once is
one of Io's main goals.

P.S. Perhaps this is just personal, but I see this as Io's biggest
win over Python.

Jason

[Erik Max Francis]

Post by Jason Grossman
Right. But then one might wonder, if it's not very useful, why
consider it a prototype at all? The answer, I think, is this: making
it look like Nil shouldn't be used as a prototype would make the
language documentation more complicated and less elegant. And being
simple, elegant and therefore holdable in one's mind all at once is
one of Io's main goals.

I agree wholeheartedly.
--
Erik Max Francis && ***@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Physics, as we know it, will be over in six months.
-- Max Born (1928)



------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Jason Grossman

Post by Mike Austin
Again, Nil is a prototypical Nil object. It's a value, or it can be used as a
prototype. In the case of Nil, it's not very useful.

Right. But then one might wonder, if it's not very useful, why
consider it a prototype at all? The answer, I think, is this: making
it look like Nil shouldn't be used as a prototype would make the
language documentation more complicated and less elegant. And being
simple, elegant and therefore holdable in one's mind all at once is
one of Io's main goals.

Are you sure that using Nil as a prototype is simple and follows along
Io's goals? I think it is better to leave it as is. If you are looking
into having a more complex value system you could always just add
things like predicates yourself. I like nil myself as I will not be
using it as a prototype whether or not I can (it is a dangerous
practice as nil is used too many ways as has been debated/shown). It
is an absurd argument otherwise or we would just capitalize
everything. Nil is practically the most common object (besides Object)
so making it noted as something more substantial than just another
prototype would be a good thing IMO.

I've talked to Steve and he has his own ideas on this. I won't speak
for him but it seems he is not concerned about people being confused
by what is and isn't used as a prototype but what is convenient to him
and the language in general. This is probably a more healthy stance to
take.

Brian.

[Jason Grossman]

Post by Brian Mitchell
It
is an absurd argument otherwise or we would just capitalize
everything.

I don't see how that implies any absurdity, unless you think I've
said that all prototypes must be capitalized, which I haven't. I've
been arguing against an argument for changing the capitalization of
Nil - i.e., I've been arguing that the status quo is OK. I agree
with your underlying point here, which is that IF all prototypes had
to be capitalized then we'd never have any lower-case names.

Post by Brian Mitchell
I've talked to Steve and he has his own ideas on this. I won't speak
for him
but it seems he is not concerned about people being confused
by what is and isn't used as a prototype but what is convenient to him
and the language in general. This is probably a more healthy stance to
take.

I'm sure Steve didn't put it like that. Sounds more like Larry
Wall :--)

Jason

[Brian Mitchell]

Post by Jason Grossman

Post by Brian Mitchell
It
is an absurd argument otherwise or we would just capitalize
everything.

I don't see how that implies any absurdity, unless you think I've
said that all prototypes must be capitalized, which I haven't. I've
been arguing against an argument for changing the capitalization of
Nil - i.e., I've been arguing that the status quo is OK. I agree
with your underlying point here, which is that IF all prototypes had
to be capitalized then we'd never have any lower-case names.

I probably got a little too general there, but my point was to show
that there is a fine line between the two from your point of view.
That is not a bad thing. It just makes it hard (for me at least) to
decide on how to name things. I realize that Nil vs. nil is a nit-pick
thing but I intend to submit anything that might help polish Io. :)

Post by Jason Grossman

Post by Brian Mitchell
I've talked to Steve and he has his own ideas on this. I won't speak
for him

It is a funny situation to say the least. I meant to give the idea
that this was my interpretation, not official or factual in any way.
:)

Post by Jason Grossman

Post by Brian Mitchell
but it seems he is not concerned about people being confused
by what is and isn't used as a prototype but what is convenient to him
and the language in general. This is probably a more healthy stance to
take.

I'm sure Steve didn't put it like that. Sounds more like Larry
Wall :--)
From conversations over the last few months... that is what I

gathered. He didn't say those words, but from his concerns over the
last bit when I've talked to him, protos being confused has never
really been a core issue. He is currently saying this on IRC if you
want more terse and direct wording:

Steve_Dekorte2: I liked the nil suggestion

and about Nop:

binary42: nop would need t follow. I forgot to add it with Nil.
...
Steve_Dekorte2: it would be nice to get rid of nop

This does not give us a thumbs up or down IMO. It probably means it
got passed the wild and crazy ideas filter. I am sure this one will
fall to its place soon. Of course this is from my interpretation as
always. Steve can let us know when he is ready.

I hope this helps,
Brian.

[Jason Grossman]

Post by Brian Mitchell
my point was to show
that there is a fine line between the two from your point of view.

Yes, definitely.

Jason

[John Nowak]

1. Can you define "treated as a value" please?

2. Coming from a Scheme background, you think I'd agree, but given
that ? is already used to call a method only if it exists, I don't
want to see any Object ?isMethod? floating around. I think the 'is'
part already is good enough in most cases.

8. What if I just want something to run endlessly? Surely loop is the
most logical, no? As for 'for' -- If anything, i'd like for to be
changed to work like it does in C rather than the current counting
method which is less flexible.

12. Why is upTo and downTo better than For, which does the same thing
with one method? For should really be renamed count as far as I'm
concerned.

13. I'd argue that is better to use isNil than have additional
iterator types.

14. Again, the less methods, the better.

15. So now you need to have False and Nil objects, each with
different sets of methods? Seems rather confusing to me. As for only
adding True, just do this: True := Object -- That said, I wouldn't
object to a blessed True object for the sake of clarity when I read
someone else's code.

17. Why on earth would you want slots to be removed when you set them
to Nil? Heavens no, that would be terrible. Oftentimes in objects I
intend to use only as prototypes, I create slots and set them to Nil
so I remember to stick a useful value in there later after I clone
it. I am sure there are other more critical reason why this is a bad
idea, but that alone should suffice. I think.

18. Why is having an infix 'not' more clear than isNil?

22. While I am generally very against adding anything unnecessary to
a language, I'd rather like to see this. If we have ==, we ought to
have !=.

24. Smart.

25. I would just like a more clear way to access a list of arguments
in general. It is rather opaque currently compared to some other
languages.

28. Yes, exactly the reason for what I said in 25.

29. Agreed.

31. This has been suggested before. Seems good to me.

32. I need more convincing. :-)

34. Right now I use CapitalizedCamelCase for objects,
lowercaseCamelCase for methods, and underscore_names for slots that
hold a value. I really don't care what Io encourages, as long as it
is consistent and logical. The real issue for me is, with my system,
how to I differentiate between a method and a slot that holds a
value? I know in Self there is no distinction in syntax, and that's
fine, but I'd like some sort of nice convention we could (mostly)
agree upon.

I may just start using this:
SomeObject
someMethod
some_variable
variable_

- John






------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[John Nowak]

I have no idea why those all went at once. I just resubscribed to the
group and nothing went when I was sending it. Obviously something was
screwy with yahoogroups. Should be okay now I hope.

- John

[Brian Mitchell]

Post by John Nowak
1. Can you define "treated as a value" please?

It is a fuzzy definition, sure. I would say that one would use it as a
final state rather than in construction of a new value.

Post by John Nowak
2. Coming from a Scheme background, you think I'd agree, but given
that ? is already used to call a method only if it exists, I don't
want to see any Object ?isMethod? floating around. I think the 'is'
part already is good enough in most cases.

interesting. I am going to post about ?'s behavior. Where did

?isMethod?

come from?

The ? would only be legal as the last char of a name. The is would be
gone and the ? operator is not ambiguous unless there is no space
between it and the target.

Object ? method?

seems fine to me.

Post by John Nowak
8. What if I just want something to run endlessly? Surely loop is the
most logical, no? As for 'for' -- If anything, i'd like for to be
changed to work like it does in C rather than the current counting
method which is less flexible.

loop is a good idea. Just use break and continue as already available.

Post by John Nowak
12. Why is upTo and downTo better than For, which does the same thing
with one method? For should really be renamed count as far as I'm
concerned.

The only plus is the fact that you are being more specific about what
you are trying to accomplish.

Others mentioned ranges and iterating elements of the ranges. That is
another good option to replace for loops.

Post by John Nowak
13. I'd argue that is better to use isNil than have additional
iterator types.
14. Again, the less methods, the better.

You probably me conditional not iterators ;)

Sure. I would still like to see not in there along with booleans. But
again, this is a bunch of stuff that I am not set in stone. I only
post because it is what I believe is good.

Post by John Nowak
15. So now you need to have False and Nil objects, each with
different sets of methods? Seems rather confusing to me. As for only
adding True, just do this: True := Object -- That said, I wouldn't
object to a blessed True object for the sake of clarity when I read
someone else's code.

Good points. I would agree but still favor having false. I would
lowercase true like my nil proposal though.

Post by John Nowak
17. Why on earth would you want slots to be removed when you set them
to Nil? Heavens no, that would be terrible. Oftentimes in objects I
intend to use only as prototypes, I create slots and set them to Nil
so I remember to stick a useful value in there later after I clone
it. I am sure there are other more critical reason why this is a bad
idea, but that alone should suffice. I think.

Good point. The update slot idiom would break in this case.

Post by John Nowak
18. Why is having an infix 'not' more clear than isNil?

can be debated. I like not as I can read that easily because of the
distance between it and the next boolean op:

not foo and bar
vs.
foo isNil and bar

The distance is the only thing about this one. not is also good if we add false.

Post by John Nowak
22. While I am generally very against adding anything unnecessary to
a language, I'd rather like to see this. If we have ==, we ought to
have !=.

we do have it. it is just not replaced. We could continue as is. This
one has very subtle differences.

The main thing about != in both cases is that you get it for free by
just implementing ==. A little bit of the DRY principle here. The
other part is a little bit about optimization.

Post by John Nowak
24. Smart.

I think this one is sort of wild and crazy still but I would be
delighted to continue discussion on this. It was one of those things
where I was thinking about argument lists and how I don't like how
their construction is hard coded. Then bam! my Haskell came back to
me. ;)

Post by John Nowak
25. I would just like a more clear way to access a list of arguments
in general. It is rather opaque currently compared to some other
languages.

The splat could be handled with some changes or we could make some
helpers for constructing new messages with custom arguments.

Post by John Nowak
28. Yes, exactly the reason for what I said in 25.

I have not sold myself on this one yet believe it or not. :)
The main thing to work on is syntax. The concept still holds.

Post by John Nowak
32. I need more convincing. :-)

I will try to update this ICR tomorrow. Stay tuned.

Post by John Nowak
34. Right now I use CapitalizedCamelCase for objects,
lowercaseCamelCase for methods, and underscore_names for slots that
hold a value. I really don't care what Io encourages, as long as it
is consistent and logical. The real issue for me is, with my system,
how to I differentiate between a method and a slot that holds a
value? I know in Self there is no distinction in syntax, and that's
fine, but I'd like some sort of nice convention we could (mostly)
agree upon.
SomeObject
someMethod
some_variable
variable_

That might work. I use methods more than variables though so I find
the variable exception sort of a small case issue.

I too will use the final style, but I thought I would throw mine out
there with some force to get a chance with it. :)

Thanks for your feed back. It has been really helpful. I will try to
get these up on the pipapo wiki soon with respective fixes and
updates. I will also be posting more, but this is not just for me. :)
Others should feel free to brain storm and write a few.

Brian.

[Rainer Deyke]

Post by Brian Mitchell
ICR-34 Camel vs. Underscore
I propose that we move method names to use underscore syntax and keep
proto objects with CapitalizedCamelCase.

Without wanting to get into a heated argument about style, I'd like to
explain why my own Io-like language uses underscore_syntax instead of
camelCase. It's not because of readability, but because of consistency.

When a underscore_syntax identifier is broken into its components, each
component is a valid underscore_syntax identifier. If a camelCase
identifier is broken into its components, this is not the case.

Let me give a specific example of why this matters. In my specific
Io-like language I have defined syntactic sugar for setting properties.
Given an expression 'a b = c', if 'a' has no slot 'b', the expression
is translated into 'a set_b(c)'. In other words, it is possible to
define a writable property 'x' by defining a method called 'set_x'. This
works out well because for any 'x' that is a valid underscore_syntax
identifier, 'set_x' is also a valid underscore_syntax identifier.

If I had used camelCase, I would have had to choose one of the following
options:

1. Use MixedCase (with the first letter capitalized) for the property.
This would have made properties look like prototypes, which is a bad thing.

2. Use camelCase for the property and end up with methods where two
sequential words are lower case, like 'setthisProperty'. This would
have severly hurt the readability and consistency of the code.

3. Automatically convert between upper case and lower case, such that
'a thisProperty = c' is translated into 'a setThisProperty(c)'. This
would have been extremely messy.

4. Use some hybrid system such that 'a thisProperty = c' translated into
'a set_thisProperty(c)'. Even with its inconsistency, this would
probably have been the best choice. But if I need underscores anyway,
why not go all the way and use underscore_syntax consistently?

[June Kim]

Hi Brian,

On 11/9/05, Brian Mitchell <***@gmail.com> wrote:
[snip]

Post by Brian Mitchell
ICR-17 Slot lifetimes and nil
I propose that slots are nil by default and are removed when set to nil.
Right now we have quite a few slot operations: newSlot, removeSlot,
setSlot, getSlot, and updateSlot. We could consolidate and remove the
need to newSlot and removeSlot.
setSlot("a", 1)
setSlot("b", 2)
slotNames sort
a, b
setSlot("a", nil)
slotNames sort
b

The problem here is nil already has one meaning and now it has two
meanings and becomes ambiguous.

What if I want to create a slot named "a" which has nothing?

setSlot("a",nil) #or if the default is nil, setSlot("a")

Now we know that: a isNil is true.

And then what if I want to remove the slot somewhere?

setSlot("a",nil)

Here, nil is ambiguous, which changes its meaning to remove it as a
whole instead of making it as "having nothing". (not existing and
having nothing is different)

Post by Brian Mitchell
ICR-23 case expression

I am not very sure if we need the case expression.
http://wiki.cs.uiuc.edu/CampSmalltalk/Smalltalk+case-statement

Thank you for the thoughtful suggestions.

p.s.

One of the great things of Io language is that almost all you
suggested is possible in the current implementation of the language
without changing the language syntax or the c codes.

One impression I got from Matz's presentation on the future of Ruby in
RubyConf 2005 was that Ruby's trying to incorporate python's(and
others') path and becoming "dizzy" and complexed rather than cleaner
and more elegant, losing the consistency. I guess ruby could become
harder to learn and lose its sweetness.

We have this subconcious identity equation that puts improvement and
adding on each side and tend to try hard to add more things in. I
wonder if we could improve without adding or even subtracting things.
I just wonder.

[Brian Mitchell]

Post by June Kim
Hi Brian,
[snip]

Post by Brian Mitchell
ICR-17 Slot lifetimes and nil
I propose that slots are nil by default and are removed when set to nil.
Right now we have quite a few slot operations: newSlot, removeSlot,
setSlot, getSlot, and updateSlot. We could consolidate and remove the
need to newSlot and removeSlot.
setSlot("a", 1)
setSlot("b", 2)
slotNames sort
a, b
setSlot("a", nil)
slotNames sort
b

The problem here is nil already has one meaning and now it has two
meanings and becomes ambiguous.
What if I want to create a slot named "a" which has nothing?
setSlot("a",nil) #or if the default is nil, setSlot("a")
Now we know that: a isNil is true.
And then what if I want to remove the slot somewhere?
setSlot("a",nil)
Here, nil is ambiguous, which changes its meaning to remove it as a
whole instead of making it as "having nothing". (not existing and
having nothing is different)

A valid complaint. It would be removing the ability to know when a
slot is defined and not. Right now an invalid getSlot name returns
nil. Perhaps that needs reform.

Post by June Kim

Post by Brian Mitchell
ICR-23 case expression

I am not very sure if we need the case expression.
http://wiki.cs.uiuc.edu/CampSmalltalk/Smalltalk+case-statement

Those are nice examples of how we could implement a case statement but
not necessarily showing that we couldn't use one.

Thanks for the link though. I will ponder this further.

Post by June Kim
Thank you for the thoughtful suggestions.
p.s.
One of the great things of Io language is that almost all you
suggested is possible in the current implementation of the language
without changing the language syntax or the c codes.
One impression I got from Matz's presentation on the future of Ruby in
RubyConf 2005 was that Ruby's trying to incorporate python's(and
others') path and becoming "dizzy" and complexed rather than cleaner
and more elegant, losing the consistency. I guess ruby could become
harder to learn and lose its sweetness.
We have this subconcious identity equation that puts improvement and
adding on each side and tend to try hard to add more things in. I
wonder if we could improve without adding or even subtracting things.
I just wonder.

I fear that I am off target with Io sometimes but then I remember that
Io is a set of concepts still growing. Some of the concepts seem to
hint that Io is a base language to be built upon. I think this would
be a good argument for discussion of features. Are they fundamental?
Are they useful? Are we cutting too much out? Do we have too many
things rarely used?

In the end it is Steve's place to decide for Io. I am trying to serve
as a source of ideas and possibly ideals when I submit things like
this.

One draw back of my point of view is that I am a user of the language
more that an implementor. This gives me blinders to what might be too
far off mark. People like Matz seem to have a good sense for language
design that I don't have. In the end of all of this, I think it is
better to put up ideas rather than avoid them being afraid of
erroneous judgement on anyone's part. I am already thinking twice
about two or three of my ICRs but I don't regret them.

Thanks for the remarks,
Brian.

[Steve Dekorte]

Brian,

Thanks for the change requests. I appreciate the feedback and encourage
everyone to submit their suggestions to me or the list soon so accepted
suggestions can make it into the 1.0 release.

Here are the suggestions that seem to me (at first glance) like a good
fit:
- nil
- setters return self
- true/false
- iterators (in general, but not the details)
- ===

Cheers,
-- Steve

[Brian Mitchell]

Post by June Kim
Brian,
Thanks for the change requests. I appreciate the feedback and encourage
everyone to submit their suggestions to me or the list soon so accepted
suggestions can make it into the 1.0 release.
Here are the suggestions that seem to me (at first glance) like a good
- nil
- setters return self
- true/false
- iterators (in general, but not the details)
- ===
Cheers,
-- Steve

Thanks for the pointers. May if talk you out of any of them now? :)
You can see my other post on some info on why false is probably not a
huge plus but that true might be good.

I can work on implementing iterators in Io is you are interested. It
might involve some collections rework to make it fit it first class.

Thanks,
Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Kevin Edwards]

Post by Brian Mitchell
ICR-2 support richer method names
I propose that we allow ? as a last character in a method name.

This seems useful, with the downside being the removal of those
characters from operator status or risking ambiguity. We could make
an exception when prefixing "?" in order to keep its current purpose.

"!" has other problems due to extant operators, e.g. how should we
parse "x!=y"?... unless Io wants to enforce a whitespace/parens rule
to separate tokens (which is perhaps what you were suggesting with
"Object ? method?").

IIRC, Steve appends a trailing underscore to mutator functions in C
code... this convention could also be used in Io, if so desired (as
opposed to "InPlace" or "!").

Post by Brian Mitchell
ICR-4 IO type hierarchy
I propose we clean up the I/O objects into clearer objects and
prototypes.

...

Post by Brian Mitchell
Notice the large number of isXYZ methods. These could be removed and
mySocketObject hasProto(Socket)

The isXYZ methods seem intended to support duck typing, where (for
example) any object that returns true to "?isSocket" could be used
as a Socket, even if it doesn't have Socket as a proto.

So, I'm not sure if it's a good idea to use a proto as formally
defining an interface, since it may be big and comes coupled with an
implementation. We also have to be mindful of clone/init and what
kind of C IoObject we really have.

I agree that a cleaner interface/type system would be nice, but I
don't know Io's design goals and thus how to integrate them with
prototypes. I think there's a similar dilemma with scoping.

Post by Brian Mitchell
ICR-15 Booleans
ICR-18 Not in booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.

I like true, false, not, etc. I suppose "false" could be nil rather
than a distinct value, if we wish to maintain the simple universal
division of true and false. e.g. false := Nil

Post by Brian Mitchell
ICR-20 Enumerable
ICR-19 Comparable
ICR-22 !=

Sounds useful. So would Object have Comparable as a proto?

In the general case, there'd be an extra lookup for every comparison
(as they are redirected to <=>), though I suppose this could be
optimized, and I do like the idea of consolidating the semantics.

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also mentioned
"~=" or variants that look a little bit better to me.

Post by Brian Mitchell
ICR-24 "," cons
ICR-25 Argument object type
ICR-26 Argument delegation and splat
ICR-28 better argument handling
ICR-30 activation

Generally good ideas, somewhat similar to my own, but I'm not sure I
understand your proposal in the context of Io. Most of the
flexibility you want with Arguments may be possible, but some of your
syntax and implementation suggestions (e.g. making "," an operator)
sound like a fairly big departure from Io's simple messaging syntax
and semantics.

Would parenthesis create an Arguments object that would take the first
token as a message and then become the target of any commas within
those parenthesis? When are parens and commas evaluated? Is the Arg
object then sent to the function (prior to activation) as a literal
(cachedResult) message?

How would your autodetected currying (ala ocaml or haskell?) work with
variable arity functions?

Post by Brian Mitchell
ICR-32 macros
ICR-33 expand

Some macro basics should be easy enough, but Io's dynamicity makes
semantic analysis difficult, which is perhaps my largest concern.
i.e. it may be difficult to determine what a message evaluates to
without actually evaluating it, in context. Of course, we could
restrict Io's dynamicity for macros or require special syntax.

Post by Brian Mitchell
ICR-10 Iterator type and iterator returns
ICR-23 case expression
ICR-31 symbols
ICR-33 inspect

These sound useful.

Thanks for sharing your ideas.

Kevin

[Jason Grossman]

Post by Kevin Edwards

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also mentioned
"~=" or variants that look a little bit better to me.

Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.

Jason


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Steve Dekorte]

Post by Jason Grossman
Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.

How about:

a is(b)

?

-- Steve



------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Steve Dekorte

Post by Jason Grossman
Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.

a is(b)
?
-- Steve

The only reason I hesitate on this is that it is a relative
comparison. "is" sounds to assertive of equality but I would like to
hear what others think.

Brian.

[Brian Mitchell]

Post by Jason Grossman

Post by Kevin Edwards

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also mentioned
"~=" or variants that look a little bit better to me.

Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.
Jason

I am amiable to the idea. Any other ones to add to the list? I came up with:

<>
=~=
=~
similar?()
isSimilar()

No reason we can't just make it a normal method if the name fails. :)

Brian.

[Bob Ippolito]

Post by Brian Mitchell

Post by Jason Grossman

Post by Kevin Edwards

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also
mentioned
"~=" or variants that look a little bit better to me.

Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.

<>
=~=
=~
similar?()
isSimilar()
No reason we can't just make it a normal method if the name fails. :)

"===" is what JavaScript and PHP use for "is equal to and is of the
same type"... it'd be a real mistake to use that to mean something else.

"is" is also a bad choice because in Python "is" means identity.

"=~" is used in Perl for string matching and substitution

"<>" is used in SQL (and is generally valid in other environments) to
mean NOT equals (e.g. "!=")

I think it should be named, the kind of "similarity" you're trying to
express doesn't really have prior art as a symbolic operator, AFAIK,
all of the "obvious" choices are used by other languages to mean
other things, and something like =~= is going to confuse the hell out
of someone just starting out with Io and they'll have to look it up.
It's probably also of note that a lot of search engines (e.g. Google)
don't really let you search for symbols like that...

-bob

[Brian Mitchell]

Post by Bob Ippolito

Post by Brian Mitchell

Post by Jason Grossman

Post by Kevin Edwards

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also mentioned
"~=" or variants that look a little bit better to me.

Also, "===" is difficult to differentiate from "==" (in some fonts,
anyway). I agree that "~=" is better.

<>
=~=
=~
similar?()
isSimilar()
No reason we can't just make it a normal method if the name fails. :)

"===" is what JavaScript and PHP use for "is equal to and is of the
same type"... it'd be a real mistake to use that to mean something else.
"is" is also a bad choice because in Python "is" means identity.
"=~" is used in Perl for string matching and substitution
"<>" is used in SQL (and is generally valid in other environments) to
mean NOT equals (e.g. "!=")
I think it should be named, the kind of "similarity" you're trying to
express doesn't really have prior art as a symbolic operator, AFAIK,
all of the "obvious" choices are used by other languages to mean
other things, and something like =~= is going to confuse the hell out
of someone just starting out with Io and they'll have to look it up.
It's probably also of note that a lot of search engines (e.g. Google)
don't really let you search for symbols like that...
-bob

Probably the most unfortunate part of designing a language is all of
the names languages before yours have used. Every single operator
symbol is likely to be found somewhere. I used === originally because
that is what Ruby uses and that is my primary background.

I am starting to think that an actual method might be best as this
won't be called directly very often (by case and related code).

Brian.

[Steve Dekorte]

Post by Bob Ippolito
"is" is also a bad choice because in Python "is" means identity.

I thought === was being proposed as an identity comparison operator. I
suggested is() as an option.

-- Steve

[Bob Ippolito]

Post by Steve Dekorte

Post by Bob Ippolito
"is" is also a bad choice because in Python "is" means identity.

I thought === was being proposed as an identity comparison operator. I
suggested is() as an option.

I agree that is() is good for identity, but that's not what the

Post by Steve Dekorte

Post by Bob Ippolito
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).
This operator would be nice when we want to know if something is
similar to another thing. In this case it would be just like hasProto
but with checks on == first.
This is just a convenient operator for case expressions and the like
(see some of my other ICRs). == is a pain to use in these cases if you
want to mach either a value or a type of object.

Apparently === is used in Ruby as the "case" operator..

case subj
when pred then result
end

result is chosen when pred === subj

The idea is that things like Regexp and Range implement it such that
you can use expressions like:

case x
when (1..10) then result
when (10..50) then result
end

case s
when /[a-Z]+/ then result
when /\d+/ then result
end

It seems like a convenient concept, if you have case statements, but
a really poor name for that almost always implicit operator.

-bob

[Thomas Sutton]

Post by Bob Ippolito

Post by Steve Dekorte

Post by Bob Ippolito
"is" is also a bad choice because in Python "is" means identity.

I thought === was being proposed as an identity comparison operator. I
suggested is() as an option.

I agree that is() is good for identity, but that's not what the

Post by Steve Dekorte

Post by Bob Ippolito
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).
This operator would be nice when we want to know if something is
similar to another thing. In this case it would be just like hasProto
but with checks on == first.
This is just a convenient operator for case expressions and the like
(see some of my other ICRs). == is a pain to use in these cases if you
want to mach either a value or a type of object.

Apparently === is used in Ruby as the "case" operator..
case subj
when pred then result
end
result is chosen when pred === subj
The idea is that things like Regexp and Range implement it such that
case x
when (1..10) then result
when (10..50) then result
end
case s
when /[a-Z]+/ then result
when /\d+/ then result
end
It seems like a convenient concept, if you have case statements, but
a really poor name for that almost always implicit operator.

If this is a method on the predicate (the regexps and ranges in the
above examples), then perhaps matches() might be a useful name.
Another alternative (depending on how general we want the concept
to be) might be contains() in the sense that the sets (of strings
or numbers) accepted or induced by the regexp or range contain the
item.

This doesn't appear to be what ICR-21 is referring to, though. If I
had to guess, the suggested operator is true iff there exists some
prototype which is an ancestor of both arguments. I'm not sure how
useful a naive implementation of this would be as if the hierarchy,
or that part of it used in the application, has a root then this
will be trivially true.

Cheers,
Thomas

[Nicholas Seckar]

Post by Bob Ippolito
I think it should be named, the kind of "similarity" you're trying to
express doesn't really have prior art as a symbolic operator, AFAIK,
all of the "obvious" choices are used by other languages to mean
other things,

For the record, === is used in Ruby for this exact thing. But
furthermore we shouldn't be overly concerned about stomping on
various operators from other languages. People arriving from these
languages will either be
i) prepared to accept new meanings for the less common operators,
such as === or =~, or
ii) not really prepared to learn a new language anyways

An issue with some of the other suggestions such as =~= is that they
are.. ugly. Visual appearance and readability might be unimportant to
some, but if we can avoid cryptic operators and instead make use of
expressive words, we will be at an advantage.

In addition, from my experience with Ruby, it is pretty rare that one
makes use of this feature by hand; the most common use of === is
inside case expressions. Because it's not a common operation, there
may be little to gain from giving it status as an operator.





------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Brian Mitchell]

Post by Kevin Edwards

Post by Brian Mitchell
ICR-4 IO type hierarchy
I propose we clean up the I/O objects into clearer objects and prototypes.

...

Post by Brian Mitchell
Notice the large number of isXYZ methods. These could be removed and
mySocketObject hasProto(Socket)

The isXYZ methods seem intended to support duck typing, where (for
example) any object that returns true to "?isSocket" could be used
as a Socket, even if it doesn't have Socket as a proto.

I don't consider that duck typing. It seems more like a COM query
system than duck typing. Duck typing involves query on a behavior
level not on the object or "type" level. A hasSlot() method is closer
to what I consider duck typing.

Post by Kevin Edwards
So, I'm not sure if it's a good idea to use a proto as formally
defining an interface, since it may be big and comes coupled with an
implementation. We also have to be mindful of clone/init and what
kind of C IoObject we really have.

I hope this sort of hierarchy will allow the data to be simplified in
sub-objects when using IO and related as prototypes. Right now File is
treated like what I want IO to be. We could keep things like isSocket
if people find that useful. It would rather be overridden if we did
use that option.

This might also make some C extensions fit in a little easier. Socket
is currently prototyped from Object. IO might be a more appropriate
place to build from. File obviously doesn't match.

Post by Kevin Edwards
I agree that a cleaner interface/type system would be nice, but I
don't know Io's design goals and thus how to integrate them with
prototypes. I think there's a similar dilemma with scoping.

I am not really disappointed with the type system, but with how we use
it (or don't use it) in some cases. This is one place where we could
really take advantage of differential inheritance.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-15 Booleans
ICR-18 Not in booleans
I propose we add true and false to the language. false and nil would
be the only values acted on as a "false value" in a boolean
expression.

I like true, false, not, etc. I suppose "false" could be nil rather
than a distinct value, if we wish to maintain the simple universal
division of true and false. e.g. false := Nil

After some heated debate both on and off this list, I've decided that
false is something that could easily be added by a user if the case is
really that dire. True however might be something more useful to add
if only to have something to balance rather than _everything else_. I
am not against false though. I would not be bothered by its addition
but I am not bothered by the lack thereof either. I guess I've gone
closer to neutral.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-20 Enumerable
ICR-19 Comparable
ICR-22 !=

Sounds useful. So would Object have Comparable as a proto?

Yes. This is just trying to use the object inheritance system to its
fullest again. It allows these to be used when Object is not in the
prototype list (very useful for isolated domain language and logic).

I think inclusion of Comparable is a good thing for object. Behavior
could at least give us ==. Object could implement <=> by returning 0
when == is true. Otherwise it could return nil signifying it does not
apply in that case, so things like >= could return nil, false, or
throw an exception depending on the behavior we choose.

Post by Kevin Edwards
In the general case, there'd be an extra lookup for every comparison
(as they are redirected to <=>), though I suppose this could be
optimized, and I do like the idea of consolidating the semantics.

I think the main plus would come in the fact that we could still
override comparison but we could harness <=> to have a really easy way
to get a lot of functionality for free.

Enumerable follows the same sort of principle.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-21 ===
I propose we add === (a.k.a. the similar to operator).

Sounds useful, but relative to your definition, the name "similar to"
and the syntax "===" looks strange to me since hasProto is not
commutative, while equality (and my notion of similarity) is. Maybe
"isa" or "specific" or (inversely) "subsumes". Someone also mentioned
"~=" or variants that look a little bit better to me.

=== would not be commutative. Good catch. This was an expected
behavior from me but only because I've used languages that provide
such a mechanism. This would be a valid point against === if you don't
understand the order.

Some more interesting things that could be done with === include
matching regular expressions (again this is sort of for case
statements):

case(string
) when( Regex clone setPattern("somePattern"),
....
) ....

and so on.

The plus of this is that when we add Regex to the language via some
sort of an extension, we don't have to rewrite it to tell it to match
the regex. We just implement === inside of the regex instead, leading
to a very clean way of providing custom case structure.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-24 "," cons
ICR-25 Argument object type
ICR-26 Argument delegation and splat
ICR-28 better argument handling
ICR-30 activation

Generally good ideas, somewhat similar to my own, but I'm not sure I
understand your proposal in the context of Io. Most of the
flexibility you want with Arguments may be possible, but some of your
syntax and implementation suggestions (e.g. making "," an operator)
sound like a fairly big departure from Io's simple messaging syntax
and semantics.

It would be fairly large. The "," thing was to enable more custom
constructions for arguments. Right now I can't easily delegate from a
dynamically parameterized method to any other one (besides snatching
arguments from the message to be executed by method which is not
simple and has side effects -- actually stays in tree).

Post by Kevin Edwards
Would parenthesis create an Arguments object that would take the first
token as a message and then become the target of any commas within
those parenthesis? When are parens and commas evaluated? Is the Arg
object then sent to the function (prior to activation) as a literal
(cachedResult) message?

All good questions. The comma would be evaluated like an operator with
a low precedence. It would create an arguments object from a prototype
called Arguments. This object could be passed around normally and
introspection would be provided. When a call is made, the activated
message would either get a message or Arguments. The message would be
processed into an Arguments object. With Arugments now created it
would be made an attribute of the call (thisMessage arguments). This
would allow me to pass the object on or add things made especially for
argument processing to Arguments to make my life easier.

This would slow down calls tremendously using our current interpreter.
If we had a VM there would be ways to optimize most cases to make this
a realistic feature. I put this one out there more because it was
interesting that probable.

Post by Kevin Edwards
How would your autodetected currying (ala ocaml or haskell?) work with
variable arity functions?

I wouln't curry with the above. The curry remark was related to the
syntax of case and other control structures. They proposed something
like:

while( ... ) (
...
)

This wouldn't work unless you did one of three things:

1) Implement an activation method using the "" slot (thanks to quag
for pointing this out).
2) Implement some sort of activation mechanism that waits until it
stops getting () to add on to the argument list.
3) Something wild and crazy. We would need substantial change to
actually make this work otherwise.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-32 macros
ICR-33 expand

Some macro basics should be easy enough, but Io's dynamicity makes
semantic analysis difficult, which is perhaps my largest concern.
i.e. it may be difficult to determine what a message evaluates to
without actually evaluating it, in context. Of course, we could
restrict Io's dynamicity for macros or require special syntax.

I promise I will update these with a much richer description. If I was
coming from a readers perspective I probably would have passed on it
because of its vagueness. The idea with macros it to provide a uniform
way to accomplish everything we would do with message injection and
modification. Stay tuned as this will be one of the first ICRs to be
revised when the new ICR web-app is ready.

Post by Kevin Edwards

Post by Brian Mitchell
ICR-10 Iterator type and iterator returns
ICR-23 case expression
ICR-31 symbols
ICR-33 inspect

These sound useful.
Thanks for sharing your ideas.
Kevin

And thanks for yours. I hope my explanations above clarify rather than
confuse the situation for you.

Brian.


------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links

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

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

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

[Kevin Edwards]

Post by Brian Mitchell

Post by Kevin Edwards

Post by Brian Mitchell
ICR-4 IO type hierarchy
I propose we clean up the I/O objects into clearer objects and prototypes.

...

Post by Brian Mitchell
Notice the large number of isXYZ methods. These could be removed
mySocketObject hasProto(Socket)

The isXYZ methods seem intended to support duck typing, where (for
example) any object that returns true to "?isSocket" could be used
as a Socket, even if it doesn't have Socket as a proto.

I don't consider that duck typing. It seems more like a COM query
system than duck typing. Duck typing involves query on a behavior
level not on the object or "type" level. A hasSlot() method is
closer to what I consider duck typing.

I apologize; after checking, it appears I was entirely wrong in my
description of isXYZ methods. e.g. isSocket is unrelated to Socket;
rather, it is a test of the underlying file descriptor. "File" is the
abstraction used by the OS, and Io is basically just exposing it.
Thus, for example, "Socket ?isSocket" is Nil.

Kevin