tag:blogger.com,1999:blog-89727839115347540442024-03-08T08:38:23.266+01:00Liberty EiffelA pure object-oriented language sprouting from SmartEiffel trunk.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-8972783911534754044.post-51026464663732682362016-05-27T21:09:00.003+02:002016-05-27T21:12:28.306+02:00 LibertyEiffel Bell released<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.liberty-eiffel.org/images/liberty.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://www.liberty-eiffel.org/images/liberty.png" height="243" width="320" /></a></div>
I'm pleased to annouce that<br />
<br />
<h2>
LibertyEiffel 2016.05 (Bell) Release is out.</h2>
<br />
Liberty Eiffel project is the GNU Eiffel Compiler.<br />
<br />
It is a free-as-in-freedom Eiffel compiler started from SmartEiffel code base.<br />
<br />
Its goal is to retain the good solidity of SmartEiffel but not its rigidity.
Think of Liberty as SmartEiffel down from its ivory tower.<br />
<br />
This is the first release since LibertyEiffel acquired the status of "official" GNU Eiffel compiler.<br />
<br />
<h3>
What's new:</h3>
<ul>
<li><b>Inline agents that are real closures</b></li>
<li>generic creation</li>
<li>Several small changes to make the language more ECMA-like:</li>
<ul>
<li>keyword "is" at the beginning of a feature is now deprecated</li>
<li>keyword "indexing" renamed by "note"</li>
<li>keyword "creation" renamed into "create"</li>
<li>Added support for alias "[]" and alias "()" </li>
</ul>
<li>changed Environment Variable name from SmartEiffel to LibertyEiffel (anyhow, normally it should not be necessary to set this one)</li>
<li>configuration files now use XDG specification</li>
<li>new tool Mock</li>
<li>new tool wrapper_generator</li>
<li>removed linebreaks in compiler output many bugfixes</li>
<li>GC call at exit is optional</li>
<li>finder now finds all classes in the universe with the given name, not only the first one</li>
<li>constants are now visible in the eiffeldoc generated documentation</li>
<li>Wrappers:</li>
<ul>
<li>SQLite</li>
<li>ZMQ</li>
<li>removed the other wrappers until they're usable</li>
</ul>
</ul>
<h3>
Known bugs:</h3>
<ul>
<li>there is still an issue in both GC implementations (classical SEGC and BDW), if it shows up, it often yields a "Bad target type" runtime error.
for the full list see </li>
</ul>
We want to thank all who worked on this release, in particular Cyril Adrian who contributed much of the work.<br />
We are looking forward to a promising time until the Curtiss release, with 2 GSoC (Google Summer of Code) projects and many new active members in the community.<br />
<br />
But I don't want to waste your time with making you read my boring
words, so please go and check it out:
You can get the Bell release as<br />
<ul>
<li>Tarball:
<a class="moz-txt-link-freetext" href="http://download.savannah.gnu.org/releases/liberty-eiffel/bell.tar.gz">http://download.savannah.gnu.org/releases/liberty-eiffel/bell.tar.gz</a> </li>
<li>Debian/Ubuntu packages:
<a class="moz-txt-link-freetext" href="http://apt.liberty-eiffel.org/">http://apt.liberty-eiffel.org/</a> release main</li>
<li>Git repository:
git://git.savannah.gnu.org/liberty-eiffel.git </li>
</ul>
Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com2tag:blogger.com,1999:blog-8972783911534754044.post-89463477920931998952013-06-07T11:48:00.001+02:002013-06-07T11:48:11.583+02:00The importance of being GNUMore than a year has passed since the last article published on this blog.<br />
Yet we haven't been idle as we kept working on the code hosted on GitHub and discussing in the mailing list.<br />
I am now delighted and honoured to inform you that <span style="font-size: large;">Liberty Eiffel has been officially being accepted as a GNU project and that it has been blessed as the continuation of SmartEiffel. </span><br />
Please visit our <a href="https://savannah.gnu.org/projects/liberty-eiffel/">page on Savannah</a> the facilities where most of the GNU projects hosts their development.<br />
We also expect to release a first version of Liberty Eiffel this summer. Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com2tag:blogger.com,1999:blog-8972783911534754044.post-47114213771685411412012-04-02T20:26:00.000+02:002012-04-02T23:59:43.766+02:00Adding øMQ and LLVM...<blockquote class="tr_bq">
<i>Pick an Eiffel compiler, cut it in small pieces, add a cup of socket library - it will work as a concurrency framework - and a cup of a low level virtual machine. Blend it all in the mixer for several revisions until all the tests are passed then pour into a repository.</i></blockquote>
<div style="text-align: right;">
<blockquote class="tr_bq">
<i>Recipe from "Recipes for a successful evening with friends"</i> </blockquote>
</div>
<div style="text-align: justify;">
I would have liked to title this "LEC: Liberty/LLVM Eiffel Compiler".</div>
<div style="text-align: justify;">
Currently SmartEiffel is a monolithic piece of code in many senses.</div>
<div style="text-align: justify;">
It <i>was</i> considered fast, perhaps the fastest Eiffel compiler available. But it was under <b>precise conditions</b>, more specifically when building projects from the scratch on a single-core 32-bit processor.</div>
<div style="text-align: justify;">
Now that «<a href="http://en.wikipedia.org/wiki/The_Times_They_Are_a-Changin%27_%28song%29">the times they are a-changin'</a>», almost all those assumptions does not held anymore: </div>
<ul style="text-align: justify;">
<li>most of the time the programmer will rebuild a project after some small changes, </li>
<li>multi-core processors are the norm even in phones; widespread machines easily have 4-6-8 or even more cores. Even the <a href="http://www.ubuntu.com/certification/hardware/201103-7458">Ubuntu-certified</a> Asus Eee PC TM Seashell 1015PXB I bought <a href="http://www.marcopoloshop.it/vendita/computer/netbook/asus/asus-eee-pc-tm-seashell-1015pxb-ubuntu">last week at 199€</a> is seen by the kernel as a four-cores machine. </li>
<li>most of those processors are 64bit</li>
</ul>
Like ISE Eiffel also SmartEiffel compiles to C and then invokes a C compiler to actually produce the binaries and that phase has always been parallelized to put at work all the cores of the machine. I initially planned to start to parallelize the parsing phase then after a few days of study I discovered that SmartEiffel design gives me an easier start from the back-end. My idea is simple: replace the original C back-end with one that outputs LLVM bytecodes, one compilation unit per class. After the original code made all the parsing, deconding and syntactic analysis I just wrote (some comments and check instructions removed):<br />
<br />
<script type="syntaxhighlighter" class="brush: eiffel;"><![CDATA[
class LLVM_BYTECODE_EMITTER
inherit CODE_PRINTER undefine is_equal end
insert MULTIPROCESSING
creation {LLVM_GLOBALS} make
feature {SMART_EIFFEL}
compile is
local workers_count: INTEGER
do
if nb_errors = 0 then
get_started
smart_eiffel.customize_runtime
workers_count := (2*processors_count + 1);
("Creating #(1) workers processes over #(2) cores.%N" # &workers_count # &processors_count).print_on(std_error)
create workers.with_capacity(workers_count)
socket_path := "ipc:///tmp/liberty-llvm-compiler-"+process_id.out
workers_count.times(agent is do
workers.add_last(create {LLVM_WORKER}.communicating_over(socket_path))
end)
create messaging_context
socket := messaging_context.new_push_socket;
socket.bind(socket_path)
(1|..|ace.cluster_count).do_all (agent (an_index: INTEGER_32) is
local message: ZMQ_STRING_MESSAGE
do
create message.from_string("compile-cluster "| &an_index)
print("Posting message `"+message+"'%N")
socket.post(message)
end)
end
end
socket_path: ABSTRACT_STRING
messaging_context: ZMQ_CONTEXT
socket: ZMQ_PUSH_SOCKET
workers: FAST_ARRAY[LLVM_WORKER]
]]></script>
Obviously all the work is done by a LLVM_WORKER which runs as a fork of the main compiler process; that way it has all the data structure ready in its address space; each worker starts listening to socket path for commands:<br />
<br />
<pre class="brush: eiffel">
class LLVM_WORKER
inherit
POSIX_PROCESS
CLASS_TEXT_VISITOR -- To access CLASS_TEXT.feature_dictionary
insert EXCEPTIONS GLOBALS
creation communicating_over
feature {} -- Creation
communicating_over (an_endpoint: ABSTRACT_STRING) is
-- Start a new worker process that will wait for commands over a øMQ socket connected to `an_endpoint'
require an_endpoint/=Void
do
endpoint := an_endpoint
start -- this will fork a new process and invoke `run'
end
feature -- Commands
run is
local command: ZMQ_STRING_MESSAGE
do
pid := process_id;
("Worker #(1) listening on '#(2)'%N" # & pid # endpoint).print_on(std_output)
create context
socket := context.new_pull_socket
from socket.connect(endpoint)
until socket.is_unsuccessful loop
create command
socket.wait_for(command)
if socket.is_successful then
process(command)
else throw(socket.zmq_exception)
end
end
("Worker #(1) ending%N" # & pid ).print_on(std_error)
end
feature {} -- Implementation
process (a_command: ZMQ_STRING_MESSAGE) is
require a_command/=Void
local words: COLLECTION[STRING]; index: INTEGER; cluster: CLUSTER
do
words := a_command.split
if words/=Void and then words.count=2 and then
words.first.is_equal("compile-cluster") and then
words.last.is_integer then
index := words.last.to_integer
cluster := ace.cluster_at(index)
("Worker process #(1) starts compiling cluster '#(2)' (##(3))%N" # &pid # cluster.name # &index).print_on(std_output)
cluster.for_all(agent visit_class_text)
end
("Cluster '#(2)' (##(3)) compiled by worker #(1)%N" # &pid # cluster.name # &index).print_on(std_output)
end
.....
</pre>
<br />
<br />
<br />
LLVM_WORKER does not yet use the PROCESS_POSIX provided by SmartEiffel: I wanted the quickest'n'dirtiest way to use <a href="http://pubs.opengroup.org/onlinepubs/009604599/functions/fork.html">fork()</a> as this is primarily a test to øMQ bindings . After all the <a href="http://en.wikipedia.org/wiki/Quick-and-dirty">quick'n'dirty approach</a> sometimes proves to be <a href="http://en.wikipedia.org/wiki/Ms-dos">exceptionally successful</a>... <br />
People coming from loosely typed languages may argue that I could have written the process command like this:<br />
<br />
<pre class="brush: eiffel">
process (a_command: ZMQ_STRING_MESSAGE) is
local words: COLLECTION[STRING]; index: INTEGER; cluster: CLUSTER
do
if a_command.split.first.is_equal("compile-cluster") then
index := a_command.split.last.to_integer
cluster := ace.cluster_at(index)
("Worker process #(1) starts compiling cluster '#(2)'
(##(3))%N" # &pid # cluster.name # &index).print_on(std_output)
cluster.for_all(agent visit_class_text)
end
("Cluster '#(2)' (##(3)) compiled by worker #(1)%N" # &pid # cluster.name # &index).print_on(std_output)
end
</pre>
<br />
While this may be true now, I ideally want this to scale at least to a local-network scale - for the messaging part it's just a matter of adding <i>socket.bind("tcp://localhost:9999")</i> after the first bind - so assuming anything about a received message is plainly wrong; we may receive garbage. And when you <a href="http://en.wikipedia.org/wiki/Garbage_in,_garbage_out">process garbage all you get is garbage</a>.<br />
Nasty reader or innocent C++ programmers may have noticed that I haven't used threads, so I couldn't have used the <a href="http://api.zeromq.org/2-1:zmq-inproc">real zero-copy in-process messaging</a>. Any Posix programmer worth his/her salt <a href="http://www.catb.org/%7Eesr/writings/taoup/html/ch07s03.html#id2923889">knows</a> that <a href="https://www.google.com/search?client=ubuntu&channel=fs&q=threads+are+evil&ie=utf-8&oe=utf-8">threads are evil</a>... Jokes apart I would really like to have real zero-copy IPC; yet our current compiler is not thread-safe. I think I should rather implement <a href="http://librelist.com/browser//libertyeiffel/2011/10/21/autorelative-references-and-liberty-parser/">auto-relative references</a> and share a memory region between processes. I actually had a somehow working prototype of such a class, modelled after <a href="http://en.wikipedia.org/wiki/Pointer_%28computer_programming%29#Autorelative_pointer">autorelative pointers</a>, but they are so brittle to use that I was ashamed to commit it anywhere...Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com1tag:blogger.com,1999:blog-8972783911534754044.post-36320076743841204902012-03-20T13:29:00.002+01:002012-03-20T13:29:56.437+01:00Successful languages have bearded designers<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Bertrand_Meyer.jpg/220px-Bertrand_Meyer.jpg" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Bertrand_Meyer.jpg/220px-Bertrand_Meyer.jpg" width="213" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://en.wikipedia.org/wiki/Bertrand_Meyer">Bertrand Meyer</a> (source Wikipedia)</td></tr>
</tbody></table>
<b><i>Dislaimer: this post is a joke.</i></b><br />
I have been an avid <a href="http://www.slashdot.org/">Slashdot</a> reader since I got on the net when I started university. Yesterday I was naively reading <a href="http://developers.slashdot.org/story/12/03/16/0240232/why-new-programming-languages-succeed-or-fail">"Why new programming languages succeed or fail" </a>when I stumbled upon the first comment: «Everyone knows it's the <a href="http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx" rel="nofollow" title="microsoft.co.il">Amount of Facial hair</a>» which lead me to this <a href="http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html">"ancient" blog entry</a>.<br />
Please read that entry blog, from which I'm taking many of the following photos.<br />
See some designers of successful, widespread languages: C, Basic (entire generations started with it), C++, Python, Ruby, Java, PHP.<br />
<img alt="image" border="0" height="170" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_85f95d7f-bf52-41a4-801b-241c9f4e2bbc.png" title="image" width="159" /> <img alt="image" border="0" height="171" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_b782d4cf-2464-4931-a714-db52ed464839.png" title="image" width="153" /> <img alt="image" border="0" height="168" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_b55842b4-c138-423a-81cf-bd522d6c1435.png" title="image" width="148" /><img alt="image" border="0" height="202" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_0198c9bc-099f-48d1-9d72-03a669c648f4.png" title="image" width="174" /><img alt="image" border="0" height="201" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_b7c599f6-8ebb-4861-93f8-a62139a05e46.png" title="image" width="163" />
<br />
<img alt="image" border="0" height="153" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_b11dbfe3-2154-44b8-811d-e27d0051e604.png" title="image" width="146" /> <img alt="image" border="0" height="150" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_884a18d3-4126-415b-baed-0e4abf083121.png" title="image" width="138" /><img alt="image" border="0" height="152" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_baf48399-d08c-4eba-8499-bf8351a82120.png" title="image" width="133" /> <img alt="image" border="0" height="193" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_275220c1-4d7a-4095-aa16-8a6c4e2afa08.png" title="image" width="145" />
<br />
<i>The student will usefully discover the name of each designer and his language.</i><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Bertrand_Meyer.jpg/220px-Bertrand_Meyer.jpg" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
Now let's see creators of famous yet-not-so-used or not-so-used-anymore programming languages or recent photos of the creators of not-so-fashionable-as-they-were languages that are losing ground: Fortran, Ada and Simula and C++ (in recent years)<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_fe2f9f08-7a12-4155-983d-b1d6b67f2bc5.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><br /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_fe2f9f08-7a12-4155-983d-b1d6b67f2bc5.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_fe2f9f08-7a12-4155-983d-b1d6b67f2bc5.png" /></a></div>
<img alt="image" border="0" height="146" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_8cc483cb-5393-43af-b7e6-17ed3a2fa1aa.png" title="image" width="153" /> <img alt="image" border="0" height="147" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_9c29ed36-591a-44a5-b737-8631bcc8c7b2.png" title="image" width="106" /><img alt="image" border="0" height="147" src="http://blogs.microsoft.co.il/blogs/tamir/WindowsLiveWriter/Computerlanguagesandfacialhairtaketwo_11FB7/image_c2615e7a-ad0b-4df5-9d0b-da94859b2f38.png" title="image" width="112" /><br />
<br />
Now some photos of Bertrand Meyer.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.inf.ethz.ch/news/focus/edu_focus/meyer/meyer_large?hires" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.inf.ethz.ch/news/focus/edu_focus/meyer/meyer_large?hires" /></a></div>
I'm pretty sure you note a striking similarity with one of the previous groups.<br />
Oh, have you really seen it?<br />
So please, Bertrand grew some beard or put a properly-bearded computer scientist in charge of Eiffel's future.<br />
<br />
To end this blog entry with style here's a virtual exchange of spicy quotes:<br />
<i>«There are only two things wrong with C++: The initial concept</i> <i>and the implementation.</i>» and «<i>C++ is the only current language making COBOL look good.</i>» – <a href="http://se.ethz.ch/%7Emeyer/" target="_blank">Bertrand Meyer</a><br />
«<i>There are only two kinds of languages: the ones people complain about and the ones nobody uses.»</i> <a href="http://www2.research.att.com/%7Ebs/" target="_blank">Bjarne Stroustrup</a> <br />
<br />
Long life and prosper, dear Meyer! Thanks for Eiffel and OOSC!<br />
<br />
<i>Don't cross commands and queries: it would be <b>bad</b>.</i> Me, know, paraphrasing Egon Spengler<br />
<br />Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-49883793224276096592012-02-22T13:47:00.000+01:002012-02-22T13:47:37.770+01:00Unicode source code<script src="http://www.monodes.com/didattica/scripts/ASCIIMathML.js" type="text/javascript">
</script>
As Frank Salter wrote in a <a href="http://liberty-eiffel.blogspot.com/2011/12/case-sensitivity.html?showComment=1329898997591#c4192779049669984590">recent comment</a> on case-sensitivity, most scientific fields requires the usage of several dozens of symbols and alphabets that go beyond the latin symbols usable in plain old <a href="http://en.wikipedia.org/wiki/ASCII">ASCII</a>, which is a standard almost half-century old (1968).<br />
For example my field - civil and structural engineering - uses almost the entire Greek alphabets in the <a href="http://eurocodes.jrc.ec.europa.eu/">Eurocodes .</a><span id="bc_0_12b+seedyEOD" kind="d"> </span><br />
<span id="bc_0_12b+seedyEOD" kind="d">There is a widespread need to go beyond case-sensitivity and ASCII.</span><br />
<span id="bc_0_12b+seedyEOD" kind="d">I already <a href="https://github.com/LibertyEiffel/Liberty/wiki/Liberty-plan">expressed at the beginning of our efforts</a> the choice to have Unicode source code as a design choice; shame on me for not having been able to find the time necessary to implement what it is clear in our mind.<br />We shall - at least - write source code in Unicode and lay down some style guide for its usage. </span><br />
<span id="bc_0_12b+seedyEOD" kind="d">First of all we </span>needs more liberal infix and prefix operators. By “liberal” I mean allowing for example Unicode math codes, like <a href="http://www.unicode.org/charts/#symbols">many mathematical symbols</a> the Unicode standard defines.<br />
Unicode libraries available as “logicielle libre” (free-as-in-freedom software) - for example <a href="http://library.gnome.org/devel/glib/stable/">Glib</a> - allows to know it a given character is a symbol (i.e. <br />
<a href="http://library.gnome.org/devel/glib/stable/glib-Unicode-Manipulation.html#g-unichar-type">g_unichar_type</a> (a_char) = G_UNICODE_MATH_SYMBOL; see also <a href="http://www.unicode.org/charts/PDF/U2200.pdf">this table</a> ).<br />
Of course I wasn’t meaning to allow code like <i>«class <span class="caps">PERSON</span>… feature infix "open"»</i>, otherwise we will drive the parser crazy ending up with something Perl-like.<br />
This way we would get rid of usual rant of people coming from languages with overloading (i.e. C++, Java) that says:<br />
“why
do I have to write <br />
my_matrix.multiply (another_matrix).scalar_vector(a_vector) <br />
instead of
(my_matrix*another_matrix)*a_vector?”<br />
Because the mathematician
would have rather written <br />
"(my_matrix × another_matrix) ^ a_vector"<br />
scalar and matrix multiplications are <b>not</b> arithmentic multiplication and in fact they actually have <b>different</b> symbols in "real" math.<br />
The infix-prefix name rule could be therefore expressed using <a href="http://library.gnome.org/devel/glib/stable/glib-Unicode-Manipulation.html">Unicode classification</a> of characters.<br />
<span id="bc_0_12b+seedyEOD" kind="d">Actually I would like to write Latex-like code
`y := { -b +- sqrt { b^2 - 4 a c} } / {2a} ` or ` </span>`A_x := int_0^1 f_m(x)dx ` in a way similar to what <a href="http://www1.chapman.edu/%7Ejipsen/mathml/asciimath.html">ASCIIMathMl</a> does for HTML pages. But this is currently a dream.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com3tag:blogger.com,1999:blog-8972783911534754044.post-13825058467874078502012-02-22T10:26:00.003+01:002012-02-22T10:26:40.551+01:00JavaScript backend?Did anyone saw me writing about an Eiffel to Javascript compiler?<br />
Well indeed I was pondering about using Liberty as a language for the Web 2.0, AJAX, anything having a JavaScript interpreter.<br />
Is there any recent appliance that does not have a JavaScript interpreter built-in these days? <br />
We cannot afford being cut-out of this!<br />
We need a JavaScript backend, so that Liberty actually becomes an Eiffel-to-Javascript compiler!<br />
Yet we have to deal with resource limitations, most notably a chronic lack of time.<br />
Here enters <a href="https://github.com/kripken/emscripten/wiki">Emscripten, the LLVM-to-JavaScript</a> compiler.<br />
As written elsewhere in this blog we were already targetting LLVM, so Emscripten is really a<span class="short_text" id="result_box" lang="en"><span class="hps"> blessing</span> <span class="hps">from heaven above: it takes compiles from LLVM bytecode to JavaScript. <b>Bingo</b>!</span></span><br />
<span class="short_text" id="result_box" lang="en"><span class="hps">Compiling to LLVM will automagically make Liberty an Eiffel-to-Javascript compiler.</span></span><br />
You may get the source code https://github.com/kripken/emscripten/wiki and read about it from http://syntensity.blogspot.com/2011/04/emscripten-10.html (in http://syntensity.blogspot.com/ ), a blog continued in http://mozakai.blogspot.com/<br />
<br />
Actually there are some <a href="https://github.com/kripken/emscripten/wiki/FAQ">enjoyable considerations</a> about how such a tool shall be called:<br />
<ul>
<li>
<b>Q.</b> Is this really a compiler? Isn't it better described as a translator?<br />
<b>A.</b> Well, a <i>compiler</i> is usually defined as a
program that transforms source code written in one programming language
into another, which is what Emscripten does. A <i>translator</i> is a
more specific term that is usually used for compilation between
high-level languages, which isn't exactly applicable. On the other hand a
<i>decompiler</i> is something that translates a low-level language
to a higher-level one, so that might technically be a valid description,
but it sounds odd since we aren't going back to the original language
we compiled from (C/C++, most likely) but into something else
(JavaScript).<br />
</li>
</ul>Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com1tag:blogger.com,1999:blog-8972783911534754044.post-33947101645078281492012-01-20T18:00:00.000+01:002012-04-02T16:20:39.893+02:00I'm almost a literate program, please format me with a proportional fontMany long-time Eiffel programmers and experts always knew it: Eiffel should be formatted with a proportional font. Looking for the original reasoning of Bertrand Meyer about it I found this link in Wikipedia:<br />
<blockquote class="tr_bq">
<a href="http://en.wikipedia.org/wiki/User:Doug_Pardee/Working#Lexical_and_syntax" target="_blank">Proportional font: Unlike most programming languages, Eiffel is not normally displayed in a monospaced typeface. The recommended display style is to use a proportional typeface. Keywords are displayed in bold, user-defined identifiers and constants are displayed in italics. Standard upright (roman) style is used for comments, operators, and punctuation marks. This is essentially the same concept as syntax coloring which has become very popular in IDEs for many languages, except that Eiffel's recommendations also extend to print media.</a></blockquote>
I tried to follow these rules to write <a href="https://github.com/tybor/SyntaxHighlighter/blob/master/styles/shCoreEiffel.css" target="_blank">a little style</a> for SyntaxHighlighter (I'll put them online as soon as possible to properly format our sources here). I would like to know your opinion about it; also please feel free to partecipate!<br />
My personal opinion is that this stylistical rule is deeply yet unconsciously linked to <a href="http://en.wikipedia.org/wiki/Literate_programming" target="_blank">Literate Programming </a>since valid Eiffel source code often resemble a natural language like English, at least much more than C, C++, Python, Java and so on.<br />
Actually an Eiffel program is not "<i>written as an uninterrupted exposition of logic in an <a href="http://en.wikipedia.org/wiki/Natural_language" title="Natural language">ordinary human language"</a>,</i> yet the source code of an Eiffel class, with its emphasis on documentation, the preconditions, the postconditions and its invariant strikingly resemble an explanation in a <a href="http://en.wikipedia.org/wiki/Natural_language" title="Natural language">natural language</a>,
such as English, of the design of the type it represent.<br />
Eiffel source code looks so much like the <a href="http://en.wikipedia.org/wiki/Pseudocode" title="Pseudocode">pseudocode</a> typically used in teaching <a href="http://en.wikipedia.org/wiki/Computer_science" title="Computer science">computer science</a> to explain <a href="http://en.wikipedia.org/wiki/Algorithm" title="Algorithm">algorithms</a> that when Bertrand Meyer wrote <a href="http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction" target="_blank">Object Oriented Software Construction</a> he actually used Eiffel from page one without telling it to his reader, pretending it was pseudocode; in the pages of the book it justified each and every design choice of his design then in the epilogue he actually revealed that the pseudo-code he used wasn't actually pseudo-code at all but real, effective Eiffel code.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-24620409745472005102012-01-20T15:48:00.002+01:002012-01-20T15:48:26.171+01:00Eiffel saw from ADA programmersSome weeks ago I stumbled upon this entry of Ada FAQ: <a href="http://www.adahome.com/FAQ/programming.html#elegance" target="_blank">Some Isn't Ada less "elegant" than Eiffel?</a> (also readable as a thread in Lisaac mailing list).<br />
Now that I think I finally found an actual way to re-implement <a href="https://github.com/tybor/Liberty/tree/deep-twin-in-eiffel">deep_twin and is_deep_equal with a pure Eiffel, reentrant, thread safe design</a> (<small>beware that I still have to test it extensively before saying it's good even to be labelled "alpha-quality"<small>) I must answer to those issues, since most of them don't hold anymore.
<br />
<i>In particular, although I like the assertion
stuff in Eiffel, I think the language has a number of "inelegant"
aspects. For example:
</i><br />
<ol>
<li><i>exception handlers only at the top level of a routine,
with the only way to "handle" an exception being by retrying
the whole routine.
</i><br>
<p>As far as I remember this have been a deliberate design choice of Meyer. The rationale behind this is that if a feature, either a command or a query is longer than a 20-30 lines it becomes far more difficoult to understand; it becomes easier to understand for the reader if it is broken in several independant pieces. Therefore the need for intra-feature exceptions fades away: when you need to handle an exception in a specific section of a feature this is the distinguished mark that <b>that</b> piece could be made an independant feature. If you don't want to expose it to your clients just hide it private behind a <b>"feature {} -- Implementation of foo feature"</b>.</p>
</li>
<li><i>No way to return from a routine in the middle.
This makes it a pain in the neck to search through
a list for something in a loop, and then return immediately
when you find what you want. (I have never found the
addition of extra boolean control variable a help to
the understanding of an algorithm.)
</i><p>This is actually something I found myself longing to sometimes.</p>
</li>
<li><i>Namespace control handled by a separate sublanguage, and
no real higher level concept of "module" or "subsystem."
</i><p></p>
</li>
<li><i>An obscure notation like "!!" being used for an important
and frequent operation (construction).
</i><p>This was a good point. In fact the "!!" notation have been (somehow) deprecated; while it has never been phased out by the language itself I have never read it in code writter in this century. Nowadays all Eiffel programmers worth their salt always use one of the following syntaxes: <ul>
<li><b>"foo: LINKED_LIST[STRING] .... create foo"</b> used when the created object be an actual instance as declared, using "default_create" feature to initialize it;</li>
<li><b>"foo: SET[STRING] .... create foo.make_with_capacity(120)"</b>, the most widespread usage where you tell the compiler which creation feature shall be used to initialize the newly created object</li>
<li><b>"foo: COLLECTION[STRING] .... create {TWO_WAY_LINKED_STRING} foo"</b> used when you want to create an object of a subtype of the declared type, either because the declared type is deferred (a.k.a. virtual for you people coming from C++/Java world) or because you want to use a subclass that better fits the task.</li>
<li>manifest notation like <b>"foo := {TWO_WAY_LINKED_LIST[STRING] << "Some", "strings", "in", "a collection">> }"</b> or <b>"{RING_ARRAY[CHARACTER] 1, << "These", "strings", "live in", "a collection", "which is actually a RING_ARRAY">> }"</b>; you may read further examples in <a href="https://github.com/LibertyEiffel/Liberty/blob/master/tutorial/manifest_notation.e">MANIFEST_NOTATION tutorial</a></li>
<li><b>in-place creation, in the middle of the arguments of a feature "produce_and_ship_with(12, "Chocolate cakes", create {CAR}.with_plate_and_label(clients_car_plate, "The car of client "|client_name)"</b>; by the way this line show the usage of one of the <b>three concatenation operators</b> we introduced in strings. I should really write a blog entry about these... (they are infix "+", infix "|" and infix "&", see <a href="https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/string/abstract_string.e">ABSTRACT_STRING</a> for a brief description.</li>
</ul>I thing it may be useful to make the compiler emit a warning when such a syntax is still used. Perhaps we may be daring enought to just drop it, allowing to use the exclamation point for free operators: it is a good thing that people learning Eiffel shall not be exposed to that "archeological" syntax.</p>
</li>
<li><i>No way to conveniently "use" another abstraction without
inheriting from it.</i><p> This is exactly what both Eiffel standards (ECMA and GNU/Smart) implemented in this decade: <a href="http://liberty-eiffel.blogspot.com/2011/12/insert-or-non-conforming-inheritance.html">non-conforming inheritance</a>; now when you need to use another abstraction without being a type conforming to it you "<b>insert</b>" it.</p>
</li>
<li><i>No strong distinctions between integer types used for array indexing.
</i><p>I think this is a "non issue" at all, since array access does not have any special status at all in Eiffel; actually you may just define your arrays to accept different types on indexes. I suspect that this </p>
</li>
<li><i>Using the same operator ":=" for both (aliasing) pointer assignment, and for value assignment, depending on whether the type is "expanded." (Simula's solution was far preferable, IMHO).
</i><p>This were actually confusing some years ago since you may decide in the definition of each feature whenever an argument shall be expanded or not. Now in GNU/SmartEiffel this is notnot confusing in my humble opinion in since the difference between assignment by reference or by value (expanded values) is estabilished class per class; when you need to have a reference to an expanded class you just use <a href="https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/kernel/reference.e"><b>REFERENCE[FOO]</b></a> with <b>FOO</b> being an expanded class. By the way you may read the definition of<a href="https://github.com/LibertyEiffel/Liberty/blob/master/src/lib/kernel/reference.e"><b>REFERENCE</b></a> discovering that it is a simple, plain and normal generic class that does <b>not</b> require any special support from the compiler at all. I think that deciding once and forever if a class is either a reference or an expanded value makes code far easier to understand for the reader, easier for the designer to conceive and easier for the compiler to parse and optimize.</p>
<br />
<h4>
<i> And most critically: </i></h4>
</li>
<li><i>No separate interface for an abstraction.
You can view a interface by running a tool,
but this misses completely the importance of having
a physical module that represents the interface, and
acts as a contract between the specifier or user of
an abstraction and its implementor.
In Eiffel, one might not even be truly aware when one is
changing the interface to an abstraction, because there
is no particular physical separation between interface
and implementation.
</i></li><p>Again this is a deliberate and willingful consequence of an explicit design choice; it has been extensively explained by Meyer in Object Oriented Software Construction; this would be a nice topic for a foreseeable blog entry as it's a sin not to explain it to people on the net; I wish Meyer published OOSC directly on the net as I'm sure that the profits for the advertizing that he would put will more than compensate his lost revenues.</p>
</ol>Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-63022222048048272692012-01-19T11:04:00.000+01:002012-01-19T11:04:09.426+01:00pwdmgrAs a change out of the interpreter I wrote a minimal password manager, using Liberty libraries.<br />
<br />
As a result I fixed a few things in those libraries :-)<br />
<br />
Please have a look at <a href="https://github.com/cadrian/pwd">https://github.com/cadrian/pwd</a><br />
<br />
Enjoy!Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-72902870543032225752012-01-09T14:58:00.002+01:002012-01-09T14:58:39.167+01:00Agent calls passing a tuple entityStarting from <a href="https://github.com/LibertyEiffel/Liberty/commit/1083bfb74cad52813278e1d451d6089efc68ec46">https://github.com/LibertyEiffel/Liberty/commit/1083bfb74cad52813278e1d451d6089efc68ec46</a> a long-standing limitation of SmartEiffel is removed.<br />
<br />
SmartEiffel used to require a manifest tuple for both <i>call</i> and <i>item</i> agent features. The rationale is to force the user to ponder on the number of arguments; and since no actual tuple was created, memory was not wasted.<br />
The drawback is that one had to manually "decapsulate" a provided tuple using an explicit (and ugly) <span style="font-family: 'Courier New', Courier, monospace;">[a_tuple.item_1, a_tuple.item_2]</span><br />
<br />
Now one may call an agent using a variable that contains a tuple.<br />
<br />
The only condition is that the entity is correctly statically typed, because the compiler generates calls to the <i>item_i</i> features using the static type. Thus the rationale is still useful (the user needs to know the actual tuple type); but the code is far less ugly. Also remember that the tuple is actually created!<br />
<br />
Enjoy :-)Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com1tag:blogger.com,1999:blog-8972783911534754044.post-6260970638253702352011-12-22T00:30:00.000+01:002011-12-22T22:10:37.279+01:00They call me GNU-Eiffel<br />
We are continuing the development of<a href="http://smarteiffel.loria.fr/wiki/en/index.php/Introduction#Eiffel.2C_the_spirit_of_Eiffel_or_the_Eiffel_method.3F"> the academic project that acquired in 1998 the status of "Gnu Eiffel compiler"</a>. As I wrote in <a href="http://liberty-eiffel.blogspot.com/2009/09/smarteiffel-dead-of-alive.html">the beginning article</a> of this blog Dominique Colnet is focusing his academic interests on other aspects of Information Technology. Cyril - a member of the former core team of developers - and me still believe that this language has still to a useful role as a free-as-in-freedom project.<br />
We thought to use the existing compiler - SmartEiffel - to bootstrap another one - LibertyEiffel, but we soon realized that it may be evolved into something more modular, more scalable. The only prerequisite to the latter approach is an extensive knowledge of the inner design of the compiler: Cyril has done a good work cleaning it up and know it seems easier to grasp it all. So Liberty design ended up becoming part of our improvements toSmartEiffel.<br />
SmartEiffel also does not implement ECMA-Eiffel, trying to be follow the original design and spirit of the language that wanted to be simple yet powerful. ECMA-Eiffel is quite a different language and more complex: the original definition of Eiffel was under 50 pages, current ECMA is quite bigger.<br />
All those considerations are pushing me to call the language and the tools implementing it GNU-Eiffel.<br />
<br />Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com4tag:blogger.com,1999:blog-8972783911534754044.post-34847037658612137252011-12-21T14:54:00.002+01:002011-12-22T16:11:27.737+01:00Insert or non-conforming inheritanceAll programming languages have been weak spots that are criticized, Eiffel is no exception.<br />
One of the most sound critique to the original Eiffel is that inheritance was the only modularity mechanism available.<br />
In fact it is a fundamental part of the object oriented approach to programming.<br />
Yet in its pristine, original form inheritance it does not allow to implement shared constant or commodity features (either queries or commands) in a clean way.<br />
For example to implement dictionaries, hash tables and many cryptografic algorithms there's the need to have a handy list of prime numbers or a function that tells the first prime higher than a given integer. Let's say we put all these informations into a PRIMES_LIST class; in pristine Eiffel we would have written:<br />
<pre class="brush: eiffel">class DICTIONARY [A_VALUE, A_KEY]
inherit PRIMES_LIST export all {NONE} end
....
end -- class DICTIONARY
</pre>
<br />
In this (oversimplified) example a DICTIONARY actually is a list of primes, but a really strange one, since with "export all {NONE}" we told the compiler that all the features originally defined in PRIMES_LIST cannot be invoked, queried or used by any code handling a DICTIONARY.<br />
Beside looking a palese breach in the OO architecture it actually answered in the wrong way to a rightful need: sharing some code or data between different parts of the programs; the pecualiar aspect is that all that code or data is not linked or bounded to a particular type at all, but they are quite generic.<br />
There's the need to have all the features - queries, commands constants and attributes - of another class without being a subtype of that class; we need what is known as non-conforming inheritance or feature insertion.<br />
That's exactly the role of "insert": to have all the feature on another class without being conforming to that class.<br />
In fact with the previous example you may write:
<br />
<pre class="brush: eiffel">feature strange is
local primes_lists: LINKED_LIST[PRIMES_LIST]
do
create primes_list
primes_list.append ( {PRIMES_LIST} )
primes_list.append ( {DICTIONARY[STRING; INTEGER]} )
primes_list.append ( {CRYPTO_USING_PRIMES} )
...
end
</pre>
What a strange collection: a list compraising a list of primes, a dictionary containing strings and a cryptografic stream! The designer of a program may actually do not want to have such objects. <br />
When we do want to share some definitions or a list of primes like in this example we may have inserted the features of PRIMES_LIST, like this:<br />
<pre class="brush: eiffel">class DICTIONARY [A_VALUE, A_KEY]
insert PRIMES_LIST
....
end -- class DICTIONARY
</pre>
Actually it is customary to declare those auxiliary classes deferred, in order to forbid direct usage of that class itself.<br />
ECMA Eiffel has the same non-conforming mechanism, but its syntax is "inherit {NONE} PRIMES_LIST", meaning inherit conforming to no class. While this is correct it seems to allow to write "inherit {MY_CLASS} PRIMES_LIST", bringing confusion together with a useful, simple mechanism. I have discussed the rationale behind this some time before SmartEiffel team decided not to implement ECMA, I'll try to dig it out.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com2tag:blogger.com,1999:blog-8972783911534754044.post-50962058752231347192011-12-21T14:54:00.001+01:002011-12-22T01:49:57.032+01:00Case sensitivityEiffel was born as a case-insensitive language. So it would allow to write this code:<br />
<blockquote class="tr_bq">
cLaSS nice_AnD_READable<br />
INHERIT foo<br />
FEAture BOOO is oD pRiNt("Boo!") end<br />
eND</blockquote>
And using it elsewhere like:<br />
<blockquote class="tr_bq">
local MY_obj: NICE_and_readABLE<br />
do<br />
CREate my_obj<br />
my_OBj.booo<br />
....</blockquote>
<div>
Nice, isn't it?</div>
<div>
Now such code quite obviously will give an headache to people reading it and it will make life harder to all tools. While the latter "would not count" if those requirements will make code easier to read it is quite the opposite: making the language case-insensitive does make the language less readable.<br />
The idea was - if I recall correctly OOSC - to turn casual case-errors into warnings allowing the developer to concentrate on the logic instead of the case of the identifiers.<br />
Actually style counts, so rightfully the definition of the language comes with a very precise style guide:<br />
<br />
<ol>
<li>all classes names shall be uppercase</li>
<li>all constants shall be lowercase with the first letter uppercase</li>
<li>all other identifiers and language reserved words shall be written lowercase</li>
</ol>
GNU SmartEiffel "only" makes the style rules mandatory so that the code above will read:<br />
<pre class="brush: eiffel">
class NICE_AND_READABLE
inherit FOO
feature boo is do print("Boo!") end
end
...
local my_obj: NICE_AND_READABLE
do
create my_obj
my_obj.boo
...
</pre>
This may look quite strict and at first it feels so; my experience tells me that this discipline is actually good for the developer writing the code, those reading the code allowing for a smoother reading.<br />
<br /></div>Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com16tag:blogger.com,1999:blog-8972783911534754044.post-10379384255621502692011-12-20T11:49:00.001+01:002011-12-23T09:54:51.253+01:00Highlighting Eiffel syntax in Blogger (DONE!)Syntax highlighting of programming languages seems to require a little tweaking in Blogger. <a href="http://alexgorbatchev.com/SyntaxHighlighter/manual/brushes/">SyntaxHighlighter from Alex Gorbatchev</a> is a most widespread syntax highlighter used in Blogger but it doesn't support Eiffel out-of-the-box.<br />
Luckily it's all JavaScript and supports Delphi and Pascal and<a href="https://github.com/alexgorbatchev/SyntaxHighlighter"> it's hosted on github</a>, so I <a href="https://github.com/tybor/SyntaxHighlighter">forked it</a> (with git it's fast, light and easy to merge the changes in the main trunk) to add (Smart)Eiffel support, thanks to the <a href="http://alexgorbatchev.com/SyntaxHighlighter/manual/brushes/custom.html">nice guide</a> the main developer <span id="goog_387682033"></span>provided<span id="goog_387682034"></span>.<br />
<br />
2011-12-22 update: I tried a really quick hack and I got a <a href="https://github.com/tybor/SyntaxHighlighter/blob/master/scripts/shBrushEiffel.js">preliminary working version</a>. To use it in Blogger I had to switch to a "simple" theme, one whose sources can be hacked, adding in the head the following code:<br />
<pre class="brush: html"><link href="http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css" rel="stylesheet" type="text/css"></link>
<script src="http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js" type="text/javascript">
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shAutoloader.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXML.js' type='text/javascript'/>
<script src='http://www.monodes.com/scripts/shBrushEiffel.js' type='text/javascript'/>
<script language='javascript'>
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/2.1.364/scripts/clipboard.swf';
SyntaxHighlighter.all();
</script>
</pre>
<br />
<pre class="brush: html"></pre>
Please note that I couldn't directly use the file on github, perhaps it does not like https so I falled back putting on a website on mine (namely at 'http://www.monodes.com/scripts/shBrushEiffel.js') until I improve it a little before proposing it to the main trunk.
Also since Alex says:
<cite>While the hosting is offered as a free service, I’m currently receiving approximately 22m requests a and 83GB in bandwidth every month which is costing me an additional $40 on Amazon S3. Where am I going with this? You guessed it – please donate to help me pay for this :)</cite>
I think I would rather put an entire copy of the package on my domain.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com4tag:blogger.com,1999:blog-8972783911534754044.post-11848788533480772212011-12-20T08:45:00.002+01:002011-12-20T17:15:19.557+01:00Creation proceduresEiffel required - a quarter of century ago - explicitly provide a creation procedure for each object; so each creation was in the form of<br />
<blockquote class="tr_bq">
create my_list.make_empty</blockquote>
Nowadays SmartEiffel allow us to write<br />
<blockquote class="tr_bq">
create my_list</blockquote>
when a class has put default_create command in the creation clauses list such as:<br />
<blockquote class="tr_bq">
class LITTLE_LIST [ITEM]<br />
-- A list to contain few elements<br />
inherit COLLECTION[ITEM]<br />
creation default_create, make, make_empty, with_capacity<br />
...</blockquote>
To create collections, lists, arrays, associative dictionaries you may use the <a href="https://github.com/LibertyEiffel/Liberty/blob/master/tutorial/manifest_notation.e">manifest notation,</a> like this:<br />
<blockquote class="tr_bq">
some_primes := {LINKED_LIST[INTEGER] <<1, 3, 5, 7, 11, 13, 17, 23>> }<br />
<div class="line" id="LC405">
dictionary := {HASHED_DICTIONARY[CHARACTER, STRING] << 'a', "key #1";</div>
<div class="line" id="LC406">
'z', "key #2";</div>
<div class="line" id="LC407">
'z', "key #3";</div>
<div class="line" id="LC408">
'a', "key #4" >> }<br />
<div class="line" id="LC417">
bijective_dictionary :=</div>
<div class="line" id="LC418">
{HASHED_BIJECTIVE_DICTIONARY[STRING, STRING]</div>
<div class="line" id="LC419">
<< "value #1", "key #1";</div>
<div class="line" id="LC420">
"value #2", "key #2";</div>
<div class="line" id="LC421">
"value #3", "key #3" >> }</div>
</div>
</blockquote>
Please excuse the horrible formatting of the code, I'm working on it. Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-84046140024245083482011-12-20T08:30:00.001+01:002012-01-24T16:52:19.351+01:00diff "Eiffel: the language" "GNU Eiffel"We <a href="http://liberty-eiffel.blogspot.com/2011/10/hello-world-again.html">have been asked</a> for some informations about the differences between the language originally described in <a href="http://books.google.it/books/about/Eiffel.html?id=06RQAAAAMAAJ&redir_esc=y">"Eiffel: the language"</a> (1992 by Bertrand Meyer) and those accepted by the current GNU/Smart/Liberty Eiffel compiler.<br />
Such a request is not only reasonable but requires some answer: there have been several additions and quite a few changes to the language.<br />
The main changes are: <br />
<ol>
<li><a href="http://liberty-eiffel.blogspot.com/2011/12/creation-procedures.html">Creation procedures</a></li>
<li>agents</li>
<li>conformance of agents </li>
<li>anonymous, in-lined agents (a_command(12, "Foo", agent (x: INTEGER): REAL is do Result:=x.to_real ^ 2 end )</li>
<li><a href="http://liberty-eiffel.blogspot.com/2011/12/insert-or-non-conforming-inheritance.html">insert, also known as "non-conforming inheritance"</a></li>
<li><a href="http://liberty-eiffel.blogspot.com/2011/12/case-sensitivity.html">case sensitivity</a></li>
<li>inspect allow for integer intervals... </li>
<li>FLOAT is replaced with REAL</li>
<li> There is no NONE (pun intended :-)</li>
<li>other I don't recall now.</li>
</ol>
To keep things tidy I am writing a separate post for each point.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-38371969137927658752011-10-03T21:50:00.001+02:002011-10-03T21:50:50.874+02:00Hello World… againThe first version of the Liberty interpreter was stillborn. It took a year to utter Hello World… and never said anything more.<br />
<br />
The second version, based on SmartEiffel, is alive and kicking, after 2 weeks gestating.<br />
The "runner" is screaming: Hello World!Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com5tag:blogger.com,1999:blog-8972783911534754044.post-62376211639141951782011-09-26T12:34:00.000+02:002011-09-26T12:34:15.265+02:00Overflow and correctness<span style="font-size: small;">Eiffel is a programming language that strives for correctness.</span><br />
<span style="font-size: small;">In C instead most of the times speed is regarded as more important than correctness (paraphrasing <a href="http://www.blogger.com/goog_223674362">a comment of E</a><a href="http://bytes.com/topic/c/answers/811548-accessing-flags">ric Sosman</a> ).</span><br />
<span style="font-size: small;">Most Eiffel compilers use C as an intermediate language (Liberty/SmartEiffel, ISE), so a programming language striving for correctness relies on one that trade correctness for speed.</span><br />
<span style="font-size: small;">I've been thinkering about</span><br />
<span style="font-size: small;">I think we cannot blame C as this is a issue that has no "solution"; let's see a little panoramic of the efforts poured into something "as simple" as correctness in integer calculations:</span><br />
<ul>
<li><span style="font-size: small;"><a href="http://stackoverflow.com/questions/199333/best-way-to-detect-integer-overflow-in-c-c">Best way to detect integer overflow in C (from Stackoverflow.com)</a></span></li>
<li><span style="font-size: small;"><a href="http://www.sei.cmu.edu/reports/10tn008.pdf">CERT's "as-if" infinitely ranged (AIR) integer model</a> and</span><span style="font-size: small;"><span id="title-text"><a href="https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow"> "Ensure that operations on signed integers do not result in overflow"</a></span></span></li>
<li><span style="font-size: small;"><a href="http://ptgmedia.pearsoncmg.com/images/0321335724/samplechapter/seacord_ch05.pdf">Integer security </a></span></li>
<li><span style="font-size: small;"><a href="http://www.fefe.de/intof.html">Catching Integer Overflows in C</a></span></li>
</ul>
<span style="font-size: small;">Sadly there is no magic wand for this issue.</span><br />
<span style="font-size: small;">An answer may be <a href="http://en.wikipedia.org/wiki/Saturation_arithmetic">saturation arithmetic</a>; digging my fading knowledge of assembler, mainly from my days on <a href="http://en.wikipedia.org/wiki/6502">6502</a> I was wondering why no one seems to use the <a href="http://en.wikipedia.org/wiki/Overflow_flag">overflow flag</a> present in almost all CPU: it seems there is no portable way to do it access it. Oh it would be so nice to write in INTEGER_GENERAL </span><br />
<blockquote>
<span style="font-size: small;">«infix "+" (another: like Current): like Current is external "built_in" ensure has_overflowed=False end»</span></blockquote>
I naively thought that an arithmetic overflow would have triggered a <a href="http://en.wikipedia.org/wiki/SIGFPE">SIGFPE signal</a> in POSIX systems. It seems I'm wrong:<br />
<blockquote>
<span style="font-size: x-small;">class <b>OVERFLOW</b><br /> -- Test integer overflow<br />insert <b>PLATFORM</b><br />creation make<br />feature make is<br /> local i,j: INTEGER<br /> do<br /> i := Maximum_integer<br /> j := i+1 -- SIGFPE expected<br /> ("i:=#(1), j=i+1=#(2)%N"# (&i) # (&j) ).print_on(std_output)<br /> end<br /> end</span></blockquote>
When compiled with "compile overflow.e" Liberty Eiffel correctly says:<br />
<blockquote>
<span style="font-size: xx-small;">*** Error at Run Time ***: Require Assertion Violated.<br />*** Error at Run Time ***: no_overflow<br />3 frames in current stack.<br />===== Bottom of run-time stack =====<br /><system root><br />Current = OVERFLOW#0x925b038<br />line 5 column 9 file /media/Liberty/tybor-liberty/work/tybor-sandbox/overflow.e <br />======================================<br />make OVERFLOW<br />Current = OVERFLOW#0x925b038<br />i = 2147483647<br />j = 0<br />line 9 column 4 file /media/Liberty/tybor-liberty/work/tybor-sandbox/overflow.e <br />======================================<br />infix + (infix + INTEGER_32)<br />Current = 2147483647<br />other = 1<br />Result = 0<br />line 21 column 80 file /home/paolo/current-liberty/src/lib/numeric/integral.e <br />===== Top of run-time stack =====<br />*** Error at Run Time ***: Require Assertion Violated.<br />*** Error at Run Time ***: no_overflow</span></blockquote>
but when we compile it with "compile --boost overflow.e" it happily says: "i:=2147483647, j=i+1=-2147483648" which is obviously wrong. You have to compile it with "compile --boost overflow.e --cc gcc -ftrapv" to laconically receive the answer<br />
<blockquote>
"Received signal 6. <br />
Eiffel program crash at run time.<br />
No trace when using option "-boost"</blockquote>
Which is not what I would expect, since signal 6 is ABRT on my system.<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com1tag:blogger.com,1999:blog-8972783911534754044.post-38525111785980280302011-09-26T08:30:00.000+02:002011-09-26T13:33:52.348+02:00infix "#": Eiffel's printfIt's really nice to be able to write in Liberty/SmartEiffel:<br />
<br />
<blockquote>
("i:=#(1), j=i+1=#(2)%N"# (&i) # (&j) ).print_on(std_output)<br />
("obviously foo := #(2), bar := #(1)%N" # &42 # &17).print_on(std_output)</blockquote>
<br />
which may look cryptic to most Eiffel programmers, but may look familiar when translated into C:<br />
<blockquote>
printf("i:=%d, j=i+1=%d\n", i,j)
<br />
printf("obviously foo := %d, bar := %d\n", 17,42)</blockquote>
Beside looking a little more convoluted it actually has quite a few advantages: <br />
<ul>
<li>like QString::arg of Qt fame it allows positional arguments,</li>
<li>it does not rely on variable argument function calls,</li>
<li>it does not allocate an unnecessary array to hold the arguments; each call to # actually return a ROPE which does is an ABSTRACT_STRING holding references to two substrings; the prefix "&" operator returns a LAZY_STRING (praises to Adrian for good idea) which will not be converted to a string until it gets iterated over, usually printing or copying it.</li>
<li>it allows to write things like:<br /><blockquote>
local s,t,u: STRING<br />
do<br />
<div style="margin-left: 40px;">
s := "Eiffel"; t:= "beautiful"<br />
u := s | " is a " |t| " language"<br />
assert (u.is_equal("Eiffel is a beautiful language")<br />
t.prepend("really ") <br />
assert (u.is_equal("Eiffel is a really beautiful language")<br />
-- which may also obtained with<br />
u := "#(1) is a #(2) language" # s # t</div>
end</blockquote>
</li>
<li>it does retain type-safety (AFAIK)</li>
</ul>
Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com1tag:blogger.com,1999:blog-8972783911534754044.post-49266950293065559172011-07-17T13:33:00.000+02:002011-07-17T13:33:06.621+02:00SmartEiffel as Liberty coreOK guys, I have permission from Dominique, and I guess it is better anyway.<br />
<br />
SmartEiffel is back in the trenches. It is now completely part of LibertyEiffel.<br />
<br />
Here is the plan:<br />
<ol><li>really integrate SmartEiffel into Liberty <i>(done)</i></li>
<li>separate the C backend from the AST (fix and use the acyclic visitor)</li>
<li>remove or rewrite the Java backend (using the acyclic visitor)</li>
<li>rewrite the interpreter as a SmartEiffel backend (maybe using the acyclic visitor)</li>
</ol><br />
Extra points to fix:<br />
<ul><li>sedb — it lost some of its power in the latest releases (some break points disappeared)</li>
<li>Liberty core — will be removed; that code is dead.</li>
<li>some bugs in inline agents parsing (SmartEiffel segfault)</li>
<li>some bugs in boost mode (invalid C code)</li>
</ul><br />
The Liberty libraries (both native and wrappers), on the other hand, are here to stay. They deserve being enhanced.<br />
<br />
Spread the news :-)Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com4tag:blogger.com,1999:blog-8972783911534754044.post-58568712328875676032010-12-26T15:21:00.000+01:002010-12-26T15:21:56.807+01:00CoroutinesThe <a href="https://github.com/LibertyEiffel/Liberty/commit/13be8ff32fad1464d5583e2aed7b3359b2e80acd">linked commit</a> introduces coroutines in the Eiffel world.<br />
<br />
The concept is implemented in the Liberty repository, but that should work in a pristine SmartEiffel too.<br />
<br />
Enjoy!Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com2tag:blogger.com,1999:blog-8972783911534754044.post-68993333748290545152010-09-17T00:14:00.000+02:002010-09-17T14:36:21.271+02:00I was told Eiffel wasn't like C++...Many Eiffel enthusiasts - I shall put myself in the group - often write about the many pros of our beloved language when compared to C++.<br />
One of those aspects that I was sure Eiffel handled better than C++ was <a href="http://en.wikipedia.org/wiki/C%2B%2B_Templates">templates</a>, known as <a href="http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Genericity">generics</a> in Eiffel.<br />
C++ templates has been often accused to lead to code bloat and large executable, since the compiler generates specialized code for each type used in a template.<br />
As an example when you use <a href="http://doc.qt.nokia.com/4.6/qlist.html">QList</a> as QList<int><int>, QList<qstring*><MyClass*>, QList<myobject*><AnotherClass*> you will end up having three specialized copies of each and every function defined in QList, a class that has more than seventy functions. </myobject*></qstring*></int><br />
This justify why C++ executables are often considered "fat".<br />
I don't know why but I have been always convinced that generics in Eiffel didn't show this pattern.<br />
SmartEiffel proved me <b>wrong</b>.<br />
I suspected it compiling my own wrappers-generator and getting <b>a 5,2 Mb executable</b> from more or less <b>4450 lines of code</b> as reported by command "wc".<br />
Ehi! This is more than 1200 bytes of binary code for each and every Eiffel line, empty lines and comments included! <br />
No, my coding style can't be so awesome and this tool is nothing special.<br />
It just shall not be this big.<br />
So I dived into generated source code.<br />
At the beginning of wrappers_generator.id which contains a description of the compiled classes from the C and Eiffel compiler point of view I can read something like:<br />
<br />
<span style="font-size: x-small;">478 "HASHED_DICTIONARY[XML_DTD_ATTRIBUTE,UNICODE_STRING]" l<br />
#<br />
555 "HASHED_DICTIONARY[COMPOSED_NODE,UNICODE_STRING]" l<br />
#<br />
404 "HASHED_DICTIONARY[WEAK_REFERENCE[ANY_LINKED_LIST_NODE],STRING]" l<br />
#<br />
467 "HASHED_DICTIONARY[RECYCLING_POOL[PROTOCOL],STRING]" l<br />
#<br />
365 "HASHED_DICTIONARY[POINTER,STRING]" l</span><br />
<br />
So I looked into wrappers_generator_T478.c wrappers_generator_T555.c wrappers_generator_T467.c wrappers_generator_T365.c which are the C code containing the translations for those.<br />
Please note that with the exception of POINTER, <b>each and every</b> classes referred in those <b>incarnations</b> of HASHED_DICTIONARY <b>are reference classes</b> that gets converted into a type-less C pointer ("void*" for the C-fond).<br />
Now I looked into the function called Txxxcreate_with_capacity ... I wasn't too surprised to find a couple of pages of machine-generated C code that is exactly the same as all thos Txxx pointers are actually void pointers.<br />
So in the end SmartEiffel actually implements generics in the very same (bloated?) way as C++ implements templates.<br />
Now I guess that people smarter than me have made many researches on the topic but let me wonder whenever Liberty may avoid this.<br />
And <b>I know it is avoidable for reference classes.</b><br />
Think a little about GLib collections and how they implemented generic object-oriented containers in C. They do not have the compiler to generate templates or generics for them, so they will end up with exactly one "binary" implementation of "replace" (<a href="http://library.gnome.org/devel/glib/stable/glib-Hash-Tables.html#g-hash-table-replace">g_hash_table_replace</a>) for every kind of hash table. <br />
<b>That is how</b> I would like to implement generic classes.<br />
The only tricky part is that when you will invoke feature "foo" of the parametric type (ITEM in class LIST[ITEM]) you need to query the runtime for the address of ITEM_foo, so you will need a full fledged object-oriented type system.<br />
I'm thinking about eventual implementation of multiple-inheritance runtime. I'm investigating a variant of <a href="http://library.gnome.org/devel/gobject/stable/howto-interface.html">Gobject interfaces</a>. In fact if we turn each and every attribute query into an actual function call multiple inheritance looks somehow like using multiple interface; this will have a deep impact of performance since every access to any structure field will be turned into a deferred/virtual/indirect function call; actually I suspect that the link-time function in-lining of LLVM may be the silver bullet. Otherwise it won't be feasible, except if we want to "degradate" Liberty to an interpreted language.<br />
A little ending note: when dealing with "expanded" classes, or with objects passed by value "template instantiation" is the only feasible way to go, so C++ was right.<br />
Luckily (Smart)Eiffel prescribe that reference classes are always passed by reference and expanded always by value. This greatly simplify the work for the compiler to translate source code but most importantly greatly simplify things for our neurons.<br />
Please feel free to correct any wrong deduction of this little note.Anonymoushttp://www.blogger.com/profile/03026537587693318231noreply@blogger.com8tag:blogger.com,1999:blog-8972783911534754044.post-8228839491046570022010-07-16T16:19:00.000+02:002010-07-16T16:19:23.469+02:00Mailing listsChristophe Haro asked me a very interesting question today: how does one contact the LibertyEiffel community?<br />
<br />
There was no mailing list ten minutes ago. Now there is.<br />
<br />
Just write to <a href="mailto:libertyeiffel@librelist.com">libertyeiffel@librelist.com</a> and you're done!<br />
<br />
See their site (<a href="http://librelist.com/">http://librelist.com</a>) for details. In a nutshell, when you send your first mail you are returned a standard subscription mail; just answer it and you're set.<br />
<br />
Welcome on board!Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-59047403647863437432010-07-02T23:03:00.000+02:002010-07-02T23:03:26.888+02:00Getting organized.Thanks to the new github "organization", LibertyEiffel has now gained a central depot independantly to the developers.<br />
<br />
You can find the code there: <a href="http://github.com/LibertyEiffel/Liberty">http://github.com/LibertyEiffel/Liberty</a><br />
<br />
Tickets should be opened there too.Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com0tag:blogger.com,1999:blog-8972783911534754044.post-14360598755823726772010-05-12T21:03:00.000+02:002010-05-12T21:03:35.128+02:00How easy should it be to install Liberty?That easy:<br />
<blockquote><span style="font-family: "Courier New",Courier,monospace;">$ <b>./install.sh</b></span></blockquote>And now it <i>is</i> that easy.Cyril Adrianhttp://www.blogger.com/profile/05915629514665711947noreply@blogger.com0