![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
>>> What, defining three pages of code is longer than the 1-liner I posted?
>>>
>>> The ($) operator is defined in the Haskell language standard. :-P
>>
>> The o operator is defined in my personal standard and I never look
>> back. ;)
>
> OK, but ($) is still a 1-liner:
>
> f $ x = f x
>
> And, unlike your notation, it doesn't require any brackets at all! ;-)
Why would my o operator not be a one-liner? Unless you think the
implementation of $ doesn't count. It's just as abstracted away as the
implementation of o.
I don't have a problem with brackets or parenthesis. Besides, Haskell
needs it too to solve ambiguities in all but the most simpler expressions.
And multiple $ for each call is as bad as multiple parenthesis, I guess.
> BTW, what would you say the most irritating library design flaw in
> Scheme is?
None. It's perfect. ;)
Ok, to be fair, I didn't like the latest standard very much... And given
Scheme is very minimalist, I'm used to writing my own libs, so any
design flaws are really mine. ;)
> In Haskell, my personal one is this:
>
> filter odd [1, 2, 3, 4]
>
> That takes a list and filters out the odd numbers, right?
>
> WRONG!
>
> It filters out the *even* numbers.
>
> Like, WTF?
>
> Obviously what they *should* have done is name it "select". Then you
> would write
>
> select odd [1, 2, 3, 4]
Hmm, that's just different terminology for the same things. Yes, I too
would expect filter odd to return the odds, but it certainly can be seen
working the other way around. I believe, though, that 2 functions doing
pretty much the same thing is wrong and bad design. select is really
only used in SQL. filter is a pretty common functional language idiom...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> data Settings = Settings
> {
> time_step :: Time,
> min_subdivide :: Time,
> tolerance :: Space,
> recursive :: Bool
> }
>
> foo $ Settings {recursive = True, tolerance = 0.01, min_subdivide =
> 0.001, time_step = 2.5}
>
> Heh, that's the trouble with named arguments - it gets so verbose. ;-)
Hah! And now you got brackets and colons (and type declarations)!!
mwahahahaaha
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: GIMP hotkeys/ scripts/ user-defined functions?
Date: 10 Dec 2008 11:53:33
Message: <493ff40d@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Don't forget Smalltalk. (Although Smalltalk still requires you to write
> them *in the right order*.)
*And* it doesn't tell you in advance when you get it wrong. :-)
Try Ada. :-)
> Yeah, actually _any_ function that requires 8 distinct arguments is
> probably a bad idea.
For OO, you should probably be setting them as configuration-style data on
the object you're invoking. This is Bertrand Meyer's take on it, and it
makes sense to me: if you have a method in an OO language that has optional
arguments, those arguments ought to be properties on the object with setters
and getters. I think this is probably true, because 95% of the time I wind
up with optional arguments, it's because I already wrote and used the
function in a bunch of places, and now I want to pass one more argument
without tracking down all the places the original got called. Either making
it a method with a settable parameter in the instance, or actually taking
the time to track down all the calls (which can be messy in a very dynamic
language) would fix that.
For functional, I can easily imagine a main loop sort of thing having to
carry around a bunch of arguments that don't make sense to put together.
For example, I have a computer word game where the main game-engine keeps a
list of possible guesses, a list of the computer's past guesses, a list of
new words it learned this game, a list of guesses made by the player and
their associated score, the human's previous guess, the computer's previous
guess, the computer's secret work (which the human is trying to guess), the
original list of words, the connection to the UI, and the random number
seed. It's hard to believe there's any data structure that sensibly
encapsulates all that without simply being a kludge to work around the lack
of loops in the language. (With loops, you'd just make most of them local
variables and not actually have to pass them through the recursive calls.)
Mind, I'm not used to functional programming, so maybe I'm doing something
wrong...
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: nemesis
Subject: Re: GIMP hotkeys/ scripts/ user-defined functions?
Date: 10 Dec 2008 11:58:11
Message: <493ff523@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> nemesis wrote:
>
>> http://en.wikipedia.org/wiki/Lisp_(programming_language)#Language_innovations
>>
>>
>> Not that wikipedia is authorithative knowledge... :P
>>
>> Until then, all you had was assembly branching.
>
> ...there's an XML syntax for Lisp??! o_O
>
> *runs away*
Holy Crap!!
actually, it's just a bridge between CL and XML. Hey, XML itself is an
s-expression language, like Lisp. ;)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> filter odd [1, 2, 3, 4]
> It filters out the *even* numbers.
Yes. And the odd numbers stay behind in the filter. If you filter out coffee
grounds, what do you have when you're done? Grounds, or coffee?
The problem with a real filter is it separates, rather than selects. When
you filter coffee, are you filtering the grounds or the drinkable stuff?
Neither: you're separating the two.
I'm kind of surprised "filter" doesn't return both, given it would seem
(semantically) fairly easy not to calculate whichever half doesn't get used.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> filter odd [1, 2, 3, 4]
>> It filters out the *even* numbers.
>
> Yes. And the odd numbers stay behind in the filter. If you filter out
> coffee grounds, what do you have when you're done? Grounds, or coffee?
>
> The problem with a real filter is it separates, rather than selects.
> When you filter coffee, are you filtering the grounds or the drinkable
> stuff? Neither: you're separating the two.
I still prefer Smalltalk's "select" and "reject". Makes much more sense
to me. :-P
> I'm kind of surprised "filter" doesn't return both, given it would seem
> (semantically) fairly easy not to calculate whichever half doesn't get
> used.
Nope; that's "partition". (Which at least has a sensible name.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Why would my o operator not be a one-liner?
Because it's defined as four (very wide) lines? :-P
> I don't have a problem with brackets or parenthesis. Besides, Haskell
> needs it too to solve ambiguities in all but the most simpler expressions.
Yeah, I know. This argument is getting kinda silly. ;-)
> And multiple $ for each call is as bad as multiple parenthesis, I guess.
Not really. With brackets, you have to match opening and closing
characters. With ($), there is only one thing to "match". The trouble
comes if you try to mix it with brackets as well... Basically, if you
find yourself doing this, you should probably split your expression into
smaller parts. Same as any language, really... except Lisp. In Lisp, you
cannot avoid endless brackets, because notionally the *entire source
code* as a single expression. :-P
>> BTW, what would you say the most irritating library design flaw in
>> Scheme is?
>
> None. It's perfect. ;)
Heh, right. One question: is it statically-typed?
> Ok, to be fair, I didn't like the latest standard very much... And given
> Scheme is very minimalist, I'm used to writing my own libs, so any
> design flaws are really mine. ;)
Yeah, I prefer a language with as few things as possible "baked-in".
Sadly, Haskell's list syntax is one such thing. :-(
> Hmm, that's just different terminology for the same things.
Ah, but *never* underestimate how important terminology can be! ;-)
> I believe, though, that 2 functions doing
> pretty much the same thing is wrong and bad design.
Haskell is *loaded* with functions that do the same or similar things.
It's about how you want to think about your problem.
For example, there's a variable defined that's called "otherwise". It's
value is "True". But compare these:
foo x
| x < 0 = ...
| x == 0 = ...
| True = ...
foo x
| x < 0 = ...
| x == 0 = ...
| otherwise = ...
Which do you think is clearer? ;-)
> select is really only used in SQL.
And Smalltalk.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Orchid XP v8
Subject: Re: GIMP hotkeys/ scripts/ user-defined functions?
Date: 10 Dec 2008 13:46:24
Message: <49400e80@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> ...there's an XML syntax for Lisp??! o_O
>>
>> *runs away*
>
> Holy Crap!!
>
> actually, it's just a bridge between CL and XML. Hey, XML itself is an
> s-expression language, like Lisp. ;)
More worryingly... There is also Lisp syntax for Haskell. o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 escreveu:
>>> ...there's an XML syntax for Lisp??! o_O
>>>
>>> *runs away*
>>
>> Holy Crap!!
>>
>> actually, it's just a bridge between CL and XML. Hey, XML itself is
>> an s-expression language, like Lisp. ;)
>
> More worryingly... There is also Lisp syntax for Haskell. o_O
There is Liskell. ;)
http://liskell.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 escreveu:
>> Why would my o operator not be a one-liner?
>
> Because it's defined as four (very wide) lines? :-P
By how many lines is $ defined by?
Abstract it away, man! We're here today because we stand in the
shoulders of giants, don't forget that...
> In Lisp, you
> cannot avoid endless brackets, because notionally the *entire source
> code* as a single expression. :-P
Yes, code is data in Lisp. Ain't that sweet? :)
> Heh, right. One question: is it statically-typed?
No. Like I said, perfect. :)
> Haskell is *loaded* with functions that do the same or similar things.
> It's about how you want to think about your problem.
I prefer to design my own DSLs and have a minimalist general-purpose
language with few constructs that don't get in the way nor confuse me
with conflicting semantics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |