 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Actually, when I want to compile something, I usually just say "make
>> foo". Otherwise GCC insists on naming it "a.out", which is very irritating.
>
> If you don't specify an executable name, how can gcc guess what is it
> that you want? Note that you can write something like:
>
> g++ file1.cc file2.cc file3.cc
Now there's interesting. I didn't know you could actually compile
multiple source files together; I was under the impression that in that
case, you must manually invoke g++ several times, and then manually
invoke ld to produce the final binary. (Or, more likely, write a
makefile that does that.)
> C++ inherits many things from C, good and bad.
Apparently so. ;-)
[I'm currently compiling a list...]
>> So there *is* a way to automate dependency analysis?
>
> The -MM option of gcc (which I use in that generic makefile I attached)
> auto-generates makefile dependencies for all the specified source
> files. Makefiles themselves (at least with gnu make) are so versatile
> that this can be used to completely automatize dependency building.
Well, that's a step up from manually writing a makefile, writing it
wrong, and producing a binary that segfaults because it's built from
incompatible object files...
>> This whole concept of having to manually write makefiles and manually
>> write header files and so forth just seems tedious and error-prone.
>
> You don't need to manually write makefiles. Just use a generic one.
Has anybody come up with a tool for autogenerating header files yet?
(Presumably you'd need to edit such a file to remove references to
things that aren't meant to be public, but at least the function names
and signatures would match.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> I really can't figure out what everybody finds so confusing about
> Haskell. Is it just that it uses different syntax to other "common"
> programming languages? (E.g., no curly braces, no function call
> brackets.) Or is it something deeper?
There are many things. For example, in what seems to be a common
Haskell style of brevity, the lack of clear delimiters is confusing.
Often everything you see in a line of haskell code looks like this:
a b c . d e f . g h
and there's no way of visually telling what they are. The role of each
element may be wildly different, and from a layman's point of view,
completely arbitrary. It's often even hard to see where a command or
definition or whatever *ends* and where a new one starts. The lack of
clear delimiters makes it very confusing.
If it had some clear delimiters, it *might* become a bit easier to grasp
what exactly is going on. For example something like this is much easier
to start thinking about:
a { b(c, d, e); f(g, h); }
Even without knowing what is a keyword and what is a type or function
name, it's already much easier to even try to understand how the code
is structured, and what might be being executed before what else.
For example let's take these lines:
"+" -> binary (+) stack
"-" -> binary (-) stack
There's no ending delimiter for those commands. The only way we could
deduce where the commands are supposed to end is by trying to deduce
from the lines being similar. If you had used whitespace completely
differently, it would become very confusing, for example:
"+" -> binary
(+) stack "-"
-> binary
(-) stack
I don't know if that's still valid, but I assume it is. Now it's very
hard for a layman to understand what is going on. And the only thing I did
was to add a few newlines and spaces, nothing more. It became an almost
incomprehensible blob of code, with no clear blocks, command ends or
overall structure.
Moreover, in Haskell, from a layman's point of view, you are not even
guaranteed that you can read from left-to-right and get a concept of how
the code is being executed. Sometimes code is executed left-to-right,
sometimes right-to-left, sometimes in a wilder order, and seemingly very
arbitrarily. It becomes very hard to follow what is going on there.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Has anybody come up with a tool for autogenerating header files yet?
I suppose there are programs which can be used for that. However,
it's very difficult for the program to tell what is it that belongs
to the public interface of the module and what isn't.
You don't want to add *everything* to a header file. You only want
to add the *minimal* public interface which is necessary to use the
module, no more.
If you had to annotate in your source file what goes to the header and
what doesn't, you might as well just write the header file yourself with
the same effort.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Has anybody come up with a tool for autogenerating header files yet?
>
> I suppose there are programs which can be used for that. However,
> it's very difficult for the program to tell what is it that belongs
> to the public interface of the module and what isn't.
Yes, it seems that such a file would need to be edited by hand afterwards...
If I'm understanding this right, C++ at least tells you if your
function's signature doesn't match what's declared in the header file.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> I really can't figure out what everybody finds so confusing about
>> Haskell. Is it just that it uses different syntax to other "common"
>> programming languages? (E.g., no curly braces, no function call
>> brackets.) Or is it something deeper?
>
> There are many things. For example, in what seems to be a common
> Haskell style of brevity, the lack of clear delimiters is confusing.
> It's often even hard to see where a command or
> definition or whatever *ends* and where a new one starts. The lack of
> clear delimiters makes it very confusing.
> For example let's take these lines:
>
> "+" -> binary (+) stack
> "-" -> binary (-) stack
>
> There's no ending delimiter for those commands.
> Moreover, in Haskell, from a layman's point of view, you are not even
> guaranteed that you can read from left-to-right and get a concept of how
> the code is being executed. Sometimes code is executed left-to-right,
> sometimes right-to-left, sometimes in a wilder order, and seemingly very
> arbitrarily. It becomes very hard to follow what is going on there.
OK, now I see where you're coming from.
In the case alternatives, the line end *is* the delimiter. So if you
were to "change only the spacing" then you could actually CHANGE THE
MEANING of the program! (In fact, likely, cause it to no longer
compile.) This is different from "curly bracket languages" where you use
"{", "}" to delimit blocks, and ";" as a seperator. In Haskell,
generally a newline is a seperator, and indentation delimits blocks.
So, this works:
case foo of
1 -> bar1
2 -> bar2
3 -> bar3
If the expressions are a bit bigger, you can say
case foo of
1 ->
very_long_thing_1
2 ->
very_long_thing_2
3 ->
very_long_thing_3
And if they're really long, you can say
case foo of
1 ->
multiline1
multiline2
multiline3
2 ->
another_block_1
another_block_2
3 ->
yet_another_block
or some such. The case expression itself ends when we get to something
less indented.
I presume it goes without saying that if you nest things too deeply,
they end up scrolling off the right edge of the screen and/or becoming
rather hard to visually untangle. Don't do that! But for the post part,
it's like a normal curly-bracket language, but without the actual
brackets. (It's normal practise to indent things anyway.)
Expression execution order is more complicated. First, you can say
fn3 (fn2 (fn1 x))
which does... what you'd think it does. It calls the function fn1, and
then passes its result to fn2, and finally passes that to fn3. You can
also write
fn3 $ fn2 $ fn1 $ x
which does exactly the same thing, but doesn't require you to match up
the right number of brackets at the other end. Subtley different, you can do
fn3 . fn2 . fn1
which yields a *function* that will do the same thing as the above,
*when* you actually give it an argument. (Notice there's no "x" here.
That's deliberate. This doesn't produce a result, it produces a
function.) So
(fn3 . fn2 . fn1) x
would be a needlessly wordy way to do the same thing as the previous two
examples.
(As an aside, it should now be clear why the functions are listed
"backwards". If you take a look at the very first expression, this is
almost valid C or C++.)
I guess uttering
mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "]: " ++ show v) (zip
[0..] stack)
*is* pretty crazy. (It doesn't even fit on one line, for example.) But
other than that, it should be *reasonably* clear that main_loop does...
whatever the hell that line does, then it does (putStr "Calc> "), then
it does (cmd <- getLine), and then it does that case expression.
If you've been paying attention, you may have spotted that the very last
line of the program *does* in fact have some delimiters:
_ -> do putStrLn "Stack underflow."; main_loop stack
Haskell does in fact permit you to use curly brackets and semicolons if
you want to. It's just that most programmers don't. (And, in an amusing
twist, curly brackets are also used for something completely unrelated
as well, so it's probably best to _only_ use them for that. Less
confusing that way...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> If you DO want to read a whole line, look up the getline function. That
>> will also take in an "empty" line.
>
> The problem with getline() is precisely that it reads an entire line.
> If there are several whitespace-separated things in that line, it will
> still read the entire line.
Which is not a problem if that's what you want to do.
I use getline to simulate a pause, where the user has to press Enter to
continue (there's another function for just reading a character - I
forget what it was).
--
Copywight 1991 Elmer Fudd. All wights wesewved
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Often everything you see in a line of haskell code looks like this:
> a b c . d e f . g h
> and there's no way of visually telling what they are.
Yeah. I find this is where I have big stumbling blocks reading both
Haskell and ML.
Of course, part of the reason for that is that there really isn't a
clear separation between functions and "values". You can't really say
something like Erlang says, where function names start with lower case
and variable start with upper case. Maybe if there was a heirarchy of
alphabets/fonts like in math, you could see that (for example) "binary"
needs to take an operator because it's in bold, or some such.
> For example let's take these lines:
>
> "+" -> binary (+) stack
> "-" -> binary (-) stack
>
> There's no ending delimiter for those commands.
I think Haskell is line oriented. Commands end at the end of lines.
Since I use a lot (relatively speaking) of languages like this, that's
not what's confusing. (Python, Tcl, most macro languages, etc.)
> Moreover, in Haskell, from a layman's point of view, you are not even
> guaranteed that you can read from left-to-right and get a concept of how
> the code is being executed.
Or even if it executes at all. :-)
> Sometimes code is executed left-to-right,
> sometimes right-to-left, sometimes in a wilder order, and seemingly very
> arbitrarily. It becomes very hard to follow what is going on there.
Yet, oddly enough, the most naive complaint about LISP is all the parens
that completely disambiguate evaluation, and about APL that the
evaluation order is strictly right to left without parens. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Now there's interesting. I didn't know you could actually compile
> multiple source files together; I was under the impression that in that
> case, you must manually invoke g++ several times, and then manually
> invoke ld to produce the final binary. (Or, more likely, write a
> makefile that does that.)
That's basically what happens internally. I don't think it's like Java,
where putting multiple sources on the same line does things that
compiling them separately can't. (For example, putting multiple sources
on the same line is the only way to get Java to compile circular
dependencies between classes, last I looked.)
> Has anybody come up with a tool for autogenerating header files yet?
Yes. About 20 years ago. :-) It was editor macros in Teco (aka PMate).
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Warp wrote:
>> Often everything you see in a line of haskell code looks like this:
>> a b c . d e f . g h
>> and there's no way of visually telling what they are.
>
> Yeah. I find this is where I have big stumbling blocks reading both
> Haskell and ML.
I have a similar issue with stuff like
while (*x++ = *y++) {}
Apparently that means "deference y, fetch the result, incriment y,
deference x, store the result there, incriment x". For no particular
reason other than the specific operator precidences of C.
Similarly, to parse a Haskell expression, note that brackets rule first,
then the (.) or ($) operator. (You'd have to be mad to mix the two
together without some brackets first.) No reason, that's just the
operator precidence rules.
> Of course, part of the reason for that is that there really isn't a
> clear separation between functions and "values".
Meaning you can write a function that takes a function and returns a
function which accepts another function which will return a function
that takes an integer and returns a Boolean. Or similar. Which, even
I'll admit, is pretty crazy.
> I think Haskell is line oriented. Commands end at the end of lines.
Indeed. (Though strictly Haskell doesn't have "commands", it has
expressions.) More exactly, blocks of stuff indented by the same amount
parse as if they were enclosed in {} (which you can manually do, if it
makes you feel better). Otherwise, expressions end at the end of the line.
>> Moreover, in Haskell, from a layman's point of view, you are not even
>> guaranteed that you can read from left-to-right and get a concept of how
>> the code is being executed.
>
> Or even if it executes at all. :-)
Well, notionally you can ignore lazy execution while figuring out the
meaning of the statement, and *then* consider how (if at all) laziness
affects it afterwards.
>> Sometimes code is executed left-to-right,
>> sometimes right-to-left, sometimes in a wilder order, and seemingly very
>> arbitrarily. It becomes very hard to follow what is going on there.
>
> Yet, oddly enough, the most naive complaint about LISP is all the parens
> that completely disambiguate evaluation, and about APL that the
> evaluation order is strictly right to left without parens. :-)
One of the most common things beginner Haskell programmers do is add
vast numbers of brackets. ;-) Trust me, beyong a certain point it
hinders rather than helps.
I think the fact that tuples use regular brackets is rather unhelpful
here. There's a very subtle visual difference between (sin(x) + sin(y))
and (sin(x), sin(y)), but their meanings are quite different. It might
have been better if we had <sin(x), sin(y)> or something, like POV-Ray
does...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> That's basically what happens internally. I don't think it's like Java,
> where putting multiple sources on the same line does things that
> compiling them separately can't. (For example, putting multiple sources
> on the same line is the only way to get Java to compile circular
> dependencies between classes, last I looked.)
When I looked, Sun's javac chokes on circular depends, but M$
VisualStudio J++ doesn't blink an eyelid. It just compiles.
This was a *long* time ago tho... Maybe Sun have fixed their compiler now?
(Before I get too smug, I gather GHC also doesn't like circular depends
either. But then, in Haskell, module bounderies are arbitrary and the
programmer can choose them. In Java, a class goes in a file, and you
can't just move stuff from class to class at will. Not if you want your
design to make sense anyway!)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
