| Author |
Message |
|
| uwiger |
 Posted: Tue Mar 11, 2008 3:29 pm |
 |
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
Hynek Vychodil skrev:
>
>
> But what I would like to have in Erlang is definitely better
> introspection /
> reflection capabilities. I would like to have records as runtime
> structures,
> so I could write:
>
> Var#{x = foo, y = bar}
>
> where Var could be any record that has slots x and y (it might have
> others),
> record_info would be a normal function that can operate on variables.
>
>
> It is misunderstand what record is. Record is not this sort of things.
> Use our own structure for this purpose. Record is not object, hash,
> dictionary or whatever you really want. Record is not designed for some
> sort of inheritance. Record is structure for memory friendly storage of
> fixed "records" a which one will be changed very rare and just only by
> design.
I don't think that these particular aspects of the current
record syntax are a "feature", but rather a pretty severe
drawback.
I have used a hack called exprecs (*), which I think addresses
some of the main problems. For one thing, it allows me to
"export" record accessors from a certain module, thus letting
users of the records read and modify attributes of a record
object without having to ensure that their own module was
compiled exactly the right version of some include file
containing the record definition.
I've also found this quite comfortable e.g. when writing
a Diameter stack, where a record is the most intuitive
representation of a message, but the central logic needs
to be able to check the value of a given attribute (e.g.
'Destination-Host'), even though it can't possibly know
all add-on message record formats at compile-time:
has_dest_host(Rec, Dict) ->
try Dict:'#get-'('Destination-Host', Rec) of
T ->
T /= undefined andalso T /= []
catch
error:_ ->
false
end.
Not that I'm putting this forth as an example of
better syntax, but as an example of what one might want
to do.
In general, I think that records and macros introduce
compile-time dependencies that can be very painful in large
projects. Given that just about everything else can be
properly encapsulated and managed at runtime, with polymorphism
and all, records and macros stick out like a sore thumb.
BR,
Ulf W
(*) http://forum.trapexit.org/viewtopic.php?p=21790#21790
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
  
