greg c

My last post about the idea of an EiffelScript language received a lot
of good responses. Is there enough interest in this for me to create a
mailing list dedicated to EiffelScript, or would it be better to just
continue with the discussion here?

In the last thread there were many good ideas as to what to implement
in EiffelScript, ranging from starting with Ruby as a base, to more
free-wheeling ideas about the role of static typing and type
determination.

I have two top priorities:

1) That the syntax for EiffelScript be as close to Eiffel as possible
(but no closer ;-) )

2) EiffelScript must provide contract and assertion mechanisms like
those in Eiffel.

After thinking about that for a while, my imagination started to
wander.

Consider the often maligned Eiffel loop construct. It occured to me
that the "from" statement is often not needed, since the initialization
instructions can always occur before the loop itself. As far as I can
tell, the "from" key word is really only needed to signal that
invariant and variant clauses are for a loop and not some syntax error.

Then, ala Lisp, would it be possible to define some EiffelScript
primitives that would let us define a loop construct in terms of those
primitives?

Standard Eiffel allows us to define pre/infix operators. Loosen this up
a bit to allow the operators to be procedures, and to be any
non-reserved word (let's worry about how this will get parsed later)
and say that a code block is defined with begin/end pairs, then could
we build a loop construct construct from these primitives? A basic
version might look vaguely like this in its declaration:

prefix "until" (control_clause: FUNCTION[ANY, TUPLE, BOOLEAN],
loop_body: PROCEDURE[ANY, TUPLE])

prefix "loop" (PROCEDURE[ANY, TUPLE]): PROCEDURE[ANY, TUPLE]

and like this in practice:

until boolean_expression loop begin do_something end

I'm taking a lot for granted here; for example, I'm assuming an implied
creation of inline agents that get passed around, and that "until" can
correctly suck in two parameters.

Of course, somewhere looping still has to really happen, down in the
implementation of "until", I suppose, since "loop" really becomes a
synonym for "agent"? But it would shut up those people who complain
about a single loop construct, since now they could go write their own.
(Not that that's necessarily a Good Thing.)

I really like agents and tuples in use they're pretty elegant. But I've
never liked the verbosity of their declarations. It's just so
cumbersome, especially when you start combining them with generics.
It's too bad that square brackets were chosen for delimiting generics
in the first place; it gives newbies wrong ideas because they look like
subscripts, and their meaning has been overloaded between tuples and
generics. Oh well.

Anyway, this is the kind of thing that keeps me up late at night, at
least when my wife is traveling!

Greg C

jojo

Greg C


the simplest is the best. but to avoid pollution of the current
newsgroup and if it tolerate such descissions, it should remain in one
thread.


agreed


the agents that you wrote? Is it the instance made by the local
variables of the feature?


i really like agent too.

peter horan

ANY is the generic parameter which stands for the object which provides
the feature which is invoked as an agent. This object is the object on
which the feature is called. TUPLE carries the arguments and BOOLEAN
carries the result of the function agent.

For example, given
class CONTAINER; feature has (v: like item): BOOLEAN; end

then the clause "agent has"

is an instance of the type
FUNCTION[CONTAINER, TUPLE [like item], BOOLEAN]

which conforms to FUNCTION[ANY, TUPLE, BOOLEAN]

When the agent is invoked, the object passed as the first argument is of
class CONTAINER.
--
Peter Horan School of Information Technology
peter@deakin.edu.au Deakin University
+61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

cheng-chang wu

IMHO the syntax for EiffelScript could be different from Eiffel, but it
should be easy for us to translate an EiffelScript automatically to
Eiffel with a translater program.

damien.guichardwanadoo.fr

I like the idea of a ligth-weight, interpreted, interactive Eiffel
implementation.
What i don't like too much is the idea of another Eiffel dialect.

So one property is essential: once the interactive session is terminated,
the interpreter should be able to output valid Eiffel classes. These Eiffel
classes should be as readable as hand-made Eiffel batch code and should be
compilable by popular compilers without any modification.

Also interactive commands of EiffelScript should be consensual before the
first implementation is made. Otherwise there will be several interpreters
with different command sets, making EiffelScript a non-portable language.

Finally, ECMA-standardization would be a huge plus.

- damien

xcriber51

My very humble opinion: Concentrating on creating an *interpreted* Eiffel
and an IDE that'll emulate the most desirable aspects of Visual Basic
(v5-6) will probably attract a higher number of potentials afficionados.

A carefully selected small set of the most usable libraries (with classes
like STRING, LIST, ARRAY, but not LIST_MULTIPLY_LINKED_IN_OBSCURE_WAYS),
with a few RAD component libraries thrown in, will be quite attractive to
those who stay away from Eiffel simply because they just can't bend their
mind around constructions like:

FUNCTION[CONTAINER, TUPLE [like item], BOOLEAN]

(No offense intended, Mr. Horan.)

If Eiffers could appreciate how much VB function set like "Left", "Mid",
and "Right" means to VB users (a lot), my idea could be put into
perspective.

[Side note: just to explain the above VB examples, these slice strings in
very convenient ways. If an EiffelScript String library could do these
like so:

s1, s2: STRING

greg c

Hello Damien,

I think you're making a convincing argument for EiffelScript fully
implementing the Eiffel syntax. Then see see which rules are
appropriate to relax or add, if any.

This brings me around to the work in Gobo, where there's a full
featured Eiffel parser that could be the basis for just such an
interpreter.

Greg C

greg c

Hello Ken,

I think you could accomplish the same sort of slicing with an infix
operator, provided the language was flexible enough to allow it. For
example, in class STRING you could have

infix "|slice| (range: TUPLE[INTEGER, INTEGER]) : STRING is ...

Then your examples couls look like this:

-- "Left"-most 5 chars
s1 := s2 |slice| [1, 5]

-- "Right"-most 5 chars
s1 := s2 |slice| [s2.count-5, s2.count]

-- "Right"-most x chars from the 5th
s1 := s2 |slice| [5 , s2.count]

-- "Mid" 2 chars starting from the 5th
s1 := s2 |slice| [5, 7]

What do you think?

Greg C

friedrich dominicus

"Greg C" <gregc@csd.net> writes:

Well all are disussing an EiffelScript assuming that it will get
Interpreted. However we have experiences with compiling in the
background (in C) and if an error occurs this will get marked. The
computers today are so extremly fast that piecewise compilation will
go undetekted. Of course one has to find a way to cope with incomplete
information but that has been done in other languages too.

E.g CormanLisp behaves like a interpreter but all the code is compiled
before use, AFAIK Mozart/Oz and OCaml do the same...

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

xcriber51

Hi Greg

Err... ummm... dunno. :-) Not that I don't appreciate your creative
coding. It just looks complicated for an average scripter's taste - not to
mention its verbosity. IMHO.

What I had in mind was more along the lines of Python.

Also, with indeces, we normally have *absolute* position slicing. But in
this example:

s1 := s2 @ s.count-5 ..

...we have a *relative* position: the 5th before the last.

Perhaps we could use the "|..|" operator I saw defined somewhere for
ranges in Eiffel, and add to it "{" and "}" to indicate relative
position:

inclusive exclusive
----------------------------------------
ABSOLUTE:
--------------------
index -5 to last a @ |-5..| a @ -5..
1st to index -5 a @ |..-5| a @ ..-5
index -5 to index 5 a @ |-5..5| a @ -5..5

etc.

RELATIVE:
--------------------
1st to 5th-before-last a @ |..{-5| a @ ..{-5
5th-after-1st to last a @ |+5}..| a @ +5}..

5th-after-1st to
5th-before-last a @ |+5}..{-5| a @ +5}..{-5

5th-before-last to last a @ |{-5..| a @ {-5..
1st to -5th-after-first a @ |..+5}| a @ ..+5}

etc.

MEANINGLESS:
--------------------
5th-before-first ? a @ -5}..
5th-after-last ? a @ ..{+5

etc.

(Note that in Eiffel arrays can have any index range. So "5th-after-1st"
does *not* mean "element with index 5" - it could well be 217.)

Given these, the above example can be coded like this:

s1 := s2 @ |{-5..|

In plain English, this says "the last 5 characters".

The only problem is lazy evaluation.

A simpler way of implementing this, though, is default parameters:

infix "|}..{|" (low := Current.first, high := Current.last : INTEGER) is
...

This would require a statement containing a declaration and initialization
simultaneously, which may be considered as a kind of side-effect. We know
that there are languages like Haskell which use type inference to
eliminate this. Maybe Eiffel could make an exception for this dumbest kind
of statement which is around simply because we have to say things like
"length is a numeric value, you moronic computer; it's not a character".
;-]


Cheers
Ken