| Author |
Message |
|
| kostis at user.it.uu.se |
 Posted: Wed Dec 10, 2003 6:35 pm |
 |
|
|
Guest
|
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 |
|
| vlad_dumitrescu at hotmai |
| Posted: Wed Dec 10, 2003 7:21 pm |
|
|
|
Guest
|
Hi,
> test(A) ->
> a + 42.
For the "A vs a" problem, there is already a warning being issued. Possibly
the full warnings options should be enabled by default?
Since both a and 42 are constants, I feel it would be easy (besides useful)
to be able to detect it at compile time. The operation should even be
evaluated at compile time, IMHO.
regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| sean.hinde at mac.com |
| Posted: Wed Dec 10, 2003 7:22 pm |
|
|
|
Guest
|
On 10 Dec 2003, at 17:25, Kostis Sagonas wrote:
> 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
3 please. This is not feature I want anyone here relying on :-)
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| luke at bluetail.com |
| Posted: Wed Dec 10, 2003 7:30 pm |
|
|
|
Guest
|
Kostis Sagonas <kostis_at_user.it.uu.se> writes:
> 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
I would like (2). (1) would be a bit weird since there are already
warnings for e.g. unused functions, but (3) might be annoying if I
know test/1 is broken but want to poke around some other functions.
Is this coming from the type-analysis stuff mentioned in the EUC HiPE
presentation? If so, to firmly put myself into broken-record-mode  ,
I think what CMUCL does with the type information it discovers is
pretty nice -- warnings like this and optional "efficiency-notes".
And if you end up doing optional efficiency-notes in HiPE, as in
foo.erl:10: Bit-syntax pattern is not byte-aligned - not native-compiling
foo.erl:20: Can't determine operand types in "X*Y*Z" - not inlining '*'
then I promise to hack up a fancy Emacs front-end like CMUCL has
http://www.bluetail.com/~luke/misc/lisp/slime-shot.png
.. though I won't suggest we have to make the compiler so
unpredictable as to require efficiency-notes just so that the Emacs
mode can be fancier :-)
(And of course Emacs needs to know a little more than just the line
number to figure out what to underline..)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| taavi at uninet.ee |
| Posted: Wed Dec 10, 2003 7:33 pm |
|
|
|
Guest
|
On Wed, 10 Dec 2003, Vlad Dumitrescu wrote:
> > test(A) ->
> > a + 42.
>
> For the "A vs a" problem, there is already a warning being issued. Possibly
> the full warnings options should be enabled by default?
>
> Since both a and 42 are constants, I feel it would be easy (besides useful)
> to be able to detect it at compile time. The operation should even be
> evaluated at compile time, IMHO.
Exactly. And if compile time evaluation fails, give compile time error
{badarith,....}.
best regards,
taavi
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| hal at vailsys.com |
| Posted: Wed Dec 10, 2003 7:44 pm |
|
|
|
Guest
|
Kostis Sagonas <kostis_at_user.it.uu.se> writes:
> 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
We don't do that, ergo, no preference.
I'd rather see cond added.
:-)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Wed Dec 10, 2003 8:24 pm |
|
|
|
Guest
|
On Wed, 10 Dec 2003 18:25:44 +0100 (MET)
Kostis Sagonas <kostis_at_user.it.uu.se> wrote:
> 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
5. Would prefer it returned the atom 'a42' (PerLang/I! Yesss!!!)
(Dark humour aside... I think #2 makes the most sense.)
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| luna at update.uu.se |
| Posted: Wed Dec 10, 2003 9:04 pm |
|
|
|
Guest
|
On Wed, 10 Dec 2003, Kostis Sagonas wrote:
> 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.
I would choose 2, which btw is the behaviour you get in this case if you
have set ERL_COMPILER_OPTIONS="[warn_unused_vars]". In the case where you
don't get that warning (for instance by using the variable earlier in the
function) I still like option 2.
It would be easy (and nice) to add a warning at all points where constant
propagation detects a possible (probable?) run-time error. I use the word
possible since I would like the warning in the case
test(A,B) ->
case B of
true -> a + 42;
_ -> A.
The above function is also a good example of why option 3 is bad. There
might actually be a reason that the programmer wants to generate a
run-time error in the case that B is true (I can't think of one, but...).
Anyway it would be bad to disallow program lines that might actually never
even be reached.
btw Since I am delurking I should probably say hi to the list. Hi list.
I am a last year student at Uppsala University, studying Computer Science
and Mathematics (in no particular order of preference). I recently took a
course in compiler techniques where we rewrote the constant propagation
pass on the ICode level for HiPE. This made me interested in Erlang so I
started lurking here.
My email log says that I have been lurking since July, but in reality I
have been deleting more than I have read; increasing my read/delete ratio
steadily. Up to almost 1 the last week (or "division by zero exception"
depending on how you count).
#Luna
--
Daniel Luna | Top reasons that I have a beard:
luna_at_update.uu.se | a) Laziness.
http://www.update.uu.se/~luna/ | b) I can.
Don't look at my homepage (it stinks).| c) I can get away with it.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thomasl_erlang at yahoo.c |
| Posted: Wed Dec 10, 2003 9:31 pm |
|
|
|
Guest
|
--- Luke Gorrie <luke_at_bluetail.com> wrote:
> Kostis Sagonas <kostis_at_user.it.uu.se> writes:
>
> > 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
I prefer (2) with an OPTIONAL warning, and otherwise
concur with Luke. CMUCL:s user interaction is the most
sophisticated I know of, so building on efficiency
notes etc. sounds like a good idea. (As a principle,
it is a bad idea to leave the programmer guessing
about what sort of tweaks should be made for good
performance.)
However, there are some problems. First, it should be
noted that Common Lisp has a much richer type system
than Erlang. Expressing that something is a fixnum or
a specialized sort of tuple is tedious in Erlang.
Second, the various type annotations one might want to
make are probably easier and more elegantly done with
macros in CL than in Erlang. Some easy way of
communicating those to the compiler is probably
needed.
In short, the compiler-user interaction is worth some
careful thinking.
Best,
Thomas
PS. As regards warnings in general, I would like two
more options:
- Warn when a variable occurrence is matched rather
than bound. This has turned out to be a bug more often
than I would have liked.
- Warn about unknown compiler options (currently just ignored)
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| taavi at uninet.ee |
| Posted: Wed Dec 10, 2003 9:44 pm |
|
|
|
Guest
|
On Wed, 10 Dec 2003, Daniel Luna wrote:
> It would be easy (and nice) to add a warning at all points where constant
> propagation detects a possible (probable?) run-time error. I use the word
> possible since I would like the warning in the case
>
> test(A,B) ->
> case B of
> true -> a + 42;
> _ -> A.
>
> The above function is also a good example of why option 3 is bad. There
> might actually be a reason that the programmer wants to generate a
> run-time error in the case that B is true (I can't think of one, but...).
> Anyway it would be bad to disallow program lines that might actually never
> even be reached.
Still disagree. Erlang specification does not disallow optimizing
compilers, which try to evaluate constant expressions compile time.
Language allready has special construct for throwing exceptions -
throw(...).
Why not force explicit usage of throw() instead of obscure evaluation
side effects?
best regards,
taavi
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| p0rj2el602 at sneakemail. |
| Posted: Thu Dec 11, 2003 3:39 am |
|
|
|
Guest
|
On ons, 2003-12-10 at 18:25, Kostis Sagonas wrote:
> 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
I liked the "perlang" suggestion  .
Seriously, my preference (in order) would be: #2, #3, #1. Or maybe #3
by default, but a compiler option to use #2.
I see three uses for writing such code:
1. As a programmer, one wants to know what exceptions will be generated
by certain error conditions, and/or how your program will react to
them. So one writes a little code that artificially generates such
errors. Such code is never released to the world.
2. As a tester, one may want to do much the same thing. I'm not really
sure that this case is really distinct from the first one, but in my
mind it is a different part of the process. Also, testers tend to be
rather less well versed in the subtleties of compiler behaviour, and
thus less capable of doing tricky things to "fool" the compiler.
3. One wants to generate a particular error in precisely the "standard"
format, regardless of how the internals of the erlang system may change
in future releases.
I believe that case #3 is so rare that it is unimportant (or perhaps it
is even non-existent). But while they are not something that I would
raise a fuss about, I'm not sure that the first two cases should be
ignored.
Just the other day, I was doing weird things to see what kind of NaNs
libm/pentium produce at runtime. I think I fooled gcc into actually
performing the nasty operations at run time instead of compile time (and
maybe it generates the same result even when it optimises the operations
away), but I may have made a mistake. It's nicer when one doesn't have
to play games with the compiler.
(BTW, the semantics of floating point in erlang seem to be rather messed
up. Is their any intention to clean it up some time? I usually just
try to pretend that erlang doesn't have floats).
On ons, 2003-12-10 at 22:44, Taavi Talvik wrote:
> Still disagree. Erlang specification does not disallow optimizing
> compilers, which try to evaluate constant expressions compile time.
>
> Language allready has special construct for throwing exceptions -
> throw(...).
>
> Why not force explicit usage of throw() instead of obscure evaluation
> side effects?
I agree that an explicit exit() is almost always better. But isn't
exit() what you want, not throw()? If so, this demonstrates the point
that people aren't really so aware of the correct way to simulate
errors. So it might be better (occasionally) if they can just write
straightforward code to generate a desired error condition.
/Lon
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ulf.wiger at telia.com |
| Posted: Thu Dec 11, 2003 6:11 am |
|
|
|
Guest
|
Lon, you saved me a lot of typing. I agree with all of what you wrote.
/Uffe
On Thu, 11 Dec 2003 04:39:00 +0100, Lon Willett
<p0rj2el602_at_sneakemail.com> wrote:
> On ons, 2003-12-10 at 18:25, Kostis Sagonas wrote:
>> 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
>
> I liked the "perlang" suggestion .
>
> Seriously, my preference (in order) would be: #2, #3, #1. Or maybe #3
> by default, but a compiler option to use #2.
>
> I see three uses for writing such code:
>
> 1. As a programmer, one wants to know what exceptions will be generated
> by certain error conditions, and/or how your program will react to
> them. So one writes a little code that artificially generates such
> errors. Such code is never released to the world.
>
> 2. As a tester, one may want to do much the same thing. I'm not really
> sure that this case is really distinct from the first one, but in my
> mind it is a different part of the process. Also, testers tend to be
> rather less well versed in the subtleties of compiler behaviour, and
> thus less capable of doing tricky things to "fool" the compiler.
>
> 3. One wants to generate a particular error in precisely the "standard"
> format, regardless of how the internals of the erlang system may change
> in future releases.
>
> I believe that case #3 is so rare that it is unimportant (or perhaps it
> is even non-existent). But while they are not something that I would
> raise a fuss about, I'm not sure that the first two cases should be
> ignored.
>
> Just the other day, I was doing weird things to see what kind of NaNs
> libm/pentium produce at runtime. I think I fooled gcc into actually
> performing the nasty operations at run time instead of compile time (and
> maybe it generates the same result even when it optimises the operations
> away), but I may have made a mistake. It's nicer when one doesn't have
> to play games with the compiler.
>
> (BTW, the semantics of floating point in erlang seem to be rather messed
> up. Is their any intention to clean it up some time? I usually just
> try to pretend that erlang doesn't have floats).
>
> On ons, 2003-12-10 at 22:44, Taavi Talvik wrote:
>> Still disagree. Erlang specification does not disallow optimizing
>> compilers, which try to evaluate constant expressions compile time.
>>
>> Language allready has special construct for throwing exceptions -
>> throw(...).
>>
>> Why not force explicit usage of throw() instead of obscure evaluation
>> side effects?
>
> I agree that an explicit exit() is almost always better. But isn't
> exit() what you want, not throw()? If so, this demonstrates the point
> that people aren't really so aware of the correct way to simulate
> errors. So it might be better (occasionally) if they can just write
> straightforward code to generate a desired error condition.
>
> /Lon
>
--
Ulf Wiger
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Thu Dec 11, 2003 7:47 am |
|
|
|
Guest
|
Hi,
From: "Lon Willett" <p0rj2el602_at_sneakemail.com>
> 1. As a programmer, one wants to know what exceptions will be generated
> by certain error conditions, and/or how your program will react to
> them. So one writes a little code that artificially generates such
> errors. Such code is never released to the world.
In such a case, I'd rather have a default configuration that doesn't support
such things (for production code) and a compiler option that makes it accept
such erroneous code.
regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| peter at lundata.se |
| Posted: Thu Dec 11, 2003 8:05 am |
|
|
|
Guest
|
I am certainly putting my money on no 1!
The case when "a + 32" craches my code will be easily detected
the first time I run that piece of code, and since I *do* test my
code before delivery, this is a non-problem. I would not like
having anyone wasting their valuable time improving the compiler
to catch this and also wasting more CPU power on everyones
computer when compiling.
/Peter
> 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 |
|
| Bengt.Kleberg at ericsson |
| Posted: Thu Dec 11, 2003 8:42 am |
|
|
|
Guest
|
Kostis Sagonas wrote:
> 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
i choose 3.
bengt
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
