| Author |
Message |
|
| Guest |
 Posted: Mon May 03, 2010 7:59 pm |
 |
|
|
Guest
|
Hello!
While reading turorials of how MongoDB documents are made in
Python/Ruby, I saw one thing I ever wanted to have in Erlang:
{"author": "Mike",
"text": "My first blog post!",
"tags": ["mongodb", "python", "pymongo"],
"date": datetime.datetime.utcnow()}
That is special syntax for dictionaries.
Take a look at the slide 47 of "What are the important ideas in
Erlang?" [1] presentation by Joe Armstrong:
-----Slide 47-----
Hashmaps
foo(<{a:X, b:Y | T }>) ->
...
> foo(<{c:23, a:123, b:abc}>)
Binds X=123, Y=abc T=<{c:23}>
---------------------
Are there chances that we'll see this feature in one of the following
releases of Erlang?
I know there already are records, proplists and dict/gb_trees, but
runtime support for records is limited and it isn't possible to
pattern match on proplists (because the order of tuples may change)
and dicts.
[1] http://www.erlang-factory.com/conference/SFBay2010/speakers/joearmstrong
--
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: Mon May 03, 2010 11:12 pm |
|
|
|
Guest
|
On May 4, 2010, at 7:57 AM, Sergey Samokhin wrote:
> Hello!
>
> While reading turorials of how MongoDB documents are made in
> Python/Ruby, I saw one thing I ever wanted to have in Erlang:
>
> {"author": "Mike",
> "text": "My first blog post!",
> "tags": ["mongodb", "python", "pymongo"],
> "date": datetime.datetime.utcnow()}
>
> That is special syntax for dictionaries.
My proposal for 'frames' has been sitting around for years.
I would write that as
<{ author ~ "Mike"
, text ~ "My first blog post!"
, tags ~ ["mongodb","python","pymongo"]
, date ~ erlang:now()
}>
but it's NOT a hashmap because it's NOT mutable, the keys
may only be atoms, and it's intended for fast matching of
groups of at most low dozens of entries, being a replacement
for -record, not dictionaries. As a practical matter, it
is important to separate keys from values by something
other than : (module prefix), = (matching), or -> (function
arrow), and a lot of work at Xerox PARC used ~ .
Joe Armstrong has a similar proposal which he called 'proper
structs' that is only superficially different from mine, but
even older. (Mine discusses implementation, which his does
not. It is possible to get the space for a frame down to
the same as the space for the corresponding record in the
usual case.)
>
________________________________________________________________
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 |
|
| als |
| Posted: Tue May 04, 2010 11:36 am |
|
|
|
User
Joined: 29 Mar 2007
Posts: 51
|
On Tue, 4 May 2010 05:57:19 am Sergey Samokhin wrote:
> Hello!
>
> While reading turorials of how MongoDB documents are made in
> Python/Ruby, I saw one thing I ever wanted to have in Erlang:
>
> {"author": "Mike",
> "text": "My first blog post!",
> "tags": ["mongodb", "python", "pymongo"],
> "date": datetime.datetime.utcnow()}
>
> That is special syntax for dictionaries.
This is not far off it
dict:from_list([
{"author", "Mike"},
{"tags", ["mongodb", "python", "pymongo"]}
])
--
Anthony Shipman Mamas don't let your babies
als@iinet.net.au grow up to be outsourced.
________________________________________________________________
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: Tue May 04, 2010 10:05 pm |
|
|
|
Guest
|
> My proposal for 'frames' has been sitting around for years.
> I would write that as
> |
|
|
| Back to top |
|
| axel |
| Posted: Wed May 05, 2010 4:56 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
Greetings,
Would not using ":" make it look like a function call (to another
module)?
bengt
On Wed, 2010-05-05 at 00:02 +0200, Tim Fletcher wrote:
> > My proposal for 'frames' has been sitting around for years.
> > I would write that as
> > <{ author ~ "Mike"
> > , text ~ "My first blog post!"
> > , tags ~ ["mongodb","python","pymongo"]
> > , date ~ erlang:now()
> > }>
>
> As much as I dislike the double bracketing I can see the necessity. Is
> there any reason why using the more common choice of ":" to delimit
> the keys and values would be a problem (instead of "~")?
>
> For example: <{author: "Mike", text: "My first blog post!"...}>
>
> Tim
>
> ________________________________________________________________
> 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: Wed May 05, 2010 7:34 am |
|
|
|
Guest
|
> Would not using ":" make it look like a function call
> (to another module)?
Yes, if the values are atoms and you don't put spaces before/after the
semicolon. Whilst that would be similar to a mod:fun call, there are
no brackets, so technically there's no ambiguity. Currently that usage
of the semicolon is illegal syntax, so presumably it could be made to
work. And to make it really look like a function call you'd have to be
using keys and values that are similar to those used to identify
modules and functions, like this:
<{erlang:list_to_integer}>.
I think both of these look sufficiently different from a mod:fun call
though:
<{erlang: list_to_integer}>.
<{erlang : list_to_integer}>.
Maybe it's my exposure to languages that use the semicolon for this
purpose, but it feels more natural than "~".
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 |
|
| rvirding |
| Posted: Wed May 05, 2010 10:22 am |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
The problem is that syntax has to be interpreted by two different
parsers: programmers who read the code and the language parser. While
programmers can often infer what you mean the parser can only follow
strict rules. This means that there can be no ambiguities.
While your examples might work if the value is a simple constant or
variable allowing any legal general expression will cause problems.
How would you interpret <{erlang:list_to_integer("123")}> ? Note that
white space is usually ignored so making white space significant here
would be creating a special case for just this. There is no difference
between erlang:list_to_integer and erlang : list_to_integer.
Even if you grab the first atom + colon as key name you can still get
some funny combinations, for example
<{erlang:erlang:list_to_integer("123")}>. The parser would have no
problems with this, it would blindly follow the rules, but a
programmer might start to wonder.
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.
Robert
On 5 May 2010 09:32, Tim Fletcher <mail@tfletcher.com> wrote:
>> Would not using ":" make it look like a function call
>> (to another module)?
>
> Yes, if the values are atoms and you don't put spaces before/after the
> semicolon. Whilst that would be similar to a mod:fun call, there are
> no brackets, so technically there's no ambiguity. Currently that usage
> of the semicolon is illegal syntax, so presumably it could be made to
> work. And to make it really look like a function call you'd have to be
> using keys and values that are similar to those used to identify
> modules and functions, like this:
>
> |
|
|
| Back to top |
 