|
| Guest |
| Posted: Tue Mar 11, 2008 3:57 pm |
|
|
|
Guest
|
>
> In general, I think that records and macros introduce
> compile-time dependencies that can be very painful in large
> projects. Given that just about everything else can be
> properly encapsulated and managed at runtime, with polymorphism
> and all, records and macros stick out like a sore thumb.
We use edep from jungerl to manage record dependencies in normal
develop/make cycles.
A quick "make depend" after a checkout sets up makefile dependencies
for all record definitions. This at least means that future calls to
make after a record change will cause all dependent modules to be re-
compiled.
Highly recommended for larger projects.
Sean
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 4:47 pm |
|
|
|
Guest
|
Ah, this topic 
First the trivia:
1. I'm on board with getting rid of 'if'. I always had to stop and
think about whether I wanted 'if' or 'case' so now I use the latter
for everything.
2. Oh for swapping the meanings of "=:=" and "==".
Now the real issue: commas and semicolons. It used to bother me, to
the point where I considered writing a preprocessor to convert from
indentation-based formatting, but I've since gotten used to it. The
tricky part of indentation based syntax is that you can do stuff like
this:
[atom1, atom2, 2, case X of
true -> ...
false -> ...
end]
Python uses a continuation character at the end of the line, but yuck.
It *would* be nice to get rid of semicolons and periods for top-level
function definitions, though. That could be done without ambiguity
and mocked up via a Perl script in half an hour.
James
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 5:52 pm |
|
|
|
Guest
|
I can live with just about all of the various syntax quirks compared
to other languages and in fact am starting to enjoy some of them, but
I have to chime in with support for the suggestions that record access
needs to be cleaned up a bit. Regardless of what records were
intended to solve, they have become the generic "structure" datum for
Erlang and I think they need to be extended somewhat to make them a
bit more programmer-friendly. Basic introspection, an easier access
mechanism, etc.
When the FAQ has an entry that is titled "Is it just me, or are
records ugly?" I think this might be an indication of the first place
to look for syntax tweaks...
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 6:28 pm |
|
|
|
Guest
|
Ulf Wiger (TN/EAB) wrote:
>
> In general, I think that records and macros introduce
> compile-time dependencies that can be very painful in large
> projects. Given that just about everything else can be
> properly encapsulated and managed at runtime, with polymorphism
> and all, records and macros stick out like a sore thumb.
>
... and parse transforms...
mats
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 6:34 pm |
|
|
|
Guest
|
Jim McCoy wrote:
> ... Regardless of what records were
> intended to solve...
>
i believe that the original requirement was something like; "access to
tuple elements by name, but with zero overhead compared to normal tuple
access."
a pretty tall order (and, with hindsight, misguided)...
mats
Post recived from mailinglist |
|
|
| Back to top |
|
| uwiger |
| Posted: Tue Mar 11, 2008 8:39 pm |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
Mats Cronqvist skrev:
> Ulf Wiger (TN/EAB) wrote:
>>
>> In general, I think that records and macros introduce
>> compile-time dependencies that can be very painful in large
>> projects. Given that just about everything else can be
>> properly encapsulated and managed at runtime, with polymorphism
>> and all, records and macros stick out like a sore thumb.
>>
>
> ... and parse transforms...
>
> mats
No no no no - parse transforms are just wonderful. (:
The only thing missing with parse transforms is the
ability to introduce new syntax (e.g. like !!).
BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 9:22 pm |
|
|
|
Guest
|
On 11 Mar 2008, at 10:02 pm, Ladislav Lenart wrote:
> But what I would like to have in Erlang is definitely better
> introspection /
> reflection capabilities. I would like to have records as runtime
> structures,
Joe Armstrong and I have independently come up with essentially the same
proposal, which is essentially the same thing as LIFE's psi-terms and as
a data type whose name I forget in IBM Prolog. Given that these things
have been implemented in those two languages, and given my outline of
how
to implement them, we KNOW it can be done, and it can be done with
tolerable
effiency. People keep on asking for it. I'm busy this week, but next
week
I might have time to reformat my proposal as an EEP. If you are reading
this, Joe, do you want to do a rival EEP, or should we merge our
proposals?
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 9:26 pm |
|
|
|
Guest
|
On 12 Mar 2008, at 12:05 am, Christian S wrote:
> Would it be possible to create a pattern matching syntax for some kind
> of association map?
Yes it would. Joe Armstrong and I have both produced such designs.
I don't know how he intends his to be implemented, but mine manages
to be sufficiently memory-efficient in the usual case to completely
replace existing uses of records, while still being flexible. It is
*definitely* EEP time.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| noss |
| Posted: Tue Mar 11, 2008 10:04 pm |
|
|
|
User
Joined: 09 Oct 2005
Posts: 290
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 10:17 pm |
|
|
|
Guest
|
Ulf Wiger (TN/EAB) wrote:
> Mats Cronqvist skrev:
>> Ulf Wiger (TN/EAB) wrote:
>>>
>>> In general, I think that records and macros introduce
>>> compile-time dependencies that can be very painful in large
>>> projects. Given that just about everything else can be
>>> properly encapsulated and managed at runtime, with polymorphism
>>> and all, records and macros stick out like a sore thumb.
>>>
>>
>> ... and parse transforms...
>>
>> mats
>
> No no no no - parse transforms are just wonderful. (:
>
> The only thing missing with parse transforms is the
> ability to introduce new syntax (e.g. like !!).
at the very least, the ability to introduce weird compile-time
dependencies is second to none.
mats
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 10:38 pm |
|
|
|
Guest
|
On 11 Mar 2008, at 22:03, Christian S wrote:
> On Tue, Mar 11, 2008 at 10:25 PM, Richard A. O'Keefe <ok@cs.otago.ac.nz
> > wrote:
>> On 12 Mar 2008, at 12:05 am, Christian S wrote:
>>> Would it be possible to create a pattern matching syntax for some
>>> kind
>>> of association map?
>>
>> Yes it would. Joe Armstrong and I have both produced such designs.
>> I don't know how he intends his to be implemented, but mine manages
>> to be sufficiently memory-efficient in the usual case to completely
>> replace existing uses of records, while still being flexible. It is
>> *definitely* EEP time.
>
> I've been looking around for what you have in mind. This one suggests
> some major changes:
> http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
>
> This one seem very doable, to the point that I want them already:
> http://www.erlang.org/ml-archive/erlang-questions/200509/msg00329.html
Or there was the abstract patterns proposal I rather liked:
http://www.erlang.org/ml-archive/erlang-questions/200309/msg00309.html
Sean
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Mar 11, 2008 10:44 pm |
|
|
|
Guest
|
|
| Back to top |
|
| rvirding |
| Posted: Wed Mar 12, 2008 12:30 am |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
On 11/03/2008, Mats Cronqvist <mats.cronqvist@kreditor.se (mats.cronqvist@kreditor.se)> wrote:Quote: Jim McCoy wrote:
> ... Regardless of what records were
> intended to solve...
>
|
|
|
| Back to top |
|
| rvirding |
| Posted: Wed Mar 12, 2008 1:00 am |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
Very few of the misfeatures of Erlang syntax are new, though this doesn't make them less important. Some are be fixable.
I was probably a little unclear but I was interested in the question of a whole new syntax, which at least Ulf understood. And the follow-up question of whether this would satisfy people?
For example assume we did a new flavour of Erlang based on Java which had the look of Java but still had Erlang semantics (it couldn't be otherwise). Would this make new users who came from more traditional languages happy? Or would it just make it worse in that it might look the same as what they are used to (sort of) but there would still be no "real" assignments or destructive operations or loops etc ?
I suppose the question really gets back to where the *real* problem is. Is it really the syntax, or is it actually the semantics but people see it a syntax problem because that is what they see first, the syntax? If a new syntax really solved new users problems then it might be worth doing, otherwise not. What do people think?
One benefit on basing a new syntax on a typed language would be that adding (optional) type declarations would still look "right". Typing records just looks weird to me.
Robert
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
