[erlang-questions] erlang improvement - objective c (or smalltalk) syntax

[Bengt Kleberg]

Greetings,

In the beginning I missed the point that
 string:substring( string:S start:I length:J )
is not part of the documentation but of the source. Now I get it. That
makes it worthwhile.


bengt

On Fri, 2009-06-05 at 17:00 +1200, Richard O'Keefe wrote:
> On 4 Jun 2009, at 10:08 pm, Bengt Kleberg wrote:
> > The thought of getting a new standard library with less clutter and
> > inconsistency is very welcome. So that, alone , makes this is a good
> > idea. Presumably there are a lot of other good things in this  
> > suggestion
> > since it comes from Joe. However, I must have missed them since I can
> > not help but think that the benefits presented are not enough.
> >
> > 1) I would still need to look in the documentation. No longer to find
> > the position, but to find out the names/spelling of the arguments.  
> > Is it
> > string: or str:, start: or first: and is it length: or chars:?
> 
> This is true.  But if you misremember the names of the argument
> packets, there simply isn't a function by that name, whereas if
> you misremember the order of arguments in a packet, you don't
> discover the mistake until later, if ever.
> >
> >
> > 2) I do not find it more beneficial to write
> > string:substring( string:S start:I length:J ), instead of
> > string:substring( String, Start, Length ).
> 
> Consider the following variations on substring:
>   (0) Is the first integer a 0-origin offset, or
>   (1) is it a 1-origin index?
>   (a) Is the second argument a length, or
>   (b) is it a 0-origin index of the last included character, or
>   (c) is it a 1-origin index of the last included character, or
>   (d) is it a 0-origin index of the first excluded character, or
>   (e) is it a 1-origin index of the first excluded character?
> 
> That's 10 possibilities, and it's not exhaustive.
> BASIC often used (1,c).  AWK uses (1,a).  Scheme uses (0,d).
> Icon has rules that allow the use of negative integers.
> 
> The proposal I've presented several times is due to Paul Lyons,
> who was a Masters student at the University of Auckland back
> when I was.  He called it "split procedure names".  I know he
> wrote it up; I don't know if in SIGPLAN Notices or where.  He
> himself would have been the first to admit that the idea
> actually goes back to Algol 60, where you could write things
> like
> 	integral of(f)from:(lb)to:(ub)step:(h)
> where the rule was that ")[a-zA-Z ]+:(" was equivalent to ",".
> So in Algol 60, the idea was just cosmetic.  Burroughs Algol,
> with which Paul Lyons and I were familiar, didn't _quite_ do
> that.  It said that ")" <string> "(" was equivalent to ",",
> so you'd write
> 	integral_of(f)"from"(lb)"to"(ub)"step"(h).
> It was Paul who noticed that you didn't need the colons and
> that you could take the thing _seriously_ and wouldn't need
> any special syntax for keywords.  This would have been about
> 1977.
> 
> Why is
> 	string:substring(S) start(I) length(J)
> better than
> 	string:substring(S, Start, Length)?
> 
> Because (a) what if it's another argument which you *thought* was
> a length but was actually a Scheme-like "end"?  And (b) variables
> are often arguments of more than one function, and it's not always
> possible to choose the name to suit both equally well.
> 
> Writing Smalltalk, where you'd write
> 	aString copyFrom: start to: stop
> I have found that I make almost no function-interface mistakes,
> because the name of the function I'm calling reminds me what
> the arguments are supposed to be.  (I make plenty of other mistakes!)
> 
> 
> 
> 
> 
> 
> >
> >
> >
> > bengt
> >
> > On Thu, 2009-06-04 at 11:10 +0200, Joe Armstrong wrote:
> >> I've been writing some objective-C and like the method calling  
> >> syntax.
> >> Objective-C (and smalltalk) code is very readable without lot's of  
> >> comments
> >>
> >> Could we do something similar in Erlang?
> >> This was (I think)  discussed a long time ago but can't find the  
> >> discussion.
> >>
> >> Imagine a function like string:substring/3. A call to this looks  
> >> like:
> >>
> >>        string:substring(Str, I, J)
> >>
> >> The problem with this is that it's difficult to remember the  
> >> argument order
> >> and you have to consult the documentation *to find out the order of
> >> the arguments*
> >> I *know* what the arguments are (a string, a start index and a  
> >> length)
> >> but I have to
> >> consult the documentation to find the order.
> >>
> >> Solution: write the call like this.
> >>
> >>       string:substring( string:S start:I length:J)
> >>
> >> This could be expanded into a canonical form:
> >>
> >>       string:substring_start_string_length(S, I, J)
> >>
> >> where the tags are sorted.
> >>
> >> This would also make the definitions of functions *shorter*
> >> and almost self-documenting
> >>
> >> ie: today I might write something
> >>
> >>         f123(FileName, Mode) ->
> >>                Fin = FileName ++ ".erl",
> >>                Fout = FileName ++ ".beam",
> >>                compile(Fin, Fout, Mode).
> >>
> >> whereas I could write
> >>
> >>         f123(filename:F mode:M) ->
> >>                Fin = F ++ ".erl",
> >>                Fout = F++ ".beam",
> >>                compile(Fin, Fout, M).
> >>
> >> whose canonical expansion is:
> >>
> >>     f123_filename_mode(F, M) ->
> >>                Fin = F ++ ".erl",
> >>                Fout = F++ ".beam",
> >>                compile(Fin, Fout, M).
> >>
> >> This change has many advantages:
> >>
> >>            + forces use of meaningful tag names in arguments
> >>            + don't have to remember argument order
> >>            + variable names in the body of a function become shorter
> >>
> >>
> >> If we were to make this change we would have to rewrite all the
> >> standard libraries
> >> but this would be a *good thing* - since this time we could get  
> >> them right.
> >>
> >> This is would also be a backwards compatible change (I think)
> >>
> >> /Joe
> >>
> >> ________________________________________________________________
> >> erlang-questions mailing list. See http://www.erlang.org/faq.html
> >> erlang-questions (at) erlang.org
> >>
> >
> >
> > ________________________________________________________________
> > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > erlang-questions (at) erlang.org
> >
> >
>