|
| Guest |
| Posted: Wed May 05, 2010 12:19 pm |
|
|
|
Guest
|
> While your examples might work if the value is a simple constant or
> variable allowing any legal general expression will cause problems.
> How would you interpret <{erlang:list_to_integer("123")}> ? Note that
> white space is usually ignored so making white space significant here
> would be creating a special case for just this.
You're right, that's definitely not workable.
> 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.
I think = is fine aesthetically, but Richard notes in his frames
proposal that it could also be confused with existing syntax that uses
=. Adopting the Ruby style "arrows" would be another option:
<{author=>"Mike", erlang=>list_to_integer("123")}>
Looks clear enough, but might be a bit too verbose for typing out?
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: Wed May 05, 2010 1:10 pm |
|
|
|
Guest
|
On Wed, May 5, 2010 at 2:17 PM, Tim Fletcher <mail@tfletcher.com> wrote:
>> While your examples might work if the value is a simple constant or
>> variable allowing any legal general expression will cause problems.
>> How would you interpret <{erlang:list_to_integer("123")}> ? Note that
>> white space is usually ignored so making white space significant here
>> would be creating a special case for just this.
>
> You're right, that's definitely not workable.
>
>> 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.
>
> I think = is fine aesthetically, but Richard notes in his frames
> proposal that it could also be confused with existing syntax that uses
> =. Adopting the Ruby style "arrows" would be another option:
>
> |
|
|
| Back to top |
|
| Guest |
| Posted: Wed May 05, 2010 3:41 pm |
|
|
|
Guest
|
> Just to be correct it is not Ruby style but Perl style
Surely it's still in the style of Ruby, even if the style originated
elsewhere? 
> it was found brief enough even in Perl sense.
Sure, I like it, but the { : } combo is half as many characters for
the delimiters as the <{ => }> combo. Just trying to compare the
alternatives.
Syntax aside, frames/structs would be nice to have.
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: Wed May 05, 2010 8:54 pm |
|
|
|
Guest
|
Hello.
> but it's NOT a hashmap because it's NOT mutable, the keys
> may only be atoms, and it's intended for fast matching of
> groups of at most low dozens of entries, being a replacement
> for -record, not dictionaries.
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
________________________________________________________________
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:50 am |
|
|
|
Guest
|
On 5-May-10, at 11:08 PM, Hynek Vychodil wrote:
> On Wed, May 5, 2010 at 2:17 PM, Tim Fletcher <mail@tfletcher.com>
> wrote:
>>> While your examples might work if the value is a simple constant or
>>> variable allowing any legal general expression will cause problems.
>>> How would you interpret <{erlang:list_to_integer("123")}> ? Note
>>> that
>>> white space is usually ignored so making white space significant
>>> here
>>> would be creating a special case for just this.
>>
>> You're right, that's definitely not workable.
>>
>>> 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.
>>
>> I think = is fine aesthetically, but Richard notes in his frames
>> proposal that it could also be confused with existing syntax that
>> uses
>> =. Adopting the Ruby style "arrows" would be another option:
>>
>> <{author=>"Mike", erlang=>list_to_integer("123")}>
>>
>> Looks clear enough, but might be a bit too verbose for typing out?
>
> Just to be correct it is not Ruby style but Perl style and it was
> found brief enough even in Perl sense.
Also PHP.
--Toby
>
>>
>> Tim
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@erlang.org
>>
>>
>
>
>
> --
> --Hynek (Pichi) Vychodil
>
> Analyze your data in minutes. Share your insights instantly. Thrill
> your boss. Be a data hero!
> Try GoodData now for free: www.gooddata.com
>
> ________________________________________________________________
> 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: Thu May 06, 2010 1:20 am |
|
|
|
Guest
|
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.
However, you can produce a new dict from an old dict and a key/keys to add,
just like you can produce a new record which is created from an old record
and a field/multiple fields to change.
When you say "frames" wouldn't be mutable, how does that differ from dicts
(or for that matter, records)
--
Tony Arcieri
Medioh! A Kudelski Brand
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 2:21 am |
|
|
|
Guest
|
On May 5, 2010, at 10:02 AM, Tim Fletcher wrote:
>> My proposal for 'frames' has been sitting around for years.
>> I would write that as
>> <{ author ~ "Mike"
>> , text ~ "My first blog post!"
>> , tags ~ ["mongodb","python","pymongo"]
>> , date ~ erlang:now()
>> }>
>
> As much as I dislike the double bracketing I can see the necessity.
You must hate the <<...>> used for binaries, then.
There just aren't any ASCII brackets left.
The double guillemets |
|
|
| Back to top |
|
| Guest |
| Posted: Thu May 06, 2010 2:37 am |
|
|
|
Guest
|
On May 5, 2010, at 7:32 PM, Tim Fletcher wrote:
> Yes, if the values are atoms and you don't put spaces before/after the
> semicolon. Whilst that would be similar to a mod:fun call, there are
> no brackets, so technically there's no ambiguity. Currently that usage
> of the semicolon is illegal syntax, so presumably it could be made to
> work.
What semicolon? ":" is a colon.
Erlang is not Javascript, so there is no compelling reason why
it should *look* like Javascript.
There are things that are technically unambiguous in a programming
language, but that's very far from being a sufficient criterion
for usability. For example, in Fortran 66 there were "Hollerith
literals" where you wrote a string as the number of characters
followed by those characters, e.g.,
15H.NOT.REAL(CODE)
for the string ".NOT.REAL(CODE)". The *compiler* never had any
trouble with this, but *people* had trouble getting the number
right and far worse trouble reading the result, which is why this
feature isn't in any recent Fortran standard. (.NOT. is a Fortran
logical negation operator and REAL is a Fortran intrinsic function.)
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: label ~ func(args) is perfectly possible
and indeed in my experiments with using the notation I have found
a maplet with a function call to be quite common.
You have to consider not just what the *compiler* can process,
but
- what *people* can rapidly distinguish,
- what can happen as a result of cut-and-paste editing,
- what crude approximate parsers like syntax colouring editors
might have trouble with
- what's going to happen when people grep for things
- the fact that spaces are not generally obligatory in Erlang,
so just saying "you ought to write label: value" is no
guarantee that it will be done that way
________________________________________________________________
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
Page 1 of 3
Goto page 1, 2, 3 Next
|
|
|
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
