Eiffel need some simplifications

I spend a week on the computer and came up with 12000 lines of code
implementing the fist part of the semantical anaysis of an eiffel
compiler. If was a lot of fun, especially because i could improve my
multithreading programming skills (the current part of the compiler is
multithreaded and scales up to 80% on a dual core system).

But after the initals i found that the Eiffel language - even ETL2 is
a much to complicated beast. And to be honest i do simply not
understand all parts of ETL3 and Ecma Eiffel definitely don't want to
implement them.

What would you think are the least important parts of Eiffel which can
be omitted in an implementation? At the moment i'm sure i will remove
this stupid "BIT N" idea. And simplification of the expanded<-
>reference would also make a lot easier, like SmartEiffel which
removed the automatic boxing. I think that ANY should only be a base
class for reference types (which includes tuples and agents). For
expanded types i'm even thinking about totally removing inheritance
for them. Can't see a real practical use case for this.

I said once that i would call this Eiffel inspirated language "Edison"
because he was a much more practical engineer.

A typo that makes a different: Instead of

> and Ecma Eiffel definitely don't want to implement them.

i mean

> and Ecma Eiffel and definitely don't want to implement them.

of course Ecma Eiffel (aka ISE's Eiffel) does implement them
and they don't want to give up because i'm sure they spend a lot
of time.

And because i'm replying now. Just want tell you why i still use
Eiffel - despite all the hate postings. There is just no other
language that has generic types and readability of the syntax like
Eiffel. Garbage Collection, easy readable Source, Generics and DbC
are for me the whole productivity benefits from Eiffel. I wouldn't
even bother to remove the mulitple inheritance. This does not add
to much and is just a nice to have.

In message <38acd5cb-391f-4e54-83c8-9ad71ca7c9e2@a9g2000prl.googlegroups.com>
scholz.lothar@gmail.com wrote:

> I spend a week on the computer and came up with 12000 lines of code
> implementing the fist part of the semantical anaysis of an eiffel
> compiler. If was a lot of fun, especially because i could improve my
> multithreading programming skills (the current part of the compiler is
> multithreaded and scales up to 80% on a dual core system).

I've been playing with something similar off and on for about ten years now.

I've a basic C++ implementation that compiles the Eiffel version to C, but
that compiler's output doesn't yet compile.

I've not bothered with multi-threading in the compiler because it tends to
produce nearly as many problems as it solves, in my experience, but then I
didn't have dual/multi-processor devices to make it worthwhile, either.
I've been sort-of planning to fork off the C compilation phase to separate
processes as the code is generated and then link them as a final step, but
it's not a big deal.

As far as the language is concerned, I've re-done the select clause, so
that instead of selecting individual features, the select clause specifies
which inheritance path will provide a particular parent type's interface.
The generated code has lots of duplication (the idea is to reduce that in an
optimisation phase), but means that you can do "iterating several actions",
not that anyone wants to, any more.

I'd like to add callbacks (instead of agents), which are declared like:

c: callback( item: T ): BOOLEAN

e.g. for_each_until( inspect: callback( item: T ): BOOLEAN ) is do ...

and defined like:

for_each_until( {
total := total + item.something
Result := should_be_last( item )
} )

i.e. a composite instruction in braces, with access to the current object
and, optionally, local variables. (If a callback uses local variables, it's
not storable and can only be used inside the routine it's passed to.)

A callback is not a class, and has one attribute: is_storable (calling one
looks like a normal feature call). (is_storable may only be false for
parameters to features.)

> But after the initals i found that the Eiffel language - even ETL2 is
> a much to complicated beast. And to be honest i do simply not
> understand all parts of ETL3 and Ecma Eiffel definitely don't want to
> implement them.

I must admit, I stopped looking in detail at the process when agents and
tuples came into the equation; they seemed to me to be more complicated than
necessary for the required functionality.

Conversions sound like a good idea, though.

> What would you think are the least important parts of Eiffel which can
> be omitted in an implementation? At the moment i'm sure i will remove
> this stupid "BIT N" idea. And simplification of the expanded<-
> >reference would also make a lot easier, like SmartEiffel which
> removed the automatic boxing. I think that ANY should only be a base
> class for reference types (which includes tuples and agents). For
> expanded types i'm even thinking about totally removing inheritance
> for them. Can't see a real practical use case for this.

I've kept BIT N, as the only storage mechanism (INTEGERs contain a BIT 32
attribute, for example).

> I said once that i would call this Eiffel inspirated language "Edison"
> because he was a much more practical engineer.

I'd be happy if something I built over a couple of years was still standing
strong after only a few minor modifications and two hundred years, or would
you say it was over-engineered?

Have fun!

Simon

--
ROLF - The RISC OS Look and Feel on Linux.
http://stoppers.drobe.co.uk
http://ro-lookandfeel.blogspot.com/

> I've not bothered with multi-threading in the compiler because it tends to
> produce nearly as many problems as it solves,

Depends how you implement it. It's pretty nice that a compiler can be
split
easily into independent passes that only have read access to results
of
previous passes.

>
> I'd like to add callbacks (instead of agents), which are declared like:
>

Looks like the block iterators in ruby. I like (and miss them too).
Programmatically
they seem to be very easy to implement. And i would definitely prefer
them over
inline agents.

> > I said once that i would call this Eiffel inspirated language "Edison"
> > because he was a much more practical engineer.
>
> I'd be happy if something I built over a couple of years was still standing
> strong after only a few minor modifications and two hundred years,


Well it's impressive but i use Edisons inventions many hours every day
but only
made two trips to Paris in the last 39 years, where i spend about 30
minutes on
top of the the tower - i think that Edison has much more importance
for real live.

And the same is with ETL3 when you read it you are really impressed by
the PDF file,
and then you go back and do your work in Java, C or whatever. Its
compiler creators
philosophie from the vaults of universities.

> or would you say it was over-engineered?

With the orginal requirement that the tower should be removed at the
end of
the exhibition i think i say: it was totally over-engineered.

<scholz.lothar@gmail.com> schreef in bericht
news:ae417c6a-5332-4f8b-8e8e-6ae896528a9b@t12g2000prg.googlegroups.com...

> Well it's impressive but i use Edisons inventions many hours every day
> but only
> made two trips to Paris in the last 39 years, where i spend about 30
> minutes on
> top of the the tower - i think that Edison has much more importance
> for real live.


Eiffel constructed more than just the Eiffel-tower: hundreds of bridges
(many of which are still in use today), department stores, observatories,
railway stations, observatories, aquaducts, locks and the innards of the
Statue of Liberty.

Eiffel was a very successful engineer, constructor, entrepreneur (the
Eiffel-company still exists today and was responsible for the steel
construction work in the largest viaduct in the world -- Le Grand Viaduc de
Millau, 2004) and scientist (the pioneer of aerodynamics).

Saying that Eiffel was not pragmatic illustrates a lack of research on your
part. Compared to Edison, Eiffel is the pragmatist IMHO.
..

In message <ae417c6a-5332-4f8b-8e8e-6ae896528a9b@t12g2000prg.googlegroups.com>
scholz.lothar@gmail.com wrote:

> > I'd like to add callbacks (instead of agents), which are declared like:
>
> Looks like the block iterators in ruby.

That's probably where I got the idea from, at least partly.

> I like (and miss them too).
> Programmatically they seem to be very easy to implement. And i would
> definitely prefer them over inline agents.

I prefer the way you don't have to worry about the order of parameters, and
that they are trivially type safe.


--
ROLF - The RISC OS Look and Feel on Linux.
http://stoppers.drobe.co.uk
http://ro-lookandfeel.blogspot.com/