In other people's code and even in books there is this convention where
someone takes a function that accepts a foo and returns a bar and they
name it
foo->bar
so they end up with something like this:
(form->result (list->form (vector->list (string->vector x))))
If you are one of these people just for one day try naming your
functions
bar<-foo
because when you read your code you're not reading
"I've got a foo" -> "it's going to be a bar"
from left to right, your reading
"thie function (that will return a bar)" -> "the foo argument that I'm
giving it"
from left to right. Now you end up with:
(result<-form (form<-list (list<-vector (vector<-string x))))
which is easier to follow than the previous form. Also now the first
thing you read (and type) whenever you use a function is what it's
going to return, not what it takes.
peace
Nick
········@gmail.com wrote:
> because when you read your code you're not reading
>
> "I've got a foo" -> "it's going to be a bar"
yes, we are. it's the same case of functions like foo2bar, fooToBar,
for_to_bar in other languages.
Pedro Kroger
Pedro Kroger wrote:
> ········@gmail.com wrote:
> > because when you read your code you're not reading
> >
> > "I've got a foo" -> "it's going to be a bar"
>
> yes, we are. it's the same case of functions like foo2bar, fooToBar,
> for_to_bar in other languages.
are these functional languages?
>
> Pedro Kroger
(message (Hello 'Pedro)
(you :wrote :on '(31 Dec 2006 19:16:57 -0800))
(
??>> "I've got a foo" -> "it's going to be a bar"
PK> yes, we are. it's the same case of functions like foo2bar, fooToBar,
PK> for_to_bar in other languages.
you can also see
new Bar(foo);
in other languages, i bet not much less frequent then, so what?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
········@gmail.com wrote:
> from left to right. Now you end up with:
>
> (result<-form (form<-list (list<-vector (vector<-string x))))
Not if someone uses a macro to do left to right filtering. Then the fur
is being rubbed the wrong away again:
(filter x vector<-string list-<vector form-<list result-<form)
Also, look at the redudancy you have there, now made gapingly obvious:
... <-form (form ...
... <-list (list ...
... <-vector (vector ...
Even the <-string part in the name vector-<string is useless, because
you care more about what x is being converted to than what it is. You
can look up what x is, or give it a name which reveals that: x-str or
whatever.
And so (ignoring for a second that some of these functions clash with
standard CL):
(result (form (list (vector x))))
There you go. Make a vector out of x, then a list out of that, then a
form out of that, then a result out of that.
The "vector<-string" or "string->vector" notation is stupid for another
reason: it flies in the face of genericity, by mangling the type of an
argument into the function name. You can't just make some X into a
vector without caring what its type is. You must know the type of X and
apply the specific function instead of a generic one. When you refactor
the code such that X becomes something else, you have to edit all those
calls. If you refactor the code so that X can be more than one thing,
then you have to add typecases to select from among the
differently-named conversions.
So if this is to be used at all, it should be used in some shitty
little Lisp-like dialect without generic functions. ... *whistle*
Kaz Kylheku wrote:
> ········@gmail.com wrote:
> > from left to right. Now you end up with:
> >
> > (result<-form (form<-list (list<-vector (vector<-string x))))
>
> Not if someone uses a macro to do left to right filtering. Then the fur
> is being rubbed the wrong away again:
>
> (filter x vector<-string list-<vector form-<list result-<form)
>
> Also, look at the redudancy you have there, now made gapingly obvious:
>
> ... <-form (form ...
> ... <-list (list ...
> ... <-vector (vector ...
uh... the post was about the merrits of THIS->NOTATION vs
THIS<-NOTATION, not THIS<-NOTATION vs EVERY-OTHER-NOTATION-EVER
in THIS<-NOTATION you can glance at a form and see that all the
function input/output types match up, as opposed to THIS->NOTATION
... ->result (list...
... ->form (vector...
... ->list (string...
>
> Even the <-string part in the name vector-<string is useless, because
> you care more about what x is being converted to than what it is. You
> can look up what x is, or give it a name which reveals that: x-str or
> whatever.
>
> And so (ignoring for a second that some of these functions clash with
> standard CL):
>
> (result (form (list (vector x))))
>
> There you go. Make a vector out of x, then a list out of that, then a
> form out of that, then a result out of that.
>
> The "vector<-string" or "string->vector" notation is stupid for another
> reason: it flies in the face of genericity, by mangling the type of an
> argument into the function name. You can't just make some X into a
> vector without caring what its type is. You must know the type of X and
> apply the specific function instead of a generic one. When you refactor
> the code such that X becomes something else, you have to edit all those
> calls. If you refactor the code so that X can be more than one thing,
> then you have to add typecases to select from among the
> differently-named conversions.
>
> So if this is to be used at all, it should be used in some shitty
> little Lisp-like dialect without generic functions. ... *whistle*
yes, if all you ever did was write operations to convert one class/type
to another you could use just generic functions. you're a genious.
ok, in chapter 31 of Practical Common Lisp (the html generation
compiler chapter) Peter uses a function SEXP->OPS that does something
high-level, I don't remember what... or imagine something like
PRETTY-STRING-TO-UGLY-STRING that isn't just an application of COERCE
where it might be prudent to specify what _abstract_ "type" the
function was taking
respectfully
Nick
········@gmail.com wrote:
> In other people's code and even in books there is this convention where
> someone takes a function that accepts a foo and returns a bar and they
> name it
>
> foo->bar
>
> so they end up with something like this:
>
> (form->result (list->form (vector->list (string->vector x))))
Ewwwww. Lose the cutesy arrowheads. The Mac proved two things: GUIs rock
(listening, Slimeballs?) and icons don't work.
Meanwhile: (sales-tax (product-price (item-product (order-item o))))..
You got a problem with that?
>
> If you are one of these people just for one day try naming your
> functions
>
> bar<-foo
and height<-page and width<-line? We should have a contest to see if
anyone can come up with something harder to read, you deserve some
recognition.
>
> because when you read your code...
No one reads code. Few people read natural language, witness c.l.l.
>... you're not reading
>
> "I've got a foo" -> "it's going to be a bar"
I just hope this message does not get too many page-views. (hint)
>
> from left to right, your reading
>
> "thie function (that will return a bar)" -> "the foo argument that I'm
> giving it"
dude, you now have the function as the input to its argument. where do I
begin?
widget-height means "the height of the widget"
If I have a more elaborate function that constructs a GUI representation
of a widget, it still gets called:
widget-view
...with no readability problem. view-widget would be a ridiculous name
for that function, and arrowheads are just a way of saying "this scheme
is ridiculous".
>
> from left to right. Now you end up with:
>
> (result<-form (form<-list (list<-vector (vector<-string x))))
What part of from-to do you not understand?
>
> which is easier to follow than the previous form. Also now the first
> thing you read (and type) whenever you use a function is what it's
> going to return, not what it takes.
Why are your reading OPC? Hell, I do not even read my own.
> peace
Impeachment,
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton wrote:
> Meanwhile: (sales-tax (product-price (item-product (order-item o))))..
>
> You got a problem with that?
>
and
> dude, you now have the function as the input to its argument. where do I
> begin?
>
> widget-height means "the height of the widget"
>
> If I have a more elaborate function that constructs a GUI representation
> of a widget, it still gets called:
>
> widget-view
>
> ...with no readability problem. view-widget would be a ridiculous name
> for that function, and arrowheads are just a way of saying "this scheme
> is ridiculous".
>
Excellent reply, I agree. It just seems to be a scheme created for
confusing people. I'm new to Lisp (hi, by the way), and I don't see
what's wrong with simple-descriptive-names.
Ken Tilton wrote:
> and height<-page and width<-line?
Yes.
(let ((height (height-of-page n-page))
(width (width-of-line n-line)))...)
Not hard at all. It's sort of self-documenting.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> Ken Tilton wrote:
>
>> and height<-page and width<-line?
>
> Yes.
Uhhh, what I see next looks more like "No":
> (let ((height (height-of-page n-page))
> (width (width-of-line n-line)))...)
You defend the name "height<-page" by throwing it out? Cool. Why
couldn't Johnny Cochran have used the same approach?
>
> Not hard at all.
This refers to the new naming scheme you have offered to replace the
OP's, yes? I agree, much better than the unreadable "<-" "->" stuff. I
guess next 1+ becomes 1^ to illustrate the direction the value is moving.
> It's sort of self-documenting.
>
But "apropos" alpha sorts of func names no longer group sensibly and
symbol completion is rendered useless. 2007 is off to a great start! :)
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
>> (let ((height (height-of-page n-page))
>> (width (width-of-line n-line)))...)
Ken Tilton wrote:
> You defend the name "height<-page" by throwing it out?
I thought the OP's main point was the word order.
That's the part he changed. I don't think the left
arrow is intrinsically confusing, it's just unfamiliar.
--
Dan
www.prairienet.org/~dsb
Dan Bensen wrote:
> >> (let ((height (height-of-page n-page))
> >> (width (width-of-line n-line)))...)
>
> Ken Tilton wrote:
>
>> You defend the name "height<-page" by throwing it out?
>
>
> I thought the OP's main point was the word order.
I know. My point was that changing <- to -of-, um, changes everything.
The latter requires no mental translation and merely cocks up sorts by
name and symbol completion. The former attempts some astonishing feat
whereby the function name lists all inputs and outputs with arrows of
utterly ambiguos meaning signifying somehow which are the inputs and
which the outputs. If left arrow means input then I guess right arrow
means output, so floor could be renamed:
quotient->remainder-><-number<-divisor
I like it! But wait, now we do not have a menmonic for the
transformation. Howseabout:
quotient->remainder->floor<-number<-divisor
Nah, that cannot be it. Maybe the left arrow changes meaning to "output"
if it is left of the mnemonic? Lessee:
<-quotient<-remainder[floor]<-number<-divisor
Sorry about those []s, but I needed something. Hmmm, really just need
something on the left, and should the primary return value be nearer the
menmonic?
quotient<-remainder=floor<-number<-divisor
When does the football start?
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton wrote:
>
>
> Dan Bensen wrote:
>
>> >> (let ((height (height-of-page n-page))
>> >> (width (width-of-line n-line)))...)
>>
>> Ken Tilton wrote:
>>
>>> You defend the name "height<-page" by throwing it out?
>>
>>
>>
>> I thought the OP's main point was the word order.
>
>
> I know. My point was that changing <- to -of-, um, changes everything.
> The latter requires no mental translation and merely cocks up sorts by
> name and symbol completion. The former attempts some astonishing feat
> whereby the function name lists all inputs and outputs with arrows of
> utterly ambiguos meaning signifying somehow which are the inputs and
> which the outputs. If left arrow means input then I guess right arrow
> means output, so floor could be renamed:
>
> quotient->remainder-><-number<-divisor
>
> I like it! But wait, now we do not have a menmonic for the
> transformation. Howseabout:
>
> quotient->remainder->floor<-number<-divisor
>
> Nah, that cannot be it. Maybe the left arrow changes meaning to "output"
> if it is left of the mnemonic? Lessee:
>
> <-quotient<-remainder[floor]<-number<-divisor
>
> Sorry about those []s, but I needed something. Hmmm, really just need
> something on the left, and should the primary return value be nearer the
> menmonic?
>
> quotient<-remainder=floor<-number<-divisor
Silly me (and do we need the -s? I keep having C flashbacks):
<remainder<quotient=floor<number<divisor
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton wrote:
> ········@gmail.com wrote:
> > In other people's code and even in books there is this convention where
> > someone takes a function that accepts a foo and returns a bar and they
> > name it
> >
> > foo->bar
> >
> > so they end up with something like this:
> >
> > (form->result (list->form (vector->list (string->vector x))))
>
> Ewwwww. Lose the cutesy arrowheads. The Mac proved two things: GUIs rock
> (listening, Slimeballs?) and icons don't work.
>
> Meanwhile: (sales-tax (product-price (item-product (order-item o))))..
>
> You got a problem with that?
no, it's your code, so it's your problem if you can't read six months
from now.
actually, in this instance I would
(defmethod price-of ((x order))
(price-of (item-of o)))
(defmethod price-of ((x item))
(price-of (product<-item x)))
(compute-sales-tax (price-of o))
now I don't ever have to remember to
PRODUCT-PRICE/ITEM-PRODUCT/ORDER-ITEM. whenever I want the price of
anything whatsoever I just use PRICE-OF
>
> >
> > If you are one of these people just for one day try naming your
> > functions
> >
> > bar<-foo
>
> and height<-page and width<-line? We should have a contest to see if
> anyone can come up with something harder to read, you deserve some
> recognition.
god, it's almost as bad as all those horrible parenthesis I just can't
get over seeing for the first time
I wrote this post last night. You responded to it this morning. You
couldn't have possibly given it the "one day trial" ;-)
>
> >
> > because when you read your code...
>
> No one reads code. Few people read natural language, witness c.l.l.
>
> >... you're not reading
> >
> > "I've got a foo" -> "it's going to be a bar"
>
> I just hope this message does not get too many page-views. (hint)
>
> >
> > from left to right, your reading
> >
> > "thie function (that will return a bar)" -> "the foo argument that I'm
> > giving it"
>
> dude, you now have the function as the input to its argument. where do I
> begin?
uh, no. that arrow is supposed to represent reading from left to right,
sorry for the confusion.
>
> widget-height means "the height of the widget"
>
> If I have a more elaborate function that constructs a GUI representation
> of a widget, it still gets called:
>
> widget-view
>
> ...with no readability problem. view-widget would be a ridiculous name
> for that function, and arrowheads are just a way of saying "this scheme
> is ridiculous".
>
> >
> > from left to right. Now you end up with:
> >
> > (result<-form (form<-list (list<-vector (vector<-string x))))
>
> What part of from-to do you not understand?
what part of the order that sexps are evaluated do you not understand?
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1.3
>
> >
> > which is easier to follow than the previous form. Also now the first
> > thing you read (and type) whenever you use a function is what it's
> > going to return, not what it takes.
>
> Why are your reading OPC? Hell, I do not even read my own.
>
> > peace
>
> Impeachment,
the code is not written. but it's not _not_ written. it's just being
written slower than we first anticipated.
respectfully
Nick
>
> kt
>
> --
> The Dalai Lama gets the same crap all the time.
> -- Kenny Tilton on c.l.l when accused of immodesty
On Sun, 31 Dec 2006 23:11:29 -0500, Ken Tilton <·········@gmail.com>
wrote:
>········@gmail.com wrote:
>> In other people's code and even in books there is this convention where
>> someone takes a function that accepts a foo and returns a bar and they
>> name it
>>
>> foo->bar
>>
>> :
>>
>> If you are one of these people just for one day try naming your
>> functions
>>
>> bar<-foo
>
>and height<-page and width<-line?
??? How do you transform a height<-page or a width<-line?
>dude, you now have the function as the input to its argument. where do I
>begin?
>
> widget-height means "the height of the widget"
>
>If I have a more elaborate function that constructs a GUI representation
>of a widget, it still gets called:
>
> widget-view
>
>...with no readability problem. view-widget would be a ridiculous name
>for that function, and arrowheads are just a way of saying "this scheme
>is ridiculous".
You read back-ass-ward and have the nerve to tell someone else that
naming functions so they can be read forward is dumb? How dumb is
that?
If Nick wants function names in his Lisp based DSL to read forwards,
who are you to argue? If you don't want to look at them, just wrap
them appropriately. If we get enough people wrap the "wrong way"
names enough times maybe the program will fall over under its own
weight.
>> (result<-form (form<-list (list<-vector (vector<-string x))))
>
>What part of from-to do you not understand?
The part where Lisp turned its back on several hundred years [in the
English speaking world at least] of established convention to report
changes in "to-from" style. You obviously pay no attention to the
business news ... rebinding of the variables indicating valuation are
always quoted as "to [new-value] from [old-value]".
>> peace
>
>Impeachment,
Uisce Beatha.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Sun, 31 Dec 2006 23:11:29 -0500, Ken Tilton <·········@gmail.com>
> wrote:
>
>
>>········@gmail.com wrote:
>>
>>>In other people's code and even in books there is this convention where
>>>someone takes a function that accepts a foo and returns a bar and they
>>>name it
>>>
>>>foo->bar
>>>
>>>:
>>>
>>>If you are one of these people just for one day try naming your
>>>functions
>>>
>>>bar<-foo
>>
>>and height<-page and width<-line?
>
>
> ??? How do you transform a height<-page or a width<-line?
Beats me. I mean, the meaning of your question.
>
>
>
>
>>dude, you now have the function as the input to its argument. where do I
>>begin?
>>
>> widget-height means "the height of the widget"
>>
>>If I have a more elaborate function that constructs a GUI representation
>>of a widget, it still gets called:
>>
>> widget-view
>>
>>...with no readability problem. view-widget would be a ridiculous name
>>for that function, and arrowheads are just a way of saying "this scheme
>>is ridiculous".
>
>
> You read back-ass-ward and have the nerve to tell someone else that
> naming functions so they can be read forward is dumb? How dumb is
> that?
>
> If Nick wants function names in his Lisp based DSL to read forwards,
> who are you to argue?
Oh, sh*t, this is comp.lang.nick? Checking....nope. In fact, look who is
asking other people to change:
········@gmail.com wrote:
> If you are one of these people just for one day try naming your
> functions
btw, "argue"? I thought Nick had made a fun point about naming and I
thought I would flame him for it to get the new year off to a good
start, and in the process flush out dumb f*cks like you for my killfile.
> If you don't want to look at them, just wrap
> them appropriately. If we get enough people wrap the "wrong way"
> names enough times maybe the program will fall over under its own
> weight.
>
>
>
>>>(result<-form (form<-list (list<-vector (vector<-string x))))
>>
>>What part of from-to do you not understand?
>
>
> The part where Lisp turned its back on several hundred years [in the
> English speaking world at least] of established convention to report
> changes in "to-from" style. You obviously pay no attention to the
> business news ... rebinding of the variables indicating valuation are
> always quoted as "to [new-value] from [old-value]".
You obviously pay no attention to Cells:
(slot-value-observe slot-name self new-value old-value old-value-boundp)
On Mon, 01 Jan 2007 15:53:46 -0500, Ken Tilton <·········@gmail.com>
wrote:
>George Neuner wrote:
>> On Sun, 31 Dec 2006 23:11:29 -0500, Ken Tilton <·········@gmail.com>
>> wrote:
>>
>>>········@gmail.com wrote:
>>>
>>>>(result<-form (form<-list (list<-vector (vector<-string x))))
>>>
>>>What part of from-to do you not understand?
>>
>> The part where Lisp turned its back on several hundred years [in the
>> English speaking world at least] of established convention to report
>> changes in "to-from" style. You obviously pay no attention to the
>> business news ... rebinding of the variables indicating valuation are
>> always quoted as "to [new-value] from [old-value]".
>
>You obviously pay no attention to Cells:
>
>(slot-value-observe slot-name self new-value old-value old-value-boundp)
Lessee ... I parse that as "observe change to new-value from
old-value" ... ie. TO-FROM. Exactly what Nick proposed and exactly
the reverse of your previous argument.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Mon, 01 Jan 2007 15:53:46 -0500, Ken Tilton <·········@gmail.com>
> wrote:
>
> >George Neuner wrote:
> >> On Sun, 31 Dec 2006 23:11:29 -0500, Ken Tilton <·········@gmail.com>
> >> wrote:
> >>
> >>>········@gmail.com wrote:
> >>>
> >>>>(result<-form (form<-list (list<-vector (vector<-string x))))
> >>>
> >>>What part of from-to do you not understand?
> >>
> >> The part where Lisp turned its back on several hundred years [in the
> >> English speaking world at least] of established convention to report
> >> changes in "to-from" style. You obviously pay no attention to the
> >> business news ... rebinding of the variables indicating valuation are
> >> always quoted as "to [new-value] from [old-value]".
> >
> >You obviously pay no attention to Cells:
> >
> >(slot-value-observe slot-name self new-value old-value old-value-boundp)
>
> Lessee ... I parse that as "observe change to new-value from
> old-value" ... ie. TO-FROM. Exactly what Nick proposed and exactly
> the reverse of your previous argument.
>
You use that word "exactly" so much. I do not think it means what you
think it means.
If your thinking was as exact as your mouth is big you would notice you
have changed the conversation from the transformation semantic of
from-to to the before-after semantic thereof. ie, before the topic was
input-output (as in page-height and widget-view, functions that take a
page and widget as inputs and return heights and views) and after your
gaffe the topic is old-value/new-value.
I would have stopped you sooner if I had taken you more seriously, but
your needlessly contentious tone prevented that.
Not to encourage your careless misdirection, all things being equal I
would when listing parameters order them old-new, but an overriding
rule in parameter lists is that they appear in decreasing order of
interestingness, and in practice slot-value-observers rarely care about
prior values and almost always care about new values.
Of course the topic is functions that take an input and produce an
output and how to name them, not the order of parameters and /not/
before/after. What is not clear is whether your sloppy thinking arises
from a weak mind or your anger and aggression clouding your judgment. I
am guessing both.
········@gmail.com writes:
> If you are one of these people just for one day try naming your
> functions
>
> bar<-foo
> [...]
> from left to right. Now you end up with:
>
> (result<-form (form<-list (list<-vector (vector<-string x))))
>
> which is easier to follow than the previous form. Also now the first
> thing you read (and type) whenever you use a function is what it's
> going to return, not what it takes.
Yes, we're aware of it. When it starts to become interesting is when
you have several libraries and you need to mix list<-vector
integer->list string-to-integer string-from-symbol and some other
variants like: (coerce object 'type) or (map 'type fun objects)...
Perhaps you'd be closer to your goal if you provided a package named
"ORTHO-CL" with all the symbols from "COMMON-LISP" except the new
aliases, and similarly for implementation specific packages, along
with new versions of all the lisp libraries you can find on Internet.
Some people tried something similar even before Common Lisp; the
result is called Scheme and it's not so nice... (IMO).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
········@gmail.com wrote:
> In other people's code and even in books there is this convention where
> someone takes a function that accepts a foo and returns a bar and they
> name it
>
> foo->bar
This is a naming convention I have seen in Scheme code but not in Common
Lisp code, right?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
>>>>> "nallen05" == nallen05 <········@gmail.com> writes:
nallen05> In other people's code and even in books there is this
nallen05> convention where someone takes a function that accepts a
nallen05> foo and returns a bar and they name it
nallen05> foo->bar
My USD$0.02 (since I'm flush with cash this holiday season), continuing
above rant in a slightly different vein:
This arrow syntax is in effect a way of specifying an application of
`COERCE' - is there a sexy way to extend that function to user-defined
types? e.g.:
(defclass foo () ...)
(defclass bar () ...)
(let ((f (make-instance 'foo)))
(coerce f 'bar))
for some user-defined foo-to-bar transformer?
Secondly, arrow notation gets rather nonsensical when one considers that
this extends to, effectively, specifying a function's parameter types in
its name. What's next, perhaps
`STRING-INTEGER-OPTIONAL-KEYWORD->MY-OBJECT'?
--
Michael J. Barillier /// http://www.blackwolfinfosys.net/~blackwolf/
_O_| Greenspun's Tenth Rule of Programming: "Any sufficiently
__O| complicated C or Fortran program contains an ad-hoc, informally-
OOO| specified bug-ridden slow implementation of half of Common Lisp."
········@gmail.com wrote:
> In other people's code and even in books there is this convention where
> someone takes a function that accepts a foo and returns a bar and they
> name it
>
> foo->bar
In advanced mathematics, f:x->y is standard notation for f(x)=y. e.g.
sqrt:2->1.414.
Thus foo->bar is simply a shorthand that drops the function name (f:)
prefix; in a sense, Lisp auto-prepends f: to the first entry of any
unquoted list.
On Jan 1, 7:48 pm, D Herring <········@at.tentpost.dot.com> wrote:
> ···········@gmail.com wrote:
> > In other people's code and even in books there is this convention where
> > someone takes a function that accepts a foo and returns a bar and they
> > name it
>
> > foo->barIn advanced mathematics, f:x->y is standard notation for f(x)=y. e.g.
> sqrt:2->1.414.
Indeed. I was thoroughly confused by ML and Haskell's function
signatures
(prototypes) until I picked up a book on higher level math and found
the part
about standard mathematical function notation.
Funny how just reversing something that's so familiar can cause so much
confusion (well, that and the lack of parens around the arguments vs.
the
return value on the right).
--
kruhft
metashell.blogspot.com
Dnia 02.01.2007 Burton Samograd <······@gmail.com> napisa�/a:
>
>
> On Jan 1, 7:48 pm, D Herring <········@at.tentpost.dot.com> wrote:
>> ···········@gmail.com wrote:
>> > In other people's code and even in books there is this convention where
>> > someone takes a function that accepts a foo and returns a bar and they
>> > name it
>>
>> > foo->barIn advanced mathematics, f:x->y is standard notation for f(x)=y. e.g.
>> sqrt:2->1.414.
>
> Indeed. I was thoroughly confused by ML and Haskell's function
> signatures
> (prototypes) until I picked up a book on higher level math and found
> the part
> about standard mathematical function notation.
OTOH, the functions in OCaml standard library that convert some data to
another type have names of the form "x_of_y" (eg. int_of_string, not
string_to_int) for the very reason that this makes reading
their compositions more straightforward.
--
Daniel 'Nathell' Janus, GG #1631668, ············@nathell.korpus.pl
"Though a program be but three lines long, someday it will have to be
maintained."
-- The Tao of Programming
On Mon, 01 Jan 2007 20:48:31 -0500, D Herring <········@at.tentpost.dot.com>
tried to confuse everyone with this message:
>········@gmail.com wrote:
>> In other people's code and even in books there is this convention where
>> someone takes a function that accepts a foo and returns a bar and they
>> name it
>>
>> foo->bar
>
>In advanced mathematics, f:x->y is standard notation for f(x)=y. e.g.
>sqrt:2->1.414.
No, it's f:x|->y. f:x->y means a function defined on set x with values in set y.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|