[Haskell] Re: Use of tab characters in indentation-sensitive code
Joking aside, surely you intelligent people realize that the internals of a file format have nothing whatsoever to do with the user interface of the editing tool. Something like this would be completely transparent *if* you used the right tools. This just shows how deeply ingrained the ascii plain text mindset is in the programming community. I don't expect anything like this to ever fly, for this reason. You guys won't let it. :( Besides, the idea would be not to use nbsp, but rather some indent paragraph tag. Sean - Original Message - From: Ketil Malde [EMAIL PROTECTED] To: Sean L. Palmer [EMAIL PROTECTED] Cc: Wolfgang Thaller [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 25, 2004 1:06 PM Subject: Re: Use of tab characters in indentation-sensitive code Sean L. Palmer [EMAIL PROTECTED] writes: Why has HTML been out for many many years, and yet programming languages still use plain ASCII text exclusively? Don't we have similar needs as other electronic document manipulators? So we could write: foo bar = case bar of nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;Zot x - ... nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;Pleb - ... (Sorry, I couldn't help myself :-) -kzm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Use of tab characters in indentation-sensitive code
Why has HTML been out for many many years, and yet programming languages still use plain ASCII text exclusively? Don't we have similar needs as other electronic document manipulators? Someone should decide on a subset of HTML that is intended for programming. Then we could use *actual* indentation instead of tabs or spaces. It could also unify or abstract away commenting style, moving it from the domain of the language (lexer) to the domain of the layout protocol. But if I stop the wishful thinking, Wolfgang is right. Tabs are ok so long as they are used exclusively. In fact, if the tab size equals the indent size, it makes it quite easy to *change* the indent size when the source is worked on by various people with different indent preferences. Sean - Original Message - From: Wolfgang Thaller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 24, 2004 9:29 AM Subject: Re: Use of tab characters in indentation-sensitive code Graham Klyne wrote: I think that compilers should issue a warning when indentation that determines the scope of a construct is found to contain tab characters. I'd say, when it is found to contain a mixture of tab and space characters. I have successfully written a lot of Haskell code that uses tabs *exclusively* - in that case, the meaning of the program *doesn't* depend on how the tab characters are interpreted. IMHO, there should only be warnings about tabs when their size makes a difference to the meaning of the program, as shown in the examples below: let spacesx = 1 TAB---y = 1 -- warning let TAB---x = 1 -- OK TAB---y = 2 -- OK spacesz = 3 -- warning a = let x = 1 y = 2 -- OK in ... b = let x = 1 TAB---y = 2 -- warning in ... There are many editors that automatically mix tabs and spaces in indentation (and I don't like that - what's it good for?), but some people will certainly want to continue to use them, so I'm not sure if adding warnings like these would be acceptable to them. Cheers, Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell naming conventions
That was quite a satisfying explanation, thank you. That is certainly
clearing a few things up.
Sean
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 26, 2003 3:07 AM
Subject: Re: Haskell naming conventions
G'day all.
Quoting Lennart Augustsson [EMAIL PROTECTED]:
According to dictionary.com one of the definitions of the word class is:
A set, collection, group, or configuration containing members
regarded
as having certain attributes or traits in common; a kind or category.
And what the members of class Eq have in common is that they have a
function (==). So to me it seems that the word class is very well
chosen; it describes what's going on.
Right. It's exactly the same way that Java and C++ use the word class.
A class is a set of types. In the case of Eq, it's the set of types
which support the equality testing operation (==).
The problem is that C++ (and Java, but I'll use C++ as the archetype from
now on) uses the one keyword, class to do multiple tasks. When you
declare a C++ class:
class Foo
{
// something
};
you're actually doing three things. You are defining a class of types,
namely, the set of types which are derived (possibly in zero steps)
from Foo. You are also defining a concrete type, namely Foo. Finally,
you are declaring that the concrete type Foo is a member of the class
Foo.
Haskell decouples these three tasks. To define a class, you use class.
To define a concrete type you use data. To declare that a certain
concrete type is a member of a class, you use instance.
I should point out that C++ has an idiom something like Haskell type
classes, which is the concept. Concepts are, I think, an admission
that OO derivation is often not the most appropriate way to implement
an abstract interface. Concepts are not statically checked by default,
but there are good libraries out there which effectively provide static
checking of concepts.
A good C++ programmer would probably not implement Eq as a C++ class
because (as Haskell programmers already know), Eq doesn't make sense
as a Liskov-substitutable concrete type on its own. Rather, a good
C++ programmer would provide the interface for the STL equality
comparable concept, which is pretty much the same as Eq.
Now, I admit that if you think you can take concepts with similar names
from other programming languages and apply them to Haskell you might
get confused. You might come across what is called false friends in
natural language, i.e., words that look the same but mean different
things.
Well, in this case, what Haskell calls a class is a strict subset of
what C++ calls a class, so it's more of a true friend than a false
one. It's C++'s fault (though it is historically understandable) that
the class keyword does more than just declare a class of types.
Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Haskell naming conventions
It occurs to me that Haskell would be quite a bit easier for OO and traditional programmers to grasp if Haskell would actually use the correct, or at least more commonly used, names for things. For instance, data Maybe a = Nothing | Just a Maybe is a type constructor and Nothing and Just are data constructors. So it makes me wonder why the use of the datakeyword... wouldn't it make more sense to say: type Maybe a = Nothing | Just a ? Either that or perhaps change the descriptions "type constructor" and "data constructor" to something that fits with the keywords used. Likewise with class, type class, and instance: class Eq a where (==) :: a - a - Bool That actually declares a type class, not a class. So why the use of the keyword class? Is it done merely to confuse C++ and Java programmers? The concept of type class in Haskell apparently roughly corresponds to the concept of "interface" in Java. So why not call it interface? Instance is also confusing: instance EqInteger where a == b = a `integerEq` b That actually declares that Integer is a type, not an "instance" in the traditional use of the word. A C++ programmer would probably use the word "subclass" instead of "instance". Then consider how different a meaning "return" has in Haskell than it does in C. ;) Does anyone else think this is a problem? If so, is it fixable? I guess from reading the many tutorials and FAQ's, that I'm in the same boat as everybody else. I consider myself a pretty bright boy, I've learned all kinds of other programming languages, from asm to forth to basic, pascal, C, C++, java, and C#... but this Haskell business, has me almost stumped. I mean, I understand the basic ideas pretty easily enough, but there seems to be such syntactical wierdness that to understand how to program in Haskell above the level of toy programs requires one to revisit every single design decision that went into making the language and its libraries, and grasp everything along the way, not only its function but also its peculiar nomenclature, and usually two different ways to say the same thing (maybe more). Only after following this long tortuous path will one ever be able to actually write useful programs. If Haskell (or any language of this style) is ever to gain a larger following, it would probably be wise to accomodate the existing programmer knowledge base a little more. I believe that the same core language, with cleaner design, different keywords, maybe different operators, would probably be readily accepted. There are many things that contribute to making Haskell less approachable, the above is just one. I wonder if there are any tutorials out there that provide a 1:1 mapping of concepts and idioms from other common languages into Haskell; small snippets of examples of pure translations would make things easier to grasp for some people than any amount of longwinded explanation. Probably there are easier ways to do the same things in Haskell, but it would be useful for beginners to get aunedited translation, even if that means heavy use of do-notation. At least people could then start writing imperative style Haskell programs immediately, and yeah that's not good style, but you can't learn good style if you can't accomplish anything and are stuck at square one. Frustratedly, Sean ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: literate comments
You could make a utility that just strips code out of XML, using the XML nesting as indentation for the Haskell code. Run it as a preprocessor. It's hard to get stuff like that standardized though. I imagine any kind of development environment is free to pretty up or package the source however it wants, so long as the compiler gets what it needs. The easiest way to make a standard is to make a tool that uses it. Personally I would prefer the kind of all-in-one package of code editor and XML packager/unpackager. That way it all gets done transparently, behind the scenes, and I never have to look at the mess. Personally, not a big fan of LaTeX. I don't understand the bias towards it. Sean - Original Message - From: Steffen Mazanek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 1:08 PM Subject: Re: literate comments Hello, I have thought again about the relationship of Haskell and XML. Finally I come up with the following idea. Why not introduce a Haskell DTD? Not to gain better literate programming facilities, but to represent _real_ Haskell code in XML. Of course, no person would like to program Haskell in XML, but a uniform representation has its advantages nevertheless (cf. openmath [1]): * approved tools for further processing * separation of the presentation layer, pretty printing * interoperability * cross-linking (e.g., generating library summaries or in the manner of funnelweb [2], but xml-style) * objects are often serializable as xml, too The following questions are still open for me: * would the literate programming facilities really be improved? for now, Haskell plays nice with LaTeX, but not at all with XML * possible advantages of xml schema? What do you think about this? Do you see even more advantages of this approach or would it be senseless work? Regards, Steffen Mazanek ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
A... should be split into A.. and . I found a compromise: let's make it a lexing error! :-) At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that A... should be lexed as the two tokens A.. and ., and similarly, A.where should be lexed as A.wher followed by e. Hi. I'm really new to Haskell, just learning it, and I must say I'm pretty overwhelmed by the large variety of constructs. (=, -, \ to name a few) But I'm just writing this to let you guys know (surely you know this already) that anyone from a C/C++/Java/Delphi background is going to completely misunderstand the meaning of A.anything in Haskell... it's completely nonintuitive to people with my background. I kinda like dot notation because it ties together the symbols visually, for instance myrec.myfield is more of a unit than myrec myfield. It stays together better when surrounded by other code, and would result in fewer parenthesis necessary. Haskell to me seems to be a great language with a syntax problem, and a bad case of too many ways to do the same thing; thus every programmer does things their own way and it's difficult to grasp the language by looking at various programs, since they're all so very different. As a small example, there's 'let' vs. 'where'. Maybe a bit of pruning would be in order. That said, I still think it looks more promising than any other language I've looked at that actually is being actively used and maintained and has a decent installed base and good cross platform support. So I will learn it. I just wish the transition was easier and that it took less time to learn. ;) Sean ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
