>>> 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

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

>>> 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

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

nemesis <nam### [at] gmailcom> 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

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

"gregjohn" <pte### [at] yahoocom> 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

Nicolas Alvarez <nic### [at] gmailcom> 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

> 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

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