| Author |
Message |
|
| ok at cs.otago.ac.nz |
 Posted: Fri Oct 24, 2003 3:26 am |
 |
|
|
Guest
|
-module(stdlib, "8.3"). % Needs 8.3 ERTS.
I hate this syntax, because it is so obviously declaring
the version of THIS module, not the version of Erlang.
Any method of declaring the version of the Erlang language that is
required should ideally have *erlang* in the name so that it is obvious
what it is the version *of*.
For example,
-erlang([8,3,10]). % Erlang 8.3J or later
-module(thingy, [10,2,27]). % This is thingy version 10.2.27
...
Like an XML declaration, this should go first.
A revised Erlang language might not even use -module for declaring
modules; some day we might see
-erlang([10,1]).
module StdLib (
foo/1, bar/2
) where
...
(with apologies to Haskell).
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Fri Oct 24, 2003 3:07 pm |
|
|
|
Guest
|
Chris Pressey wrote:
...deleted
> It's a good idea, but wouldn't it be easier to write code that works on
> different versions if it was done with macros, e.g.
>
> -ifdef(?ERLANG_5_3).
> % some code that uses bleeding-edge features here
> -else.
> -ifdef(?ERLANG_5_2).
> % some code that uses 5.2-isms here
> -else.
> % some code that is dangerously language-version-unspecific here
> -endif.
> -endif.
>
please do not allow this into erlang.
i have maintained (somebody elses) c code which used #ifdef, and i
promised myself never to do that again.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Fri Oct 24, 2003 3:50 pm |
|
|
|
Guest
|
Joe Armstrong wrote:
...deleted
> - A new version of the language turns up - with the 'try' statement.
> - I write a program using 'try' and use the latest compiler
> - I post my program to the net
> - I get mail saying that my program is ****ed up because it
> won't go through some old version of the compiler that was released
> before version numbering was introduced.
>
> This has already happened to me on several occasions - I have sent people
> program that use binaries - only to find that they are using a
> "pre-binaries" Erlang.
...deleted
would it not be true to say that you have written atleast one program
that have the opposite problem? using www_tools-1.0.tgz i had to update
the tcp code to R7.
i would also like to thank you for this module since it made it possible
to do what i wanted to do.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Fri Oct 24, 2003 4:31 pm |
|
|
|
Guest
|
WILLIAMS Dominic wrote:
...deleted
> 2) Functions would be deprecated by adding an obsolete attribute that
> would list obsolete functions in the same format as export/import:
>
> -module(my_module).
> -export([a/1,b/2,c/3]).
> -obsolete([b/2]).
>
the eiffel keyword ''obsolete'' has an argument that explains what
alternatives there are, instead of the obsolete feature. perhaps
somehting like this (yes, i know this makes it impossible to obsolete a
whole slew of functions in one go. but see my second example for an
alternative):
-module(my_module).
-export([a/1,b/2,c/3]).
-obsolete(b/2, "use c/2 instead").
moreover, eiffel can obsolete a whole class. which could be quite handy:
-module(my_module).
-obsolete("use my_other_module instead").
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Fri Oct 24, 2003 4:51 pm |
|
|
|
Guest
|
On Fri, 24 Oct 2003 15:42:49 +1300 (NZDT)
"Richard A. O'Keefe" <ok_at_cs.otago.ac.nz> wrote:
> Chris Pressey <cpressey_at_catseye.mine.nu> suggested:
> It's a good idea, but wouldn't it be easier to write code that
> works on different versions if it was done with macros, e.g.
>
> -ifdef(?ERLANG_5_3).
> [snip]
> -endif.
>
> I think this would be the way to go if you wanted to write code
> that takes advantage of new features while still being able to
> compile and run on older installations.
>
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!
Gee Richard A. O'Keefe, you sound a bit stressed. Maybe you should make
yourself a nice hot cup of peppermint tea and re-read my "suggestion"
(as you call it) paying closer attention to how I used the word "if".
> Someone please tell me this was a late April Fools' joke?
Let me put it this way: if it's easy to tell when I'm being serious and
when I'm not, I'm not doing my job. I AM a Bishop, after all.
> If would be nice if people finally understood why the Ada requirements
> explicitly required that there *NOT* be a preprocessor or conditional
> compilation facility...
Yes, it would be nice. I think I've done my part by understanding it
fairly well. However, I'm also not very optimistic about seeing
invariant expressions in Erlang any time soon.
Ah, but the rivers of the Erlang support list are choked with the bodies
of keyboard-pounding language designers, are they not? Guardians of
Truth and Beauty, each and every one of us, who do not seem to realize
that Erlang is not a project in pursuit of perfect language purity. It
is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?)
And defining a new predefined macro is just about as small an investment
there is.
Take it one small step further and add -assert() to -ifdef() and
friends, and I for one have a hard time explaining the difference
between
-requires_erlang('5.3').
and
-assert(?ERLANG_VERSION, '5.3').
in terms that the average non-language-designing Erlang programmer would
appreciate or care about. So it would seem to me that this small
investment gets a comparable return. Perhaps even a greater one, when
you consider the same -assert() mechanism can be used for any other
macro already in use, predefined (like ?MACHINE) or otherwise.
So there you have a plausible case for using macros.
Of course, if you think that just because I can make that case means
that that's the way I truly feel, you're a bigger sucker than I thought.
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Fri Oct 24, 2003 4:53 pm |
|
|
|
Guest
|
On Fri, 24 Oct 2003 11:07:38 +0200
Bengt Kleberg <Bengt.Kleberg_at_ericsson.com> wrote:
> Chris Pressey wrote:
> ...deleted
> > It's a good idea, but wouldn't it be easier to write code that works on
> > different versions if it was done with macros, e.g.
> >
> > -ifdef(?ERLANG_5_3).
> > % some code that uses bleeding-edge features here
> > -else.
> > -ifdef(?ERLANG_5_2).
> > % some code that uses 5.2-isms here
> > -else.
> > % some code that is dangerously language-version-unspecific here
> > -endif.
> > -endif.
> >
>
> please do not allow this into erlang.
It's too late - it's already there!
<lugosi>THE HORROR THE HORROR</lugosi>
> i have maintained (somebody elses) c code which used #ifdef, and i
> promised myself never to do that again.
OOC, were you using a syntax-colouring editor at the time?
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| luke at bluetail.com |
| Posted: Fri Oct 24, 2003 5:07 pm |
|
|
|
Guest
|
Bengt Kleberg <Bengt.Kleberg_at_ericsson.com> writes:
> i have maintained (somebody elses) c code which used #ifdef, and i
> promised myself never to do that again.
They have this in Common Lisp too. The other week I was trying to
understand a single function that was 170 lines long and contained no
fewer than 43 ifdef-style conditionals.
"Not very nice."
By the way, I've found a really fun new way of inspecting programs:
http://groups.google.com/groups?q=teleport.el&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=lhoexds818.fsf%40dodo.bluetail.com&rnum=1
(Joe, I think you might like it  )
Cheers,
Luke (who'd be remiss not to mention Emacs `hide-ifdef' mode, for when
you need to read heavily ifdef'ified C)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joachim.durchholz at web. |
| Posted: Fri Oct 24, 2003 10:27 pm |
|
|
|
Guest
|
Bengt Kleberg wrote:
> WILLIAMS Dominic wrote:
> ...deleted
>
>> 2) Functions would be deprecated by adding an obsolete attribute that
>> would list obsolete functions in the same format as export/import:
>>
>> -module(my_module).
>> -export([a/1,b/2,c/3]).
>> -obsolete([b/2]).
>
> the eiffel keyword ''obsolete'' has an argument that explains what
> alternatives there are, instead of the obsolete feature. perhaps
> somehting like this (yes, i know this makes it impossible to obsolete a
> whole slew of functions in one go. but see my second example for an
> alternative):
>
> -module(my_module).
> -export([a/1,b/2,c/3]).
> -obsolete(b/2, "use c/2 instead").
>
> moreover, eiffel can obsolete a whole class. which could be quite handy:
>
> -module(my_module).
> -obsolete("use my_other_module instead").
I have been programming in Eiffel for several years, so some experience
reports may be in order.
1. In Eiffel, the "obsolete" keyword has no semantic effect whatsoever.
However, the Eiffel compiler will emit a warning whenever it sees a call
to an obsolete feature. (One thing that could have been improved: if an
obsolete routine called another obsolete routine, that call would also
be flagged with a warning. Presumably, such calls should /not/ be
marked... but that's really a minor nit to pick.)
An important point is that the remark given with the "obsolete keyword"
is given as part of the warning message. The programmer will see the
warning and can decide immediately whether anything should be done about
the issue, without having to go into the source code of the obsolete
function.
2. For library designers, "obsolete" is a godsend. It will deflect most
bug reports, change requests, and other communication from application
programmers even before it hits the support line. If a programmer ever
has a problem with an obsolete routine, he will prefer upgrading to the
"approved" routines to any support calls.
(Of course, some people will call anyway. But the support load reduces
substantially.)
3. For application programmers, "obsolete" is a godsend as well. The
remark on the "obsolete" keywords usually gives enough information that
he knows what to do, without bothering to call support (and wait until a
solution is available).
4. A warning to library developers: don't expect to ever get rid of a
function marked obsolete anyway. There will be software that has been
running untouched for a decade, and that will continue for decades to
come. Functions marked obsolete are still there to stay, just like
Fortran 
If you want to really phase out some function, use a mechanism that goes
beyond "obsolete", or add an option that turns the warning into
something more severe. Or make the standard obsolescence warnings be
emitted as "remark" and turn it into a "warning" when phasing out the
function is imminent for the next release. Or whatever - in any case,
provide for a distinction between mild obsolescence reminders and stern
warnings that a function Won't Be Available Anymore.
Regards,
Jo
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Bengt.Kleberg at ericsson |
| Posted: Fri Oct 24, 2003 10:51 pm |
|
|
|
Guest
|
Vlad Dumitrescu wrote:
> From: "Shawn Pearce" <spearce_at_spearce.org>
>
...deleted
>>It might also be nice to define other dependencies such as:
>>
>>-require(stdlib, "5.3").
>>
>>to indicate that this module would need a version of stdlib that understand
>>the calls available in version 5.3 of stdlib.
>
>
> Mmm, wouldn't there be confusions with the stdlib application's version? After
> all, as user of stdlib, I don't care what it's using inside, just what
> interfaces it has. So in this case i'd expect to check stdlib's version - but if
i do not think anybody would expect ''require'' to check anything _but_
the interface to a module. the implementation is surely uninteresting
for this purpose?
note that, imho, the first argument to ''require'' should be the
smallest part that is distributed. currently erlang is a monolith (but i
hope this changes rsn , so only
-require(erlang, "R9A").
would make sense.
when we get seperate pieces of erlang, it would make sense to use
''stdlib'', or something (''core''?).
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| robert.virding at telia.c |
| Posted: Sun Oct 26, 2003 11:56 pm |
|
|
|
Guest
|
----- Original Message -----
From: "Chris Pressey" <cpressey_at_catseye.mine.nu>
To: "Richard A. O'Keefe" <ok_at_cs.otago.ac.nz>
Cc: "Erlang-Questions" <erlang-questions_at_erlang.org>
Sent: Friday, October 24, 2003 5:53 PM
Subject: Re: Language change proposal
> Ah, but the rivers of the Erlang support list are choked with the bodies
> of keyboard-pounding language designers, are they not? Guardians of
> Truth and Beauty, each and every one of us, who do not seem to realize
> that Erlang is not a project in pursuit of perfect language purity. It
> is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?)
>
> And defining a new predefined macro is just about as small an investment
> there is.
>
> Take it one small step further and add -assert() to -ifdef() and
> friends, and I for one have a hard time explaining the difference
> between
>
> -requires_erlang('5.3').
>
> and
>
> -assert(?ERLANG_VERSION, '5.3').
>
> in terms that the average non-language-designing Erlang programmer would
> appreciate or care about. So it would seem to me that this small
> investment gets a comparable return. Perhaps even a greater one, when
> you consider the same -assert() mechanism can be used for any other
> macro already in use, predefined (like ?MACHINE) or otherwise.
>
> So there you have a plausible case for using macros.
Being the original "Guardian of Truth and Beauty" I think you have missed the point, at least how I see it. If you want Erlang to be a good return-on-investment over a long term then you have to be very strict about what you allow in the language. Otherwise it will become full of little "features" that, separately, are all innocent but put together result in a complete mess, which is difficult to understand and maintain. And macros are definitely in this this category.
Mind you this coming from the person who actually added macros to the language! To my defence I must say that I didn't want them myself and never really saw the benefit. They made me do it. Being in a playful mood I gave them much more than they originally asked for, for example arguments, and there is only one thing I really missed and that is allowing macros of the same name with different number of arguments. If you are going down you might as well do it properly.
But I still say the preprocessor should never have been added. Richard where is the Ada reasoning about a preprocessor described? If I had been able to come up with Richard O'Keefe's Abstract Data Types this would have been a much better solution.
In contrast to Joe though I don't see size in itself to be the main problem. The main things to worry about are to be extremely clear about the basic concepts in your language and keeping to them, and in being consistent. If two different things look similar then they should behave similarily, and vice a versa. That was one of my main critisms about the type checking in patterns, it broke the model of being able to put terms together and pull them apart by the same construct. I think that if you ARE clear and consistent then there is no basic problem in adding new features. Of course it is another question whether you NEED the new features. Implementing the union of everyones requests is a bad idea.
This is one of the problems I see with ETS tables. They don't fit into the basic Erlang model of how data is organised. Data is local to processes while ETS tables are outside. It is my view (and here I do agree with Joe that everything should look like a process, i.e. you communicate with messages and you can link to it.
This is why you need guardians so that it will be clear and consistent. As I have said before one of our, the original implementors, main faults was not actually explaining and writing down our basic concepts. To us they were so clear they need no explanantion. Of course sometimes we weren't in agreement as to the concepts. :-)
Robert
P.S. I also implemented records. Not my idea either. A struct like term would have been much better but there were reasons for not doing that, which I again think were wrong.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ok at cs.otago.ac.nz |
| Posted: Fri Oct 31, 2003 9:46 am |
|
|
|
Guest
|
"Robert Virding" <robert.virding_at_telia.com> wrote:
But I still say the preprocessor should never have been added.
Richard where is the Ada reasoning about a preprocessor
described? If I had been able to come up with Richard O'Keefe's
Abstract Data Types this would have been a much better solution.
The requirement was stated in Steelman 2C.
(http://www.adahome.com/History/Steelman/steelman.htm#2)
2C. Syntactic Extensions. The user shall not be able to modify
the source language syntax. In particular, the user shall not be
able to introduce new precedence rules or to define new syntactic
forms.
Basically, they didn't want an extensible language (like Algol 68 or CGOL,
which let you introduce new operators, or like Pop with its templates
which I actually found very nice to use). If we are going to talk about
return on investment, that's precisely what this is all about. They wanted
to make sure that there were no unnecessary barriers to building tools that
could analyse Ada source code, and that every maintainer would be reading
the same language.
I find the fact that I can't build an Erlang analysis tool without
having to emulate all that preprocessor fertiliser incredibly sad;
put the preprocessor and records together, and you've roughly doubled
the size of a simple tool. Yes, I know it's easy if you do it in Erlang
using the appropriate existing module. But that simply emphasises how hard
it is to do it any _other_ way.
>From http://www.faqs.org/faqs/computer-lang/Ada/programming/part3/
question 8.7:
.7: Does Ada have macros?
No, neither Ada 83 nor Ada 95 do. There was a Steelman requirement
that the language developed NOT have a macro capability. This was a
well thought-out requirement. What you see in a piece of Ada code is
what you get (within a debugger for example). This does not hold true
for macro languages.
General text-substitution macros like those in the C preprocessor are
thought to be too unsafe. For example, a macro can refer to a variable
X and depending where the macro is expanded X may or may not be
visible. Ada programs are supposed to be readable and in many cases C
macros are the main culprits in producing unreadable C programs.
Compile time macro facilities tend to be dreadfully over- and misused,
resulting in horrible maintenance problems. Furthermore, there is a
tendency to use macros to patch up glaring omissions in the language.
For example, C has no named constants, a very bad omission, but
#define is used to patch over this gap.
In C, three "legitimate" uses of macros are for defining compile-time
constants, types, and inline functions. Ada has all three of these
facilities, without macros.
If one wants macros to handle conditional compilation, the better way
to achieve the equivalent is in most instances to isolate the system
dependent parts and then put them in separate units with multiple
system-specific implementations.
Because Erlang has pattern matching, inline functions are not quite good
enough to handle compile-time constants. That's what Abstract Patterns
were invented for. Cross-module inlining would be made possible by the
-import_early directive I once described.
This is why you need guardians so that it will be clear and
consistent. As I have said before one of our, the original
implementors, main faults was not actually explaining and
writing down our basic concepts. To us they were so clear they
need no explanantion. Of course sometimes we weren't in
agreement as to the concepts. :-)
It's surely not too late to write them down now.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ok at cs.otago.ac.nz |
| Posted: Fri Oct 31, 2003 9:46 am |
|
|
|
Guest
|
Chris Pressey persists:
Ah, but the rivers of the Erlang support list are choked with
the bodies of keyboard-pounding language designers, are they
not? Guardians of Truth and Beauty, each and every one of us,
who do not seem to realize that Erlang is not a project in
pursuit of perfect language purity. It is, in fact, an exercise
in return-on-investment (right, Mr. Ericsson?)
False dichotomy.
And defining a new predefined macro is just about as small an
investment there is.
Predefined macros aren't *investments*, they are *penalties*.
Take it one small step further and add -assert() to -ifdef() and
friends, and I for one have a hard time explaining the difference
between
-requires_erlang('5.3').
and
-assert(?ERLANG_VERSION, '5.3').
in terms that the average non-language-designing Erlang
programmer would appreciate or care about.
It is incredibly simple. -assert (which does not and should not exist;
we should be looking for ways to excise the preprocessor cancer, not
pumping it full of growth hormones) can appear too late. You *CAN'T*
check Erlang version using a feature whose very removal is one of the
things you want to protect against.
Oddly enough, when it comes to reading an Erlang source file, an Erlang
processor has the same two problems that an XML processor has when reading
an XML document.
(1) What character set encoding was used?
One of the long term goals for Erlang is that it should support Unicode;
many existing Erlang users already combine Erlang and XML (hence xmerl,
amongst others), and XML requires Unicoode. If you are going to process
XML in Erlang, it is helpful if you can represent XML identifiers as
Erlang atoms, and at a minimum you need to be able to hold Unicode
characters in strings.
I'd be happy with ISO Latin 1 as the default encoding, but I suppose
Windows programmers wouldn't be, and in today's Europe, it could be
useful to be able to mention the Euro, so 8859-15 might be a good
choice; need I go on?
(2) Which version of the language specification is to be used?
There is no reason to expect that every future version of Erlang
will _have_ a preprocessor. The "erlang declaration" still needs
to be usable, so it _can't_ use a preprocessor kluge.
We come up with the fairly obvious result that something like
-erlang(Encoding, Version).
is needed, where "-erlang(" must literally be the first 8 characters of
the source file, the Encoding written as an unquoted Erlang atom follows
with no spaces, and then the language version. This also has the nice
effect of making it easy to tell the UNIX 'file' command how to
recognise Erlang source files.
By the way, whatever you call "assert", it's not a macro.
If Chris Pressey _doesn't_ want to see the same kind of preprocessor
mess that makes maintaining other people's C code a challenge, he should
not have wasted our time suggesting it.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joachim.durchholz at web. |
| Posted: Fri Oct 31, 2003 11:38 am |
|
|
|
Guest
|
Richard A. O'Keefe wrote:
> One of the long term goals for Erlang is that it should support Unicode;
This is something that I'd advise against.
True, it would be nice to be able to write your source code using
native-language identifiers witout having to worry about ASCII
representation.
However, there are two problems here:
1) If somebody gives me software to maintain, I might hit a, say,
Chinese glyph somewhere. I'd have to download the proper font just to be
able to look at the sources.
I have programmed in Java, which also uses Unicode. I tend to avoid the
German special characters |
|
|
| Back to top |
|
| cyberlync at yahoo.com |
| Posted: Fri Oct 31, 2003 2:46 pm |
|
|
|
Guest
|
> (There's also a portability issue: there are still
> EBCDIC machines
> around that don't support Unicode. I don't think
> this is relevant for
> Erlang though *g*)
EBCDIC is far, far from dead. Its usually only used
on big iron like a 390 but its still used in the
midrange realm on the as400s too. I wouldn't mind
seeing erlang for 400s or 390s. Then you have some of
the most reliable code running on some of the most
reliable hardware on the planet.
And no, this hardware is not old. Both of these
platforms still see quite allot of use. IBM still
releases upgrades and creates new versions. In fact,
right now, the as/400 is probably the best general
midrange server product available. I would say the
same about the 390 on the high end.
In any case, allot of systems still use EBCDIC.
> My personal idea about Unicode is that it is
> massively overengineered
> for simple tasks like representing source code.
> With one exception: it would be very nice if the
> language allowed
> Unicode within string literals. That's more a
> question of how to
> integrate binary data into source code well.
I tend to agree. Why introduce complexity where none
is needed. ASCII is probably the simplist solution
that works, why switch it for something much more
complex.
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Fri Oct 31, 2003 8:20 pm |
|
|
|
Guest
|
On Mon, 27 Oct 2003 12:53:36 +0100
"Robert Virding" <robert.virding_at_telia.com> wrote:
> ----- Original Message -----
> From: "Chris Pressey" <cpressey_at_catseye.mine.nu>
> > [...]
> > So there you have a plausible case for using macros.
>
> Being the original "Guardian of Truth and Beauty" I think you have
> missed the point, at least how I see it. If you want Erlang to be a
> good return-on-investment over a long term then you have to be very
> strict about what you allow in the language. Otherwise it will become
> full of little "features" that, separately, are all innocent but put
> together result in a complete mess, which is difficult to understand
> and maintain.
No doubt in most sane peoples' minds that this is how companies
(/language projects/companies that oversee language projects) *should*
operate - take the long view. The question is - do they? Indeed, given
how management tends to operate, can they? And, of course the burning
question is - will Ericsson?
I don't just like Erlang because it's a beautiful language. I like it
because it's a battle-tested production language that happens to be
about two to three times more beautiful than the "national leading
brand", even counting the warts.
Given a choice between a wart-free Erlang and a bug-free Erlang, I'll
take the bug-free one. Of course, that's a bit of false dilemma, but
it speaks to where we concentrate our efforts - the more people
concerned with how to make/keep Erlang small/beautiful/expressive/
orthogonal/cutting-edge, the fewer people submitting bug reports/fixes
which will improve Erlang in the day-to-day humdrum of development.
Yes, getting rid of the warts would be great - but will it ever become
the corporate priority? I'm hoping yes, but guessing no. I'm concerned
specifically that Joe's suggestion will be seen as complicating matters
unnecessarily for paying customers. Which may or may not be the case,
depending on the magnitude of the changes from one version to the next.
But it does seem reasonable to not want to force your customers to fix
things that, from their point of view (expediency), ain't broke. At
least, not without offering them an alternative, like a bugfix branch of
the last "unversioned" Erlang/OTP.
Joe's suggestion is also interesting in that it's something you can, for
the most part, already do dynamically:
erts_version() ->
{ok, L} = file:list_dir(code:root_dir()),
lists:foldl(fun
("erts-" ++ V, A) ->
case list_to_float(V) of
R when R > A -> R;
_ -> A
end;
(_, A) -> A
end, 0.0, L).
start() ->
case of erts_version() of
V when V < 5.3 ->
erlang:fault({requires_erts, 5.3});
V ->
continue()
end.
But I dasn't expound on this hack, lest my trolling further waste the
reader's precious time - time that could be used for putting the
finishing touches on your Hallowe'en costume, or submitting patches to
make erlang:open_port/2 work correctly under Windows! :)
-Chris
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
