| Author |
Message |
|
| luke at bluetail.com |
 Posted: Fri Dec 12, 2003 6:01 pm |
 |
|
|
Guest
|
"Richard A. O'Keefe" <ok_at_cs.otago.ac.nz> writes:
> There are only three ways I can think of to get an integer calculation
> down to a single instruction:
[...]
> (2) Use some really amazing interval analysis as well as type inference.
> Erlang doesn't give you much to get started with, though. About the
> only thing I can think of is that starting with size(_) and counting
> down towards 0 should be safe.
Related to the "Network benchmark" thread: one place in Erlang that
you get precise integer-size type information is with the bit syntax,
e.g. "<<X:16, Y:16>> = Bin, X + Y" adds two 16-bit fixnums. Is that a
single-instruction case?
It's possible to imagine a heavy duty optimizer generating fast code
for e.g. checksumming an IP packet, doing lots of 16-bit arithmetic on
values coming out of a binary.
No idea if that's practical, but maybe something to drool over in idle
hours ;-)
By the way, at EUC Thomas Lindgren mentioned the bother of taking care
of "bump reductions" in loops, and Tony Rogvall said something to the
effect of "or we could get rid of bump_reductions and do it properly
instead." What would be the "proper" way?
Cheers,
Luke
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| robert.virding at telia.c |
| Posted: Tue Dec 16, 2003 8:10 am |
|
|
|
Guest
|
I have read through the discussion on this suggestion and found it a little strange, to say the least.
There are a few points I would like to make:
1. If I understood Richard correctly he means that the compiler should be careful when it can't do things consistently, in this case warn about a a construction which will generate an error. He also gave some equivalent code to "a+42" which the compiler would not warn about. His first case, "X = a, X+42" is especially funny as the compiler will generate exactly the same code for it, as it has some simple constant propagation in it. I completely agree with Richard.
2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact?
3. What is the point is the compiler transforming it to exit({badarith,...})? What are you exactly gaining by doing it? Not saving code anyway, and hardly runtime either.
So my suggestion would be #2, generate a warning. I say that the compiler should disallow illegal code and allow all legal code while warning for potentially stupid things. It should NEVER disallow legal code. Sorry Bjorn but this also includes a compiler option which transforms all warnings to errors. Do you seriously mean that it should be illegal to have singleton variables, unused functions, bad calls to format etc? It is one thing to warn, but to disallow?
The compiler should help me and not hinder me by trying to be too stupidly smart. As example just look at what Word/Outlook Express do for some really terrifying examples. This is somewhat similar to the syntax change suggestion a while back try and catch the case where there was a missing blank in X =<<...>>.
Sorry for getting worked up about this but I wish people would think through their suggestions a bit more and consider the deeper implications of them.
Finally one definite reason not to outlaw a+42 is that it is one of my standard ways of generating an error in code, being much shorter to write than exit(some_bogus_exit_value). I also use 1=2 (N.B. only one =). Which should also be banned I suppose.
Robert
P.S. If things like this are added to the compiler then it is time for an alternate compiler.
----- Original Message -----
From: "Kostis Sagonas" <kostis_at_user.it.uu.se>
To: <erlang-questions_at_erlang.org>
Sent: Wednesday, December 10, 2003 6:25 PM
Subject: Small poll
> I was wondering whether the Erlang user community would care
> to comment on the following:
>
> In a function like:
>
> test(A) ->
> a + 42.
>
> which is either crap (arguably) or a typo (A vs a), how many
> Erlang users:
>
> 1. Are content with the current situation where the compiler
> happily compiles this program
> 2. Would like to see a warning, but a .beam file generated
> nevetheless
> 3. Would prefer if the compiler in R10 refused to compile it
>
> Notice I am not talking about any serious attempt to static
> type checking, but for really "basic" checks.
>
> Kostis.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| luke at bluetail.com |
| Posted: Tue Dec 16, 2003 8:46 am |
|
|
|
Guest
|
"Robert Virding" <robert.virding_at_telia.com> writes:
> Finally one definite reason not to outlaw a+42 is that it is one of my
> standard ways of generating an error in code, being much shorter to
> write than exit(some_bogus_exit_value). I also use 1=2 (N.B. only one
> =).
I've often wondered how many different ways people do this. I do 1/0,
Klacke does a=b, you do 1=2., ..... :-)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Tue Dec 16, 2003 9:32 am |
|
|
|
Guest
|
Robert Virding wrote:
...deleted
> 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact?
i did not know ''a+42'' was legal. i thought it generated an error.
...deleted
> Finally one definite reason not to outlaw a+42 is that it is one of my standard ways of generating an error in code, being much shorter to write than exit(some_bogus_exit_value).
i think that a+42, with a comment stating that this is indeed intended
to cause an error, and an explanation why you want an error here, is
probably longer than erlang:exit(why_you_want_an_error).
presumably you do not suggest putting a+42, without any explanation,
into the source?
> P.S. If things like this are added to the compiler then it is time for an alternate compiler.
i think this is a very good suggestion. if it frightens anybody i would
like to mention that it was egcs that became gcc-2.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Tue Dec 16, 2003 10:59 am |
|
|
|
Guest
|
> 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact?
>
Quite right.
As I pointed out before there can be two possible reasons why the
programmer wrote a+42.
1) The programmer made an error, or,
2) The programmer wants the system to raise an exception.
THERE IS NO WAY THE COMPILER KNOWS WHICH OF THESES TWO CASES APPLIES
(Sorry for shouting)
Conclusion:
You must tell the compiler (ie the compiler needs to know the
programmer's intention - << what I call intentionality >>)
There are two ways of telling the compiler:
a) add pragmas to Erlang
pragma(bad_code)
a+42
end
b) add a known wrapper that the compiler understands
for example make a function
this_is_not_an_error(X) -> X. and then call it thus:
this_is_not_an_error( a + 42)
Method b) needs no syntactic changes to the language, and (I guess)
a very simple change to the compiler.
If we adopt b) then the compiler should reasonably behave as follows:
a+42 Produces a warning
and compiles the code correctly
this_is_not_an_error(a+42) Compiles the code correctly
with no warning
In both cases the function is compiled - the only difference is
whether you warn or not.
Robert is entirely right - legal code must ALWAYS be correctly
compiled --- the compiler should never try to outguess the programmer
and guess that this was an error - half our test suits would stop
working if this were the case.
/Joe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| goran.bage at mobilearts. |
| Posted: Tue Dec 16, 2003 2:00 pm |
|
|
|
Guest
|
Luke Gorrie wrote:
> "Robert Virding" <robert.virding_at_telia.com> writes:
>
>
> I've often wondered how many different ways people do this. I do 1/0,
> Klacke does a=b, you do 1=2., ..... 
>
Ahh, now you are getting somwhere, let's discuss which is the fastest :-)
--
-- Goran
------------------------- May the Snow be with you ----
Goran Bage, MobileArts, www.mobilearts.se
Tj |
|
|
| Back to top |
|
| robert.virding at telia.c |
| Posted: Wed Dec 17, 2003 12:05 am |
|
|
|
Guest
|
From: "Bengt Kleberg" <Bengt.Kleberg_at_ericsson.com>
> Robert Virding wrote:
> ...deleted
> > 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact?
>
> i did not know ''a+42'' was legal. i thought it generated an error.
It is a perfectly legal expression but when evaluated it generates an error. As errors are a part of Erlangs semantics you can't go and just eliminate any expression which might generate one. If you do that then you are changing the semantics of the language. Also doing it in an ad hoc way in the compiler by catching expressions which just happen to be easy to detect would be very confusing. I mean why flag a+42 and not A=a,A+42 which is also very simple and just as likely to cause an error. A compiler should disallow illegal code, do its best with legal code and try to be helpful by warning about legal, but potentially confusing or with misleading results, code or constructions.
That is why the compiler's warnings should stay as warnings and never become errors.
> presumably you do not suggest putting a+42, without any explanation,
> into the source?
Well, it's pretty obvious that if you write something like a+42 in your code then you're intending it to fail. I mean there are limits. I usually document code which is not plainly obvious and which I feel I might have difficulty remembering what it did at a later date, or does something tricky and smart. This and a comment at the beginning of the function usually suffices. I am of the opinion that having to many comments tends to make everything difficult to read. Also having a comment standard helps to keep comments short. Read through the compiler and parts of the libraries (the more basic ones) to see how I code.
Robert
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| luke at bluetail.com |
| Posted: Wed Dec 17, 2003 12:17 am |
|
|
|
Guest
|
"Robert Virding" <robert.virding_at_telia.com> writes:
> That is why the compiler's warnings should stay as warnings and never
> become errors.
To properly enforce this, perhaps we should also suppress the warnings?
#!/usr/bin/awk -f
BEGIN { status = 0 }
{ print $0 }
/Warning:/ { status = 1 }
END { exit(status) }
;-)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| kostis at user.it.uu.se |
| Posted: Wed Dec 17, 2003 12:36 am |
|
|
|
Guest
|
Robert Virding wrote a mail quoting my mail, and he finished it as
follows:
> ... deleted ...
>
> Sorry for getting worked up about this but I wish people would think
> through their suggestions a bit more and consider the deeper
> implications of them.
>
> Finally one definite reason not to outlaw a+42 is that it is one of my
> standard ways of generating an error in code, being much shorter to
> write than exit(some_bogus_exit_value).
I will try to avoid the temptation of replying directly to the first
statement above, and instead reply to the following question of Robert.
> 3. What is the point is the compiler transforming it to
> exit({badarith,...})? What are you exactly gaining by doing it?
> Not saving code anyway, and hardly runtime either.
Ah, Robert, you seem to have very limited imagination... let me help
you here. Consider the code:
-module(a42).
-export([test/0]).
test() ->
catch f(),
ok.
f() when a+42 == 0 ->
%% extremely long sequence of code here
ok_1;
f() ->
Y = ackerman(), % very long computation here
% (without side-effects)
X = a+42,
mod:funct(X,Y),
%% possibly lots more other code here
ok_2.
ackerman() -> ....
QUESTION 1
----------
Do the "semantics" of Erlang (BTW, I would really like to see them
formally specified before people use this term again) allow a compiler
to transform the code above to just:
-module(a42).
-export([test/0]).
test() ->
ok.
QUESTION 2
----------
Can the savings in time and code space be made arbitrarily big, or not?
QUESTIONS 3-N
-------------
- Do the two occurrences of "a+42" need to be treated differently
by the compiler in the above example, or not?
- Is "a+42" an expression that always generates an error in Erlang?
(as far as the user is concerned)
- Is it just me that finds this Erlang-ism confusing to say
the least? (I.e., is this a user-friendly language design?)
Kostis.
PS. I am very well aware that the subject has shifted from
warnings vs. errors to something else now, but I could
not resist. Apologies.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ok at cs.otago.ac.nz |
| Posted: Wed Dec 17, 2003 4:22 am |
|
|
|
Guest
|
Is it clear to everyone that
"This code must raise an exception at run time"
and
"This code is in error"
are different? Let me give an Interlisp example first.
In Interlisp-D, there was a built-in function (SHOULDNT).
For example, you might define the factorial function like this:
[PUTDQ FACTORIAL
(LAMBDA (N)
(IF (> N 1) THEN (* N (FACTORIAL (- N 1)))
ELSE IF (>= N 0) THEN 1
ELSE (SHOULDNT]
Now the call to (SHOULDNT) must raise an exception at run time,
and if the call is _executed_ that indicates an error in the way
the function is used, but it isn't an error in the program to _have_
the call sitting there. An Interlisp compiler that rejected code
containing (SHOULDNT) would have rejected every Interlisp program I
ever wrote.
The C equivalent of (SHOULDNT) is abort(). Not, by the way, assert(0).
Is it also clear that
"This code is obviously silly"
and
"This code must raise an exception at run time"
are different? Lint warns about things that are clearly silly,
yet perfectly legal, and perfectly harmless. For example,
x == y;
as a C statement is perfectly well defined, and quite harmless,
yet lint warns about it because you probably didn't mean it.
A C compiler which refused to compile such a program would not
be helpful, it would be buggy.
It is possible to make (=)-for-(==) and (==)-for-(=) errors in
Erlang, and lint checking for Erlang might warn about them even
though they are legal.
Whether a particular piece of apparent silliness is worth warning
about is an empirical question: how often do programmers make the
kind of mistake that results in an instance of that pattern, and
how often do they intend it?
I have no idea what kinds of mistakes are commonest in Erlang.
It would be interesting to find out.
I've worked on a couple of compilers for languages that supported
exception handling. (I _think_ mine was the first paper on doing this
for Prolog, except that Quintus insisted on yanking it from the conference
after it was accepted.) Exception handling can be very tricky to get
right. (There's a debate raging in the Clean mailing list at this moment.)
ANSI Smalltalk exception handling is a case in point; to me it seems
insanely complicated, and it's not clear that Squeak has got it 100% right
yet. This means that especially when you are maintaining compilers, you
_need_ simple test cases which are certain to cause exceptions because
that's what you're testing.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Wed Dec 17, 2003 9:09 am |
|
|
|
Guest
|
Richard A. O'Keefe wrote:
> Is it clear to everyone that
>
> "This code must raise an exception at run time"
>
> and
>
> "This code is in error"
>
> are different?
...deleted
yes, i think i understand. you are saying that some code should be ok to
compile, even if it will always crash at run time.
would it seem very strange if i did not agree? because i do not, even
though i have not ever written a compiler. perhaps this is why?
>
> Is it also clear that
>
> "This code is obviously silly"
>
> and
>
> "This code must raise an exception at run time"
>
> are different?
yes, here we do agree. a large part of my code is obviously silly, and
yet there are not many run time exceptions. atleast not after i have run
the test cases.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Wed Dec 17, 2003 9:14 am |
|
|
|
Guest
|
Kostis Sagonas wrote:
...deleted
> - Is it just me that finds this Erlang-ism confusing to say
> the least? (I.e., is this a user-friendly language design?)
i take the last question as beeing directed to any reader of the list,
and not to mr virding in particular. i apologise if i am mistaken.
i find erlang to be very user unfriendly in its syntax. the semantics
are beyond me, but some scope rules are terrible.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joachim.durchholz at web. |
| Posted: Wed Dec 17, 2003 9:25 am |
|
|
|
Guest
|
Richard A. O'Keefe wrote:
>
> The C equivalent of (SHOULDNT) is abort(). Not, by the way, assert(0).
If that's the case, SHOULDNT shouldn't be in the language.
After all, forcing the execution of the program to a halt is unmodular:
the caller might want to run the code and try an alternate strategy.
(Heck, that's what Erlang is all about: surviving faulty code that does
thing's that shouldn't happen.)
> Is it clear to everyone that
>
> "This code must raise an exception at run time"
>
> and
>
> "This code is in error"
>
> are different?
This classification isn't complete, and I think the ongoing discussion
is at least partially senseless because wrong distinctions of this kind
are constantly being made.
Actually, Erlang has more failure modes (and this list may not even be
complete):
1. Erroneous code that's rejected by the compiler. This includes stuff
like "1 = 2 3".
2. Code that will raise an exception. Example: "1 = 2".
3. Code that will terminate the process. Essentially, that's code that
doesn't catch all exceptions that may occur.
4. Code that will terminate the Erlang node.
5. Code that will terminate all communicating Erlang nodes.
Category 2 is what most confusion comes from: depending personal
definitions, one may consider it erroneous or not (and either definition
makes sense, depending on the point of view).
There's another source of confusion: Some people here argue that a
compiler shouldn't change the semantics of the language, but is that
indeed the case? Both syntax and semantics of Erlang have changed over
the years, in in an upwards-compatible fashion.
> Is it also clear that
>
> "This code is obviously silly"
>
> and
>
> "This code must raise an exception at run time"
>
> are different? Lint warns about things that are clearly silly,
> yet perfectly legal, and perfectly harmless. For example,
> x == y;
> as a C statement is perfectly well defined, and quite harmless,
> yet lint warns about it because you probably didn't mean it.
> A C compiler which refused to compile such a program would not
> be helpful, it would be buggy.
A C compiler would emit a warning and be compliant.
If I were to decide, I'd adopt a similar policy: issue warnings about
constructs like 1=2.
However, I dislike somethine entirely different about them. There's
clearly a need to make a computation fail, and different people use
different idioms to express is. Some say 1=2, others say a+0, and I saw
mentions a handful others.
While that's neat, it's also an unnecessary maintenance obstacle.
Whenever a maintainer sees such code, he has to (a) find out what this
code does (which will take more time than usual because he'll have to
revisit the usual assumption that code isn't written for raising
exception), (b) figure out whether the code is raising the exception
intentionally or not.
There are two additional disadvantages: (c) it's impossible to do a grep
to see whether any temporary exception-raisers were accidentally left in
some code that's considered ready for production release, and (d) if the
code does raise an exception, it will give the maintainer wrong
information: the true error is that the system is trying to execute
unwritten code, but the system will give a different error message.
I'm quite mystified why there isn't a "niy" (not implemented yet) or
"tbd" (to be determined) routine, that explicitly raises an exception
saying "fatal error: trying to execute code that has not yet been
written" (or something similar).
Once such a routine is in place, the question whether changing the
semantics of obviously silly constructs is a no-brainer: if there's no
useful purpose for them, their semantics is irrelevant and can be
changed. One may adopt a more conservative approach and maintain
compatibility with legacy code, so a warning would probably be more
appropriate. An even better option would be if that warning could be
turned into an error for those shops who want strict discipline (not all
shops need that, but sometimes there are good reasons to turn on the
equivalent of -Wall --warnings-as-errors).
> It is possible to make (=)-for-(==) and (==)-for-(=) errors in
> Erlang, and lint checking for Erlang might warn about them even
> though they are legal.
>
> Whether a particular piece of apparent silliness is worth warning
> about is an empirical question: how often do programmers make the
> kind of mistake that results in an instance of that pattern, and
> how often do they intend it?
And, more importantly: how easy is it to make the compiler detect that
pattern, and how likely is it that the compiler will make errors when
identifying such patterns?
> I've worked on a couple of compilers for languages that supported
> exception handling. (I _think_ mine was the first paper on doing this
> for Prolog, except that Quintus insisted on yanking it from the conference
> after it was accepted.) Exception handling can be very tricky to get
> right. (There's a debate raging in the Clean mailing list at this moment.)
> ANSI Smalltalk exception handling is a case in point; to me it seems
> insanely complicated, and it's not clear that Squeak has got it 100% right
> yet. This means that especially when you are maintaining compilers, you
> _need_ simple test cases which are certain to cause exceptions because
> that's what you're testing.
There's always the explicit exception raising statement. Any language
that has exceptions should have such a statement, and Erlang does it right.
Actually, I don't think that generating a test case should be a problem,
ever. There's always the possibility to do unit testing. You'll have to
structure the compiler so that it has units to be tested, but this
restructuring will clean up the compiler considerably, making is more
stable and reliable, so this is a good idea anyway. Loss of test cases
due to changes in language syntax or semantics is just an indicator that
the compiler is badly structured IMNSHO.
Regards,
Jo
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Wed Dec 17, 2003 9:32 am |
|
|
|
Guest
|
Robert Virding wrote:
...deleted
> It is a perfectly legal expression but when evaluated it generates an error. As errors are a part of Erlangs semantics you can't go and just eliminate any expression which might generate one.
may i continue to respectfully belive that code that will _always_
generate an error should stop the compilation?
...deleted
>A compiler should disallow illegal code, do its best with legal code
and try to be helpful by warning about legal, but potentially confusing
or with misleading results, code or constructions.
this is something i can fully agree with. i just happen to think that
''do its best'' in the case of only ''a+42'' is to not compile it.
...deleted
> Well, it's pretty obvious that if you write something like a+42 in your code then you're intending it to fail. I mean there are limits. I usually document code which is not plainly obvious and which I feel I might have difficulty remembering what it did at a later date, or does something tricky and smart. This and a comment at the beginning of the function usually suffices. I am of the opinion that having to many comments tends to make everything difficult to read. Also having a comment standard helps to keep comments short. Read through the compiler and parts of the libraries (the more basic ones) to see how I code.
you are much to kind to me. if i write ''a+42'' it is because i am
making a stupid mistake, nothing else. probably i intended it to be
''A+42''.
your comment standard seems very good. i hope that i am using it (or
something similar).
i am aware of the benefits i can draw from reading more code. actually,
that would be from reading more code written by somebody better than me
(at writing code, ofcourse). but this is always the case in the basic
erlang libraries. still, when time permits some thing like that, i
ususally write some code instead. stupid behaviour.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Wed Dec 17, 2003 11:08 am |
|
|
|
Guest
|
On Wed, 17 Dec 2003, Kostis Sagonas wrote:
> Robert Virding wrote a mail quoting my mail, and he finished it as
> follows:
>
> > ... deleted ...
> >
> > Sorry for getting worked up about this but I wish people would think
> > through their suggestions a bit more and consider the deeper
> > implications of them.
> >
> > Finally one definite reason not to outlaw a+42 is that it is one of my
> > standard ways of generating an error in code, being much shorter to
> > write than exit(some_bogus_exit_value).
>
> I will try to avoid the temptation of replying directly to the first
> statement above, and instead reply to the following question of Robert.
>
> > 3. What is the point is the compiler transforming it to
> > exit({badarith,...})? What are you exactly gaining by doing it?
> > Not saving code anyway, and hardly runtime either.
>
>
> Ah, Robert, you seem to have very limited imagination
<<<< limited imagination -- never - I've never heard anybody accuse
Robert of limited imagination before -- he has his little quirks, we
all do, but limited imagination is not among them... deciding to
totally rewrite the compiler one week before it's to be released and a
month after the last final-final code stop might be a more appropriate
failing >>>>
>... let me help
> you here. Consider the code:
>
> -module(a42).
> -export([test/0]).
>
> test() ->
> catch f(),
> ok.
>
> f() when a+42 == 0 ->
> %% extremely long sequence of code here
> ok_1;
> f() ->
> Y = ackerman(), % very long computation here
> % (without side-effects)
> X = a+42,
> mod:funct(X,Y),
> %% possibly lots more other code here
> ok_2.
>
> ackerman() -> ....
>
>
> QUESTION 1
> ----------
> Do the "semantics" of Erlang (BTW, I would really like to see them
> formally specified before people use this term again) allow a compiler
> to transform the code above to just:
>
> -module(a42).
> -export([test/0]).
>
> test() ->
> ok.
ABSOLUTELY NOT - the programs mean *completely* different things.
In your example the compiler writers job is to make sure that
ackerman() gets evaluated as quicky as possible - it is NOT to change
the meaning of the program.
Programs are ONLY correct wrt to specifications - period - end of story.
Here is the spec (which you didn't show us :-)
<<
Write me a program, that performs a long and evolved computation
(say by calling the ackerman function) - then generate an error and
return ok.
This is to be used in a regression test where we test the speed-up
introduce by our new big-num acceleration hardware.
>>
One good property that a programming language should have is
"predictability" the programmer should be able to naively understand
the (space-time) consequences of their code - break this rule and you
are in trouble.
I *hate* compilers that make assumptions about my code and optimize
away my so-called "mistakes".
If the programmer tells the system to do something stupid then it
should do something stupid.
<< aside -- why is this: Once upon a time I had to program a "radar
controller" when I worked for the Eiscat scientific association. The radar
controller had lots of lamps on the front panel.
The hardware guys wanted me to write an *incorrect* program which
would cause the red error lamp on the front panel to light up.
This proved *impossible* because a "smart" compiler refused all
programs which were incorrect and thus I could not write a test
program that light the red lamp.
I struggled for weeks - eventual we had to throw away all the
control software and re-write it from scratch so that I could write
"incorrect" programs.
Moral - the system should do *exactly* what you tell it and nothing
else >>
>
> QUESTION 2
> ----------
> Can the savings in time and code space be made arbitrarily big, or not?
No - the compiler/run-time system should make the code do exactly
what the programmer said the code should do - what one should optimize
are the artificial artifacts introduced by compilation - ie minimize
garbage collection times, instruction dispatching times etc.
>
> QUESTIONS 3-N
> -------------
> - Do the two occurrences of "a+42" need to be treated differently
> by the compiler in the above example, or not?
No
> - Is "a+42" an expression that always generates an error in Erlang?
> (as far as the user is concerned)
Yes
> - Is it just me that finds this Erlang-ism confusing to say
> the least? (I.e., is this a user-friendly language design?)
I don't find this strange at all - I guess it's just you :-)
/Joe
>
>
> Kostis.
>
> PS. I am very well aware that the subject has shifted from
> warnings vs. errors to something else now, but I could
> not resist. Apologies.
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
