| Author |
Message |
|
| Guest |
 Posted: Thu May 06, 2010 2:44 am |
 |
|
|
Guest
|
On May 5, 2010, at 10:20 PM, Robert Virding wrote:
> This was the main reason that = is used in the record syntax. While ~
> may look strange using : will cause problems. How about =? Though this
> may force you to parenthesize some expressions.
That would certainly ease the transition from records to frames.
Ease of transition was a big feature of Joe Armstrong's proposed
syntax.
When I tried rewriting existing code to use frames instead of
records, I actually found it helpful to be using a *different*
symbol so that I could look at a multiline pattern or expression
and tell at a glance whether I had converted it or not.
Why do we find it easier to argue about the colour of the paint
for the Ark than to climb aboard?
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 2:59 am |
|
|
|
Guest
|
On May 6, 2010, at 8:52 AM, Sergey Samokhin wrote:
> Actually I would prefer not to be limited by "keys are only atoms"
> rule (but still having pattern-matching functionality).
Remember what the frames proposal is FOR.
It is NOT a "dictionaries" or "hash tables" proposal or anything
even remotely like that.
It's a "clean replacement for the -record kluge" proposal.
To that end, _fast_ construction and matching and _low_ memory
requirements are "must haves". The report explains this in some
detail.
There could well be some kind of pattern matching support for
dictionaries. However, that's a DIFFERENT purpose with DIFFERENT
tradeoffs.
> For example,
> dictionary where keys can be strings is superior for representing JSON
> documents, that, say, can be fetched from MongoDB and have a lot of
> long strings as keys.
The frames proposal is NOT about JSON.
It's about replacing Erlang -records.
There are proposals on the table (again, one from Joe Armstrong,
and one from me that goes into some detail about implementation)
for allowing large numbers of possibly large atoms -- that one is
an EEP. If/when that's implemented, frames would become usable
for JSON, representing those strings as dynamic atoms. But that's
pretty much a lucky accident.
You might want to think about reducing the size of those JSON
keys in order to reduce transport costs.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 8:46 am |
|
|
|
Guest
|
>
> Actually I would prefer not to be limited by "keys are only atoms"
> rule (but still having pattern-matching functionality). For example,
> dictionary where keys can be strings is superior for representing JSON
> documents, that, say, can be fetched from MongoDB and have a lot of
> long strings as keys.
>
> --
> Sergey Samokhin
>
>
I hope you realize keys in mongodb are a part of the document that gets
saved as well. So you're wasting a lot of space if you're using long key
names in documents.
Sergej
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 9:46 am |
|
|
|
Guest
|
I see that there are four questions we are discussing here. So our
decision tree would be:
#1. Do we need a special syntax for dictionaries?
Thing that lead me to wish a special syntax for dictionaries was
JSON/YAML documents, where keys are strings (or even integers stored
as strings). JSON is a good example, so I will use it to illustrate
where dictionaries can be useful.
When to use:
* You don't know for sure *how many* keys there will be.
JSON can be sent to you through RESTful interface with a lot of fake
keys, and you don't want to store them as atoms in the global atom
storage.
* You don't know for sure *what* keys there will be.
Sometimes key you have is a combination of different nested keys. In
Redis database it's common to use keys like "user/name". Some subkeys
can be integers. There can be something behind the string
representation, so you may want to parse the key. Atoms aren't
strings, so what you can do on it is limited.
* You want to have pattern matching
Manipulation such a JSON-documents without pattern matching is a pain.
With dictionaries you shouldn't be restricted to atoms as keys. If
your keys are known for your program, you probably want something more
suitable for structures like frames/structs.
#1.1 If we need syntax for dictionaries, what syntax to use?
#2. Do we need first class replacement (frames/structs) for records?
Yes, because records have some well known runtime restrictions.
#2.1 If we need frames/structs, what syntax to use?
So dictionaries are more "dynamic", when frames/struct are more "static".
> Remember what the frames proposal is FOR.
> It is NOT a "dictionaries" or "hash tables" proposal or anything
> even remotely like that.
Actually my previous message wasn't about "let's use term() for keys
in frames". I really would like to have both of them implemented. I
wrote the first message because I felt the lack of syntax for
dictionaries.
> It's a "clean replacement for the -record kluge" proposal.
I would be happy to have first-class replacement for records in Erlang.
> To that end, _fast_ construction and matching and _low_ memory
> requirements are "must haves". |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 9:49 am |
|
|
|
Guest
|
> I hope you realize keys in mongodb are a part of the document that gets
> saved as well. So you're wasting a lot of space if you're using long key
> names in documents.
I know about the drawbacks of using long keys, so I use short keys =)
--
Sergey Samokhin
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 12:43 pm |
|
|
|
Guest
|
> You must hate the <<...>> used for binaries, then.
I don't, so it's probably because <{ uses two *different* characters
that I find it a little peculiar.
> What semicolon? ":" is a colon.
My mistake. I meant colon, and no idea why I typed semicolon.
> I'm not sure what brackets [] have to do with it; if you
> mean there are no parentheses, there's not the slightest
> reason why there should not be:
Parentheses. British usage of the word "brackets" usually means
parentheses. Sorry for the additional confusion.
What I meant was that <<{erlang:list_to_integer}>> can't be confused
with a function call because there are no parentheses. But as Robert
clearly explains, the key point is that the values *can* be function
calls, which gives rise to ambiguity. That's the "problem" that I did
not forsee with using colons that I was asking about in my first
question.
> Why do we find it easier to argue about the colour of the paint
> for the Ark than to climb aboard?
Just because syntax might be a relatively trivial issue does not mean
that it can't be discussed and alternatives considered/compared. I
don't have anything to add to the "more important" discussion on
"should we add frames/structs?" because I think they are a sound idea
in principle and would much prefer using them to records.
It is also my opinion that using a tilde is not the best syntax to use
for seperating the keys and values. Whilst it can't be confused with
any existing syntax, I don't think it makes the meaning of the code
very clear. Looking at <{foo ~ bar}> doesn't make me think of "a key/
name mapped to a value". It looks more like some binary operator.
Tim
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 12:46 pm |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 10:47 pm |
|
|
|
Guest
|
On May 6, 2010, at 1:18 PM, Tony Arcieri wrote:
> On Mon, May 3, 2010 at 5:10 PM, Richard O'Keefe <ok@cs.otago.ac.nz>
> wrote:
> My proposal for 'frames' has been sitting around for years.
> but it's NOT a hashmap because it's NOT mutable
>
> I'm kind of confused as to what you're saying here. Dicts aren't
> mutable either.
Did I say they were?
>
> When you say "frames" wouldn't be mutable, how does that differ from
> dicts (or for that matter, records)
I nowhere said that frames differed from either dicts or records
*in this respect*. I just said they weren't hashmaps.
java.utils.HashMap is a well known Java class -- indeed, that is where
the "word" hashmap comes from, before Java's class, people talked about
hash tables or tables or hashes or dictionaries mostly. And hashmaps
support put() and remove() mutation operations.
If it comes to that, frames aren't _any_ kind of hash table, as
in order to achieve the best space efficiency I could think of they
do not use any form of hashing at all. This is another way in which
they differ from dicts: you aren't really _expected_ to access one
field at a time, you're expected to access _several_ fields. The
report has one extended example. It's not the only one I've done.
A manual optimisation I found often useful was to replace
f(..., R, ...) ->
... use R's f ...
... use R's g ...
... use R's h ...
by
f(..., R = <{f ~ F, g ~ G, h ~ H}>, ...) ->
... use F ...
... use G ...
... use H ...
Indeed, I did at one time think of allowing
(frame-valued expression) ~ field
with the obvious meaning, but dropped it in order to encourage
this more efficient style. Of course a compiler can perfectly
well gather all the field accesses on a path and put them into
an earlier match, EXCEPT that this changes the failure behaviour
of the program: if R doesn't _have_ an h field the upper
example will crash when you try to get it, but the lower one
will crash in the function's head, which is, other things being
equal, a better thing to do. It also meant that I didn't have
to give two related-but-confusingly-different readings to ~ .
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| rvirding |
| Posted: Fri May 07, 2010 12:56 am |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
As has been mentioned we are actually discussing the syntax of two
separate things here: frames/structs and dicts/"hashmaps".
Frames/structs are an extension/replacement/improvement on records.
Both give you a structure with named fields but where records are
compile time and static not Erlangy, structs/frames are runtime and
dynamic and much more in keeping with Erlang. But they are not an
alternative to dicts, or at least they were not envisioned to be that.
One fear I have always had with frames/structs (honestly I have  )
is that people would start using them as an alternative to dicts for
which they were not intended, though I was thinking more of the
problems of implementing them. That being said I am still all for them
and will gladly take a discussion on syntax and properties. I will
even accept the ~.
I personally don't think that we need or should have a special syntax
for dicts, it would in one sense defeat the purpose of them. My basic
principle has been that there is no "best" implementation of a dict so
by having a number of different implementations with the same
interface so the could more easily test and choose. I will soon (real
soon now) be adding a tree dict.
Another reason for not wanting a special syntax for dicts/hashmaps is
that I would like to avoid adding more special syntax where it isn't
absolutely necessary and I don't feel that these really need it.
Robert
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
   
|
| Guest |
| Posted: Fri May 07, 2010 5:05 am |
|
|
|
Guest
|
On May 6, 2010, at 9:44 PM, Sergey Samokhin wrote:
> * You don't know for sure *how many* keys there will be.
>
> JSON can be sent to you through RESTful interface with a lot of fake
> keys, and you don't want to store them as atoms in the global atom
> storage.
We shouldn't have to care about that.
There is a great gaping bleeding vulnerability at the heart
of Erlang: it SHOULDN'T be possible to bring down a system
by sending it a lot of distinct atoms, but it IS.
It doesn't have to be that way.
EEP 20, by someone whose initials look a lot like mine,
says
An idea from the Logix implementation of Flat Concurrent
Prolog can be adapted to Erlang: invisibly to users there
can be two implementations of 'atoms', fixing a major
system integrity issue and removing the need to warp one's
data structure design to code around it.
Historically, many Prolog systems had a similar limitation.
When I got a copy of Brand X Prolog for the Macintosh, about the
10th thing I tried was creating more atoms than its atom table
could hold. Brand X Prolog not only crashed, it managed to wipe
itself off the disc on the way to the grave, so I was never able
to try any other tests. (Silly me, I had thought that since I
wasn't trying to change anything on that floppy, it would not change.)
A couple of years ago, Jan Wielemaker fixed SWI Prolog, so that it
DOES garbage collect atoms, and it is now common practice to use
atoms all over the place, in large numbers. This despite the fact
that SWI Prolog also has (sadly pthread-like) concurrency.
So "we need to use something other than atoms for JSON labels" is
a *temporary* concession to a bug in the surviving Erlang
implementation (GERL and Erlang-over-Scheme apparently being dead)
which has less excuse for remaining every day. I don't think we
should allow a bug that's overdue for fixing to warp the design of
*future* language changes.
>
> * You don't know for sure *what* keys there will be.
Then we are definitely talking about dictionaries. But if you
don't know what the keys will be, you can't write them in patterns
or expressions, so what good would special syntax be?
>
> Sometimes key you have is a combination of different nested keys.
Nested keys should be handled by nested dictionaries each with a
simple key. For example, in Java on my old machine,
System.getProperties.list(System.out) shows me 48 keys (and their
values) in an apparently random order. Suppose they were factorised
file/...
java/...
user/...
line/...
os/...
sun/...
Each level would be easier to grasp, and groups of properties, like
java/vm/... and os/... and user/... would actually make sense. And
each level would be so small that simple linear search would work
well. As a frame, we'd have
<{ file ~
<{ encoding ~
<{ '.' ~ _1
, pkg ~ _2 }>
, separator ~ _3 }>
, java ~ ...
, line ~ ...
, os ~ ...
, sun ~ ...
, user ~
<{ country ~ _U
, dir ~ _V
, home ~ _W
, language ~ _X
, name ~ _Y
, timezone ~ _Z }> }>
> In
> Redis database it's common to use keys like "user/name". Some subkeys
> can be integers. There can be something behind the string
> representation, so you may want to parse the key. Atoms aren't
> strings, so what you can do on it is limited.
Non-sequitur. There is nothing that can be done with strings that
*couldn't* be done with atoms. For example, in Haskell, practically
everything you might want to do with a list of characters (String)
can be done with a Data.ByteString. In particular, there's no reason
why you couldn't be allowed to concatenate atoms, slice out subatoms,
and do regular expression matching on atoms. *IF* the global limited
atom table weren't a scarce and vulnerable resource, it would make
perfect sense to do these things. SWI Prolog even lets you read
a term as an atom. (Makes me queasy, but it _works_.)
>
> * You want to have pattern matching
> Manipulation such a JSON-documents without pattern matching is a
> pain.
I've done a fair bit of XML processing in Prolog, and for that matter,
in C. (I have my own faster-than-expat parser and my own "Document
Value Model" library. It's amazing what you can do with XML
_conveniently_
in C.) JSON is really very like XML. They are *both* hard to process
with or without patterns, for the same reason: they are only
semistructured
and there can be all sorts of extra cruft there. For example, I'm
currently working with 100,000 US patents, marked up in XML. You would
think "where is *the* ECLA code saying what this is about" would be a
simple matter of fishing quickly in the meta-data, but it isn't, and for
what I actually have to do to get a best-guess at the value, no
plausible
pattern language would be a substantial improvement on the actual code I
have.
There's an old statistician's saying:
raw data are like raw potatoes,
they're no use until they're cleaned.
It applies to open semistructured data coming into a computer program
as well: first thing you do is extract just the data you want and
clean it up to make life as easy as possible for down-stream code.
(Hint: the letters "JS" in "JSON" stand for what? That has what
pattern matching facilities? Programmers using it complain about
the difficulty of using JSON data how much?)
> With dictionaries you shouldn't be restricted to atoms as keys.
With dictionaries, you aren't. Never have been, never will be.
> If
> your keys are known for your program, you probably want something more
> suitable for structures like frames/structs.
>
> #1.1 If we need syntax for dictionaries, what syntax to use?
Something extensible. There can be more than one kind of dictionary.
(As a trivial example: are keys matched using ==, or =:=, or something
else, which might perhaps ignore alphabetic case?)
>
> #2. Do we need first class replacement (frames/structs) for records?
>
> Yes, because records have some well known runtime restrictions.
>
> #2.1 If we need frames/structs, what syntax to use?
>
> So dictionaries are more "dynamic", when frames/struct are more
> "static".
That's a fair characterisation. While it is always possible to add any
key to any frame (getting a new frame), and while it is possible for a
frame to have keys that the receiver was not expecting, the _creator_ of
a frame must have a specific set of keys in mind. (Although there is a
pattern-like syntax and ALSO a fully dynamic set of functions.)
> Actually my previous message wasn't about "let's use term() for keys
> in frames". I really would like to have both of them implemented. I
> wrote the first message because I felt the lack of syntax for
> dictionaries.
I recommend writing a few modules *pretending* that such a syntax
exists and see what it ends up looking like. You'll keep on changing
your mind for a while, but eventually something will gell.
> I couldn't find your report. Could you post the link here?
Here it is again:
www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
> Actually, the size of my JSON keys is small. I'm just a bit afraid of
> using atoms, because atoms aren't garbage collected and atoms aren't
> that good for string processing (regular expressions, parsing,
> validation) just because atoms aren't strings.
At the risk of sounding like "Poor Johnny One-Note"
- atoms *should* be and *could* be garbage collected
(Logix did it and SWI Prolog does it)
- atoms *could* be processed by regular expressions as
easily as character lists and binaries (they *are* in
Smalltalk)
Right now, you are right. Fixing the atom garbage collection problem
ought to be near the top of the priority list, I think.
Note: EEP 20 proposes implementing atoms two different ways: 'global'
atoms that appear in source code and 'dynamic' ones. One reason for
this is that no changes to the compiler or to its .beam files are
needed, only VM changes.
>
> Related links:
>
> Abstract patterns, structs and frames:
> http://www.erlang.org/pipermail/erlang-questions/2009-February/041921.html
There *is* an EEP for abstract patterns, EEP 29.
I did submit an EEP for frames but it was rejected as too large.
Basically, http://www.otago.ac.nz/staffpriv/ok/frames.pdf *is* the
EEP for frames, and has been since late 2003.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri May 07, 2010 5:51 am |
|
|
|
Guest
|
On May 7, 2010, at 12:41 AM, Tim Fletcher wrote:
>
> Parentheses. British usage of the word "brackets" usually means
> parentheses. Sorry for the additional confusion.
My dialect/chronolect is fairly close to British.
However, I learned early on that talking about "brackets"
was EXTREMELY error-prone. I try to redundantly say
round parentheses
square brackets
curly braces
angle brockets
to be unambiguous. The OED (www.oed.com) says
One of two marks of the form [ ] or ( ),
and in mathematical use also {}, used for enclosing
a word or number of words, a portion of a mathematical
formula, or the like, so as to separate it from the
>>> context; in typography, esp. applied to ‘square brackets’
>>> (formerly called crotchets), the ‘round brackets’ being
>>> designated ‘parentheses’.
So the distinction between "brackets" and "parentheses" is not
confined to (careful!) programmers. It looks as though people
working in an area where it *matters* which kind of paired
symbols you use distinguish between brackets and parentheses,
whereas people working in an area where it doesn't (like it
doesn't really matter whether you use (Freddo, 1633) or
[Freddo, 1633] for citations) use brackets for both indifferently.
For what it's worth, it was the >>European<< programming language
Algol that taught me the importance of the distinction.
> Just because syntax might be a relatively trivial issue does not mean
> that it can't be discussed and alternatives considered/compared. I
> don't have anything to add to the "more important" discussion on
> "should we add frames/structs?" because I think they are a sound idea
> in principle and would much prefer using them to records.
There are none-the-less some important semantic questions.
>
> It is also my opinion that using a tilde is not the best syntax to use
> for seperating the keys and values.
Believe me, I've looked for something better, and there _isn't_
anything.
> Whilst it can't be confused with
> any existing syntax, I don't think it makes the meaning of the code
> very clear. Looking at <{foo ~ bar}> doesn't make me think of "a key/
> name mapped to a value". It looks more like some binary operator.
Well, if it comes to that, << makes me think of "very much less than"
and "left shift". It *certainly* doesn't suggest "binary" to me.
*Anything* you put between the label and the value of a maplet is
going to look like some binary operator, in fact from a grammatical
point of view it's going to BE a binary operator. The important
thing is that it not look like some EXISTING binary operator in the
language.
And I repeat: this is a notation that HAS been used before.
If it doesn't suggest "maplet" to you because you're not familiar
with the relevant work at Xerox PARC, it's not the fault of the
notation.
There *is* a Unicode character which is perfect for the job.
U+21A6 ↦ looks like exactly the maplet character.
Back in 2003 I couldn't type Unicode characters into a mail message.
In fact, I *still* can't, I have to use Insert|Special characters|...
which is a pain in the neck. (It makes \mapsto a marvel of
usability.)
Realistically, one is often looking at
<{ foo ~ SOME HAIRY EXPRESSION
, bar ~ ANOTHER HAIRY EXPRESSION
, ugh ~ YET A THIRD
}>
It's pretty obvious what's going on (as long as we don't use : or =
or ->).
Oh, the use of <{ ... }> was inspired by
- these things are sets of pairs, so {...} is appropriate
- I've seen overstruck < ( ... ) > used for string quotes
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri May 07, 2010 8:22 pm |
|
|
|
Guest
|
> I personally don't think that we need or should have a special syntax
> for dicts
After some thinking and rereading I should admit that Richard O'Keefe
is right and what I actually need is more like frames/structs than
dictionaries (actually, I don't even need indexes on keys, because my
documents are quite small). Garbage collected atoms + frames/structs
are enough.
With atoms not being garbage collected frames/stuct can only be
*almost* dynamic, because using them for representing deep and dynamic
data structures (JSON/XML/YAML) will soon lead to leaking atoms.
--
Sergey Samokhin
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| kagato |
| Posted: Fri May 07, 2010 8:36 pm |
|
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
Recently, I submitted a patch to make term_to_binary have a "safe" option (i.e. doesn't create new atoms). It was accepted. My use case was decoding binaries from the network and dropping them into a pattern-match to make simple network protocols. It turned out that I had no problem just creating the atoms I needed and letting the conversion fail if I got a bad atom.
Perhaps you could do something similar in the JSON or YAML decoder? Just use list_to_existing_atom/1. If it fails, collect that key into a 'unknown keys' dictionary or just throw it away if you don't need to save / use the extra data.
It would be perhaps a little ugly, but it should work. I've always found that a little judicious design can generally prevent atom leakage.
Good luck!
--
Jayson Vantuyl
On May 7, 2010, at 1:16 PM, Sergey Samokhin <prikrutil@gmail.com> wrote:
>> I personally don't think that we need or should have a special syntax
>> for dicts
>
> After some thinking and rereading I should admit that Richard O'Keefe
> is right and what I actually need is more like frames/structs than
> dictionaries (actually, I don't even need indexes on keys, because my
> documents are quite small). Garbage collected atoms + frames/structs
> are enough.
>
> With atoms not being garbage collected frames/stuct can only be
> *almost* dynamic, because using them for representing deep and dynamic
> data structures (JSON/XML/YAML) will soon lead to leaking atoms.
>
> --
> Sergey Samokhin
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
>
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat May 08, 2010 11:40 am |
|
|
|
Guest
|
Let's just *suppose* that frames/structs are already here.
The question: are there any reasons why we would want to use records?
In other words, should we now think of records as some kind of
deprecated trick?
To answer this question we should list features that only records have
and then ask another question: "it this good to still have these
features?".
1. With records you are restricted to declared keys. You can't add new
keys on the fly.
Are there situations when it's good?
2. With records you can specify default values to keys
With frames it can'be achieved by using custom wrappers:
create_my_frame(...) % Creates a new frame with all the default values specified
--
Sergey Samokhin
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| rvirding |
| Posted: Sat May 08, 2010 2:49 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
I think there is really only one reason why you would use records
instead of frames/structs: speed. Records will be faster as all the
work needed to find out which field to access is done at compile-time.
A secondary reason could be that you get some compile-time checking
which will catch typos. I would expect that dialyzer would be able to
catch some of those.
I personally would convert and use frames/structs when they arrive.
Robert
On 8 May 2010 13:37, Sergey Samokhin <prikrutil@gmail.com> wrote:
> Let's just *suppose* that frames/structs are already here.
>
> The question: are there any reasons why we would want to use records?
> In other words, should we now think of records as some kind of
> deprecated trick?
>
> To answer this question we should list features that only records have
> and then ask another question: "it this good to still have these
> features?".
>
> 1. With records you are restricted to declared keys. You can't add new
> keys on the fly.
>
> Are there situations when it's good?
>
> 2. With records you can specify default values to keys
>
> With frames it can'be achieved by using custom wrappers:
>
> create_my_frame(...) % Creates a new frame with all the default values specified
>
> --
> Sergey Samokhin
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
>
>
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| 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
