![](/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) |
>>> 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?
One. (See my earlier reply.)
>> 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. :)
If it's not statically-typed, how do you know that all your types match
up correctly?
Oh yeah, that's right - you run it and hope you tested every possible
code path. Until you release the code, and 3 years later discover that
hidden away in some corner is a type mismatch.
...or you could have the compiler tell you on the day when you tried to
compile the code.
Guess which way I prefer? ;-)
>> 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.
Each to their own...
--
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:
>> By how many lines is $ defined by?
>
> One. (See my earlier reply.)
No. I suggest you go through the GHC code and discover by yourself.
> If it's not statically-typed, how do you know that all your types match
> up correctly?
Oh, *I* know. Question is: does the compiler/interpreter knows where I
want to go to? Is it assuming right my decisions?
In C++/Java I have to carefully feed such decisions to the dumb
compiler, in Haskell I have to be sure its correctly following and
inform it when it isn't -- by running into runtime type mismatches, when
the compiler incorrectly assumed something.
In Scheme/Python/Ruby, the interpreter just don't care and it's all up
to you.
> Oh yeah, that's right - you run it and hope you tested every possible
> code path. Until you release the code, and 3 years later discover that
> hidden away in some corner is a type mismatch.
Not different at all from any logic mismatch between what you want to
say and what you actually say. You may type your whole program
correctly and still have logical inconsistencies. Sure, type
inconsistencies are catched early, but they sound to me like trivial
errors. They were certainly non-trivial in C/C++ and their multitude of
pointer arithmetic, they are non-trivial in Java and its multitudes of
deep OO nestings and inter-module dependencies, and they are also
non-trivial in Haskell because of the way how its advanced and complex
type system allows for much of the behaviour of a program to be directly
embedded in the type declarations themselves.
They are trivial though in Scheme, where types are just basic data types
and simple groupings and most of the program behaviour is still
algorithmic in the traditional sense. Type mismatches are the very
minor of headaches here. So, I guess the importance of type systems is
relative.
Anyway, I don't know exactly how this discussion would fit an embedded
scripting language running in a host app. Would Haskell do any better
as an embedded scripting language? All its type safeties don't quite do
much in a non-compiled interactive environment: if you ever did
anything at a Hugs or GHCi console, you'll see you may constantly run
into runtime type errors just as in a dynamically typed language.
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) |
>>> By how many lines is $ defined by?
>>
>> One. (See my earlier reply.)
>
> No. I suggest you go through the GHC code and discover by yourself.
Why? It's not defined in GHC, it's defined in the libraries. :-P
[Checking the language standard document, it's actually defined as two
lines, because it gives a type signature as well.]
>> If it's not statically-typed, how do you know that all your types
>> match up correctly?
>
> Oh, *I* know.
Right. Sure. Because you're super-human. :-P
> In C++/Java I have to carefully feed such decisions to the dumb
> compiler, in Haskell I have to be sure its correctly following and
> inform it when it isn't -- by running into runtime type mismatches, when
> the compiler incorrectly assumed something.
In Haskell, you can't *have* runtime type mismatches. :-P
> In Scheme/Python/Ruby, the interpreter just don't care and it's all up
> to you.
Exactly. If you make a mistake, it's your fault, and the interpreter
gives you no help at all to fix it.
>> Oh yeah, that's right - you run it and hope you tested every possible
>> code path. Until you release the code, and 3 years later discover that
>> hidden away in some corner is a type mismatch.
>
> Not different at all from any logic mismatch between what you want to
> say and what you actually say. You may type your whole program
> correctly and still have logical inconsistencies.
Does the type system catch every possible problem? No.
Will any automated system ever catch every possible problem? No.
Does that mean that automated systems for catching problems are a waste
of time? Again, no.
> Anyway, I don't know exactly how this discussion would fit an embedded
> scripting language running in a host app. Would Haskell do any better
> as an embedded scripting language? All its type safeties don't quite do
> much in a non-compiled interactive environment: if you ever did
> anything at a Hugs or GHCi console, you'll see you may constantly run
> into runtime type errors just as in a dynamically typed language.
For writing small, simple things on the fly, something vague and
unstructured is probably the best way to go. (This is why scripting
languages exist.)
Personally, I don't tend to write that kind of code.
--
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 wrote:
> [Checking the language standard document, it's actually defined as two
> lines, because it gives a type signature as well.]
So is mine. The others had nothing to do with compose.
>> Oh, *I* know.
>
> Right. Sure. Because you're super-human. :-P
No, I just know what I'm doing and consider type errors too primary and
trivial next to logic errors.
> In Haskell, you can't *have* runtime type mismatches. :-P
True. Sorry. It's a type system error message from verifying a type
mismatch is happening. It is helpful.
Of course, it's also a pain in the butt when it gets in the way:
Prelude> let statusLine fruits = if fruits>1 then fruits else "No more
fruits"
<interactive>:1:34:
No instance for (Num [Char])
arising from the literal `1' at <interactive>:1:34
Possible fix: add an instance declaration for (Num [Char])
In the second argument of `(>)', namely `1'
In the predicate expression: fruits > 1
In the expression: if fruits > 1 then fruits else "No more fruits"
I used a quick hack to try to get around it:
Prelude> let self x = x
Prelude> let statusLine fruits = if fruits>1 then self statusLine fruits
else "No more fruits"
So far, so good. The compiler didn't do its job. ;)
But, then:
Prelude> print statusLine 3
<interactive>:1:0:
Couldn't match expected type `t1 -> t'
against inferred type `IO ()'
In the expression: print statusLine 3
In the definition of `it': it = print statusLine 3
I tried to group it with parenthesis then:
Prelude> print (statusLine 3)
"
Weird! It output that single double quote and froze. I had to
interrupt it.
Lesson here: sometimes the compiler not only gets in your way but also
doesn't do its job as supposed.
Oh, and BTW:
Prelude> filter odd [1,2,3,4,5]
[1,3,5]
weird, huh? :P
>> In Scheme/Python/Ruby, the interpreter just don't care and it's all up
>> to you.
>
> Exactly. If you make a mistake, it's your fault, and the interpreter
> gives you no help at all to fix it.
It gives you a nice call stack trace. :)
Seriously though, Common Lisp is king in this respect. Some of its most
well-known implementations' runtime systems allow for a quick debug of
what's going on in an app, correcting, compiling and even patching it
while the system is still running. Yes, no need for reboots.
> Does that mean that automated systems for catching problems are a waste
> of time? Again, no.
Not at all.
> For writing small, simple things on the fly, something vague and
> unstructured is probably the best way to go. (This is why scripting
> languages exist.)
Exactly. Dynamic languages fit the bill whenever specifications are
vague and prone to much change. Like, every real world system I've
worked with, except they were in horribly asinine straightjacket
languages that penalized changes.
> Personally, I don't tend to write that kind of code.
But it was the kind of which the OP was asking about.
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) |
nemesis <nam### [at] gmail com> wrote:
> Hmm, I wonder if this gregjohn fellow is taking any advantage from my
> replies. He posts a question and vanishes! O_o
My goodness, how long has it been?!
But I did look at the Script-Fu (had to be sure I typed that right) for resize
and don't think it exactly worked.
I was hoping to do something like set up my own hotkey where like Shft Ctrl F11
just automatically resizes to 400x300 pixels.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: GIMP hotkeys/ scripts/ user-defined functions?
Date: 10 Dec 2008 21:36:24
Message: <49407ca8@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> actually, it's just a bridge between CL and XML. Hey, XML itself is an
> s-expression language, like Lisp. ;)
Some people have tried the opposite. Converting XML into something that
looks like lisp :)
<tag attr1="value1"
attr2="value2">
<nested>Text node</nested>
<empty/>
</tag>
(tag (@ (attr1 "value1")
(attr2 "value2"))
(nested "Text node")
(empty))
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) |
"gregjohn" <pte### [at] yahoo com> wrote:
> I was hoping to do something like set up my own hotkey where like Shft Ctrl F11
> just automatically resizes to 400x300 pixels.
Oh, man! Why didn't you say so? We went all into a language flamewar that
could be avoided! :P
Anyway, it's in the Edit -> Preferences dialog. Go to Interface -> Config
Keyboard Shortcuts, select Image -> Resize Image (way down), press your choice
of shortcut, done.
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) |
Nicolas Alvarez <nic### [at] gmail com> wrote:
> nemesis wrote:
> > actually, it's just a bridge between CL and XML. Hey, XML itself is an
> > s-expression language, like Lisp. ;)
>
> Some people have tried the opposite. Converting XML into something that
> looks like lisp :)
>
> <tag attr1="value1"
> attr2="value2">
> <nested>Text node</nested>
> <empty/>
> </tag>
>
> (tag (@ (attr1 "value1")
> (attr2 "value2"))
> (nested "Text node")
> (empty))
Yes. Many web frameworks for Scheme go that path. And I like it much better.
:)
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) |
> Lesson here: sometimes the compiler not only gets in your way but also
> doesn't do its job as supposed.
In other words, "no automated system catches every possible error". :-P
That doesn't make automated error catching useless.
>>> In Scheme/Python/Ruby, the interpreter just don't care and it's all
>>> up to you.
>>
>> Exactly. If you make a mistake, it's your fault, and the interpreter
>> gives you no help at all to fix it.
>
> It gives you a nice call stack trace. :)
>
> Seriously though, Common Lisp is king in this respect. Some of its most
> well-known implementations' runtime systems allow for a quick debug of
> what's going on in an app, correcting, compiling and even patching it
> while the system is still running. Yes, no need for reboots.
Isn't that precisely what Smalltalk also does? :-P
Of course, much as I like Smalltalk, the lack of static typing makes it
really hard to use. When you have multiple levels of indirection, it's
very easy to accidentally miss one out. Static typing would instantly
detect this mistake and tell you exactly where the problem is. But
Smalltalk doesn't have it. So you run your code, something of the wrong
type gets assigned somewhere, and many hundred method calls later, you
get an exception because some method isn't defined. Oh, sure, you get a
call stack, but *good luck* figuring out where the _problem_ is. The
call stack only shows you where the problem get _detected_.
>> Does that mean that automated systems for catching problems are a
>> waste of time? Again, no.
>
> Not at all.
You see why I like having automated error-catching systems then? :-P
>> For writing small, simple things on the fly, something vague and
>> unstructured is probably the best way to go. (This is why scripting
>> languages exist.)
>
> Exactly. Dynamic languages fit the bill whenever specifications are
> vague and prone to much change.
No, scripting languages fit the bill anywhere the thing to be built is
small, simple, and it's only going to be used in one specific way.
As soon as you start trying to do anything more sophisticated than that,
scripting languages become inadaquate.
>> Personally, I don't tend to write that kind of code.
>
> But it was the kind of which the OP was asking about.
Yeah, I get that. I'm just saying, for writing large complex programs,
more help = better.
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:
> Isn't that precisely what Smalltalk also does? :-P
Oddly enough, Ada can unload and reload new code while it's running too, and
that's about the most anal-retentive language I've ever used.
> Of course, much as I like Smalltalk, the lack of static typing makes it
> really hard to use. [...] but *good luck* figuring out where the
> _problem_ is. The
> call stack only shows you where the problem get _detected_.
You know, I did my PhD work by patching into someone else's structured
editor/compiler/interpreter written Smalltalk, without really understanding
all the details. I had this kind of error maybe a handful of times, and it
was never confusing what happened. If you leave out a level of indirection,
then you wind up with an array of XYZ where you expected a XYZ, so you know
you missed the indirection where you wanted to go from array-of-XYZ to XYZ.
If do one too many, you get the error exactly when you ask for the Nth XYZ
from the array of XYZ that's really a single XYZ.
> As soon as you start trying to do anything more sophisticated than that,
> scripting languages become inadaquate.
I disagree.
--
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) |