Class Multiplicity

[Ashley Yakeley]

I have a curious Haskell design pattern. It's called "one class per 
function". It's strange, but I find that as I need more and more 
generality, I end up with classes that look like this:

class (Monad m) => MonadGettableReference m r where
{
get :: forall a. r a -> m a;
};

class (Monad m) => MonadSettableReference m r where
{
set :: forall a. r a -> a -> m ();
};

...and then I'll have a bunch of "joining" classes. Here's a joining 
class:

class
(
MonadGettableReference m r,
MonadSettableReference m r
) => MonadFixedReference m r;

instance
(
MonadGettableReference m r,
MonadSettableReference m r
) => MonadFixedReference m r;

Sooner or later, for maximum generality they're all going to look like 
this:

class Foo a where
{
foo :: a;
};

class Bar a where
{
bar :: a;
};

class
(
Monad m,
forall a. Foo (a -> m a), -- pending appropriate extension
forall b. Bar (m b)
) => FooBar m;

instance
(
Monad m,
forall a. Foo (a -> m a),
forall b. Bar (m b)
) => FooBar m;

I'm not sure if this is a good thing or a bad thing or what.

-- 
Ashley Yakeley, Seattle WA

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Your message to Hugs-Users awaits moderator approval

[hugs-users-admin]

Your mail to 'Hugs-Users' with the subject



Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 133787 bytes but there's a limit of 40 KB

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: ASSIST ME

[John Peterson]

The current plan is to filter via spews.  We could go to member-only
posting if that's what people want but it means that students asking
their homework questions will have a harder time :-).  Plus if the
list is redistributed that's another problem.  Our original spam
filter was generating complaints so we've turned it off until we get
the spews filter up and going.  Send me comments and suggestions - I'm
no expert in this area.


  John

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: ASSIST ME

[Konst Sushenko]

(the original confidential business proposal removed)

Hello,

It was my impression that the list maintainers were considering making
this list moderated, or open only to subscribers. Is there a decision on
that?

Thanks
konst
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ASSIST ME

[vincent yerima]

   CONFIDENTIAL  BUSINESS  PROPOSAL

You may be suprise to receive this letter from me since you dont know me 
personally. The purpose of my introduction is that I  am VINCENT  YERIMA, 
the first son of DAVID YERIMA, the most popular farmer in Zimbabwe who was 
recently murdered in the land dispute in my country. I got your contact 
through network online hence decide to write you. Before the death of my 
father, he had taken me to Johannesburg to deposit the sum of 
US$7,000,000.00(seven million united states of America dollars)in one 
security company as he forsaw the coming danger in Zimbabwe. This money 
wasdeposited in a box as gemstones in to avoid much demurage from the 
security company.This amount was meart for  the  purchase of new machines 
and chemicals for the new farm and establishment in  Swziland. This land 
problems came when Zimbawean president ROBERT MUGABE introduced a new land 
act reform wholly affected the rich white farmers and some few black 
farmers. And this resulted to the killing and mob action by Zimbabwe war 
returns and some lunatics in the society.It is agaist this background that I 
and my family fled Zimbabwe for fear of our lives and currently  staying in 
The Netherlands where we seek political asylum and mooreso have decided to 
transfer my father' money to more reliable foreign account sinces the law of 
The netherland prohibits a refugee to open any bank account or to be 
involveed in any financial transaction throughout the territorial zone of 
Netherland . as the eldest son of my father , I am saddled to with the 
respobility of seeking a genuine foreign account where this money could be 
transfered without the the knowledge of my government who are bert on taking 
everything we have got.The South Africa government seems to be playing along 
with them.

I am faced with the delima of moving this amount of money out of South 
Africa for fear of going through the same experience in futre, both 
countries have similar political history. I am seeking for a partner who I 
have to entrust my future and family in his hand , I must let you know that 
this transaction is risk free. If you accept to assist me andmy family , all 
I want you to do for me , is to arrange with the security company  to clear  
the consignment (funds) from their afiliate office here in the Netherlands 
as I have already given directives for the consignment to be brought to The 
Netherlands from South Africa. But before then all modalities will have to 
be put in place e.g change of ownershipto the consignment and this money 
intend I intend to use for investment . I have two options for you , firstly 
you can choose to have certain percentage of the money or you can go into 
partnership with me for the  proper profitable investment of the money in 
your country . Which ever the option you want , feel free to notify me. I 
have aslo mapped out 5% of the money  for all kinds of expense incured in 
the process of this transaction. If you do not prefer a partnership  I a 
willing to give you 15% of the money while the remaining 80% will be for  my 
investment inin your country. Contact me with the above email address while 
i imlore you to maintain the absolute secrecy required in this transaction.

Thanks God bless  you

Vincent  Yerima


_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: infix type constructors

[Andrew J Bromage]

G'day all.

On Thu, May 16, 2002 at 07:24:10AM -0700, Simon Peyton-Jones wrote:

> I'm slowly getting around to this.   Design questions:
> 
> (A) I think it would be a good compromise to declare that operators
> like "+" are type *constructors* not type *variables*.  So 
>   S+T
> would be a type.  That's slightly inconsistent with value variables,
> but it's jolly useful.  So only alphabetic things would be type
> variables.

While we're at it, could we have infix notation for type classes too?

class (a * b) c | a b -> c where
  (*) :: a -> b -> c

Cheers,
Andrew Bromage
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Negative literals and the meaning of case -2 of -2 -> True

[Thomas Hallgren]

Hi,

The Haskell report seems pretty clear about the meaning of numeric 
literals and negation in expressions: -2 should be interpreted as negate 
(fromInteger 2). That is, negated literals are not treated specially, 
the general rule -(e) ==> negate (e) applies. (See section 3.2 and 3.4 
of the Haskell 98 report [1].)

The mening of numeric literals in patterns also seems clear (section 
3.17.2 says " The interpretation of numeric literals is exactly as 
described in Section 3.2), but the report does not say anything explicit 
about negated literals, although negated numeric literals is a special 
case in the syntax. Presumably, numeric literals should be understood as 
including negated numeric literals in the sections defining the meaning 
of pattern matching?

To find out how Haskell implementations treat negated literals, I tested 
the following program:


main = print (minusTwo,trueOrFalse)

minusTwo = -2::N

trueOrFalse =
case minusTwo of
  -2 -> True
  _ -> False

data N = Negate N | FromInteger Integer deriving (Eq,Show)

instance Num N where
  negate = Negate
  fromInteger = FromInteger
-

The result is:

* hugs Dec 2001: main outputs: (FromInteger (-2),True)
* ghc 5.02.2: main outputs: (FromInteger (-2),True)
* hbc 0..5b: main outputs: (Negate (FromInteger 2),False)
* nhc98 1.12: compiler outputs: Fail: What? matchAltIf at 7:13

 From this I conclude that hbc is the only Haskell implementation that 
treats negated literals in expressions in accordance with the report, 
but it treats negated literals in patterns differently. Hugs and ghc 
treat expressions and patterns consistently, but they disagree with the 
report. Nhc98 appears to be buggy.

Perhaps this is not a serious problem, but wouldn't it be nice if the 
report and the implementations agreed on this point? I bet Simon PJ will 
suggest that the report is changed to match GHC, rather than vice versa, 
as usual :-) I think the report is right, but the meaning of negated 
literals in patterns could be clearer...

References

[1] Haskell 98 report 
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Subject: Scheme Workshop 2002 -- submission deadline extended

[Olin Shivers]

The Scheme Workshop submission deadline has been extended two weeks.
The new submission deadline is May 31 (2200 UTC).

The 2002 Scheme Workshop will be in Pittsburgh in October, the day before
ICFP. We will be planning not only presentation of papers but also some
interesting group discussions. Going by the previous workshops, it should be a
useful and fun day for just about anyone with an interest in Scheme or
functional programming languages. I hope to see you there, and I especially
encourage people to submit papers to the program committee. Please take a
moment to read the "call for papers" I've appended below, and see if you have
a topic or result you would like to submit to the program committee.

See you in Pittsburgh.
-Olin Shivers
 workshop chairman

ACM SIGPLAN
2002 Scheme Workshop
Thursday, October 3, 2002
Pittsburgh, Pennsylvania

The workshop forms part of PLI 2002, which consists 
of the ICFP and PPDP conferences and other workshops.
Full details on the workshop can be found at URL
.

---
* Scope
---
The purpose of the workshop is to discuss experience with and future
developments of the Scheme programming language, as well as general aspects
of computer science loosely centered on the general theme of Scheme.

Papers are invited concerning all aspects of the design, semantics, theory,
application, implementation, and teaching of Scheme. Some example areas
include (but are not limited to):

- Theory
  Formal semantics, correctness of analyses and transformations, 
  lambda calculus.

- Design critiques
  Limitations of the language, future directions.

- Linguistic extensions
  Scheme's simple syntactic framework and minimal static semantics
  has historically made the language an attractive "lab bench" for the
  development and experimentation of novel language features and mechanisms.

  Topics in this area include modules systems, exceptions, control
  mechanisms, distributed programming, concurrency and synchronisation, macro
  systems, and objects.

- Type systems
  Static analyses for dynamic type systems, type systems that bridge
  the gap between static and dynamic types, static systems with
  "type dynamic" extensions, weak typing.

- Implementation
  Compilers, optimisation, virtual machines, resource management,
  interpreters, foreign-function interfaces, partial evaluation, and generally
  implementations with novel or noteworthy features.

- Program-development environments
  The Lisp and Scheme family of programming languages have traditionally
  been the source of innovative program-development environments. Authors
  working on these issues are encouraged to submit papers describing
  their technologies.

- Education
  Scheme has achieved widespread use as a tool for teaching computer science.
  Papers on the theory and practice of teaching with Scheme are invited.

- Applications and experience
  Interesting applications which illuminate aspects of Scheme;
  experience with Scheme in commercial or real-world contexts;
  use of Scheme as an extension or scripting language.

- Scheme pearls
  Elegant, instructive examples of functional programming.

  A "Scheme pearl" submission is a special category, and should be a short
  paper presenting an algorithm, idea or programming device using Scheme in a
  way that is particularly elegant. 

---
* Proceedings
-
The proceedings of the conference will be published as a Georgia Tech College
of Computing technical report. A special issue of the journal Higher-Order and
Symbolic Computation about Scheme 
is planned afterwards.

---
* Important dates
-
- Submission deadline: 2200 UTC, 31 May, 2002
- Notification of acceptance or rejection: 26 July, 2002
- Final paper due: 31 August, 2002
- Workshop: 3 October, 2002

---
* Submission guidelines
---
Authors should submit a 100-200 word abstract and a full paper by 22:00
Universal Coordinated Time on Thursday, 31 May, 2002. (Note that 2200
UTC is 1800 EDT, or 1500 PDT.)

Submissions will be carried out electronically via the Web, at
. Papers must be submitted in PDF format, or as
PostScript documents that are interpretable by Ghostscript, and they must be
printable on US Letter sized paper. Individuals for which this requirement is
a hardship should contact the program chair at least one week before the
deadline.

There are two classes of submissions: reular papers and short papers:

- Regular papers

  Submissions should be no more than 12 pages (including bibliography and
  appendices) in standard ACM conference format: two

Re: Functional design patterns (was: How to get functional software engineering experience?)

[Joost Visser]

[EMAIL PROTECTED] wrote:
> Joost Visser and I, we worked out a few maybe not so obvious functional
> programming patterns such as Success By Failure, Role Play, Rewrite Step,
> Keyhole Operation just to mention a few. By not so obvious I mean that
> they deal with generic programming rather than functional programming in
> general.
> 
>  http://www.cs.vu.nl/Strafunski/dp-sf/
> 
> We use a certain FORMAT for design patterns, and there is some modest
> analysis why this format is appropriate. Also, there is some discussion
> why design patterns would do good for functional programming. This might
> be interesting in the further process of accumulating design patterns
> for functional programming.

I have added the design pattern description format to the Haskell wiki:

http://haskell.org/wiki/wiki?DesignPatternsForFunctionalStrategicProgramming

Perhaps it would be interesting to see if some of the
CommonHaskellIdioms described on this wiki can be cast into the proposed
design pattern format as well.

Joost


--
http://www.cwi.nl/~jvisser/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Your message to Hugs-Users awaits moderator approval

[hugs-users-admin]

Your mail to 'Hugs-Users' with the subject

Meeting notice

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 126883 bytes but there's a limit of 40 KB

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: State monads don't respect the monad laws in Haskell

[John Launchbury]

Yes. Let me be clear.

It is not the fact that `seq` operates on functions that breaks foldr/build:
it is the fact that `seq` claims to be parametrically polymorphic when in
fact it is not. The parametricity result is weakened to the point that the
foldr/build proof no longer applies, and a counter example can be
constructed, viz.

  head = foldr const undefined
  one = build (\c n -> n `seq` c 1 n)

  result = head one

The one definition looks fine as the body to build is sufficiently
polymorphic, but that only because `seq` is lying.

John

>> I watched with interest the discussion about the ravages of `seq`.
>> 
>> In the old days, we protected uses of `seq` with a type class, to keep it at
>> bay. There was no function instance (so no problem with the state monads, or
>> lifting of functions in general), and the type class prevented interference
>> with foldr/build.
>> ...
> 
> Just a further remark: During discussion with Olaf about consequences of
> `seq` for foldr/build, respectively his type-inference based
> deforestation, I had the impression that there could very well be a
> function instance for `seq` not interfering with shortcut deforestation,
> provided this instance is restricted in the following way:
> 
> class Eval a where seq :: a -> b -> b
> 
> instance Eval d => Eval (c -> d)
> 
> I have no idea what would be a semantic justification for this instance
> declaration, except that it allows use of `seq` on at least some
> function types, but seems to outlaw all the critical cases where use of
> `seq` falsifies the foldr/build-rule.
> 
> 
> --
> Janis Voigtlaender

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Dependent Types

[Jon Fairbairn]

"Dominic Steinitz" <[EMAIL PROTECTED]> wrote:
> I've managed to crack something that always annoyed me when I used to do
> network programming.
[. . .]
> 
> Suppose I want to send an ICMP packet. The first byte is the type and the
> second byte is the code. Furthermore, the code depends on the type. Now you
> know at compile time that you can't use codes for one type with a different
> type. However, in Pascal (which is what I used to use) you only seemed to
> be
> able to carry out run time checks.

I'm not sure I understand your problem.  I don't see what's
wrong with the following approach, which is Haskell 98. The
type byte is coded as the type of the packet. Excuse the
perhaps ideosyncratic style ... (in particular, I'm
expecting people to use import qualified with this).


   module ICMP where

   data Type = Redirect RedirectData
 | TimeExceeded TimeData

   {- so you get an alternative for each of the packet types -}

   instance Enum Type where
fromEnum (Redirect _) = 5
fromEnum (TimeExceeded _) = 11

   {- we can't derive Enum for ICMP.Type, because it has non-nullary
  constructors. That just makes it a bit more tedious
  One could provide a class "code" with code:: t -> Int
  instead of fromEnum
-}

   {- now we define individual record types for each of the different
  ICMP types -}

   data RedirectData = RedirectData {redirectCode:: RedirectCode,
 ip_addr:: Int, -- whatever
 redirectData:: [Int]} -- or whatever

   data RedirectCode = RedirNet
 | RedirHost
 | RedirNetToS
 | RedirHostToS
deriving Enum

   data TimeData = TimeData {timeCode:: TimeExceededCode,
 timeData:: [Int]} -- or whatever

   data TimeExceededCode = ExcTTL
 | ExcFragTime
deriving Enum

   {- Since Haskell 98 doesn't have MPTCs, if we want to
  encode packets as anything other than [Int] we'd have
  to define more classes.  Encode serves as an example. -}
 
   class Encode t where
 encode:: t -> [Int]

   instance Encode Type where
encode p@(Redirect d) = fromEnum p: encode d
encode p@(TimeExceeded d) = fromEnum p: encode d

   instance Encode RedirectData where
encode d = fromEnum (redirectCode d): ip_addr d: redirectData d

   instance Encode TimeData where
encode d = fromEnum (timeCode d): 0: timeData d



so one can go 

   encode (Redirect (RedirectData RedirNet 0 [0]))

and get [5,0,0,0], but 


   encode (TimeExceeded (TimeData RedirNet 0 [0]))

gives an error, as one would hope. What am I missing?


Cheers,

  Jón
-- 
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: What does FP do well? (was How to get functional software engineering experience?)

[Bjorn Lisper]

Karl-Filip:
>But what I really meant is, if I may rephrase it, that imperative 
>programs might often be both faster and harder to write because they
>embed more information about the abblication domain. That is, if you 
>code in C and want an array, you must specify its size, so you have to 
>think about your program and figure out that you only need 'x' items
>here, wheras in Haskell you'd use a list and never have to think about 
>what the upper bound on the length of the list is.

Yes indeed. But sometimes the length of a list being returned from a
function can be a simple function of the function arguments (or the sizes of
the arguments), think of map for instance. In such cases, a static program
analysis can sometimes find the length function. If we know thee functions
for all list-producing functions in a closed program, then the lists could
be represented by arrays rather than linked structures.

I know Christoph Herrmann worked on such a program analysis some years
ago. Also, I think Manuel Hermenegildo has done this for some logic
language.

Could sized types be used for this purpose? (I must find myself some time to
read Lars Pareto's PhD thesis...)

Björn Lisper
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: What does FP do well? (was How to get functional software engineering experience?)

[Karl-Filip Faxen]

Hi!

The listlessness stuff is a precursor to deforrestation, so it 
replaces lists by (fewer lists and) scalars. I do not think there
are any arrays involved.

The most important property for being able to convert a list to
an array is that there should never be two cons cells with the same
tail (cdr). A somewhat stronger requirement is that the spine of
the list can not be shared. Then there are the representation oriented
conditions: For each (:), [] and case over lists in the program,
it has to work over arrays or over linked lists or else the linked
list representation and the array representation must be distinguishable
at run-time. That's about it.

But what I really meant is, if I may rephrase it, that imperative 
programs might often be both faster and harder to write because they
embed more information about the abblication domain. That is, if you 
code in C and want an array, you must specify its size, so you have to 
think about your program and figure out that you only need 'x' items
here, wheras in Haskell you'd use a list and never have to think about 
what the upper bound on the length of the list is.

Cheers,

 /kff


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Dependent Types

[Simon Peyton-Jones]

| Here's a bit of background I managed to dig up:
| 
   http://www.mail-archive.com/haskell@haskell.org/msg05160.html

|  It appears that a change to the monomorphism 
|  restriction to match Hugs's behaviour was considered for 
|  Haskell 98, but it looks like it never made it into the report 
|  (for what reason I'm not sure - the arguments in favour of the 
|  change look fairly compelling).

There was a bit of to and fro, but I ended up deciding not to do
anything:

http://www.mail-archive.com/haskell@haskell.org/msg03293.html

Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: preprocessing printf/regex strings (like ocaml)

[Martin Norbäck]

tor 2002-05-16 klockan 10.50 skrev Robert Ennals:

> I don't really see what makes a string such as 
> 
> "I have %. %. %.."   [where the user has to work out what the substrings are]
> 
> any harder to deal with than
> 
> "I have " ++ action ++ " " ++ number ++ " " ++ whatas
> 
> other from the fact that the former is what C does.

Because in one case you just need to change the string, which is in a
database separate from the program, in a standard format (po).

We could have some other syntaxes which makes things clearer, like

printf_named "I have %action; %number; %whatas;."
  [("action","trained"),("number", show 1), ("whatas", "Jedi")]

In the other case you need to change the program, and recompile. So in
the second case you need one compiled program for every language you
support.

If your volonteer translators have to compile the program as well, you
might not get any translations at all due to the high barrier compiling
is.

> AFAICS the only reason to use printf strings is because that is what some 
> people are used to, not because it is sensible system to be using.

I have experience with different systems for translation. If you
translate a number of programs (like I've done), you come to appreciate
that they use the same system.

Gettext is the by far most used system, and it has a lot of nice
properties, like the ability to translate an application without having
to recompile it and good tool support.

> i18n is a useful hack to retrofit onto the C printf system, but I think it 
> would be a backward step for Haskell.

Since I've never seen any i18n systems for Haskell, everything would be
a step forward.

Regards,

Martin

-- 
Martin Norbäck  [EMAIL PROTECTED]  
Kapplandsgatan 40   +46 (0)708 26 33 60
S-414 78  GÖTEBORG  http://www.dtek.chalmers.se/~d95mback/
SWEDEN  OpenPGP ID: 3FA8580B

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Second IFL 2002 announcement

[Ricardo Pe~na]

(Apologies for multiple postings)



 IFL 2002
  14th International Workshop on the
IMPLEMENTATION OF FUNCTIONAL LANGUAGES

  Madrid
  Spain
  September 16 - 18, 2002

=
Important dates
---

   Registration deadline: July 30th, 2002
   Submission deadline  : August 26th, 2002

   further details  : http://dalila.sip.ucm.es/ifl02
 
=


Scope of IFL 2002
-

The aim of the workshop is to bring together researchers and
users actively engaged in the implementation and application of 
functional programming languages to discuss results and new 
directions of research.


The workshop is intended to provide an open forum for researchers
who wish to present and discuss new ideas and concepts, work in
progress, preliminary results etc. related primarily but not 
exclusively to the implementation of functional or function-based
languages. A not necessarily exhaustive list of topics includes 

   language concepts 
   type checking 
   compilation techniques 
   (abstract) interpretation 
   automatic program generation 
   (abstract) machine architectures 
   array processing 
   concurrent/parallel programming and program execution 
   heap management 
   runtime profiling and performance measurements 
   debugging and tracing 
   verification of functional programs
   tools and programming techniques 

Contributions on applications of functional programming, e.g., in
teaching, or on theoretical work in any of the above areas are also
welcome. 



Contributions
-

All attendees are encouraged to submit papers to be published in
the draft proceedings and to give presentations at the workshop.
Submitted papers must be written in English, conform to the LNCS
format (available at: http://www.springer.de/comp/lncs/authors.html)
and not exceed 16 pages.

Papers should be submitted by August 26th as postscript or pdf files
using the submission page of the workshop accessible through
http://dalila.sip.ucm.es/ifl02.

After the workshop, we intend to publish a high-quality subset of
contributions in the Springer LNCS series. All speakers attending the
workshop are invited to submit a paper. Papers for the LNCS proceedings
will be refereed according to normal conference standards.


Ricardo Pe~na (IFL 2002 Organizing Committee Chairman)
Departamento de Sistemas Informaticos y Programacion
Facultad de Informatica
Universidad Complutense de Madrid, 28040 MADRID
e-mail: [EMAIL PROTECTED]
Ph: (+ 34) 91 394 4313FAX: (+ 34) 91 394 4602
http://dalila.sip.ucm.es/~ricardo
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: preprocessing printf/regex strings (like ocaml)

[Robert Ennals]

> Robert Ennals <[EMAIL PROTECTED]> wrote:
> > Surely that problem only arises if one insists on encoding all the relevant 
> > information inside a string.
> 
> This is pretty much the only option, because translators
> and programmers are different people. Translators can deal with
> simple text files with one message string per line and not
> much else. You can't hire a translation firm and tell them
> "translate this Haskell module for me".
> 
> You can treat message strings as declarations in a specialised
> language. This language can be typed, and you could theoretically
> typecheck it against your Haskell program using specialised tools.
> But translators need to see simple readable message strings.

I don't really see what makes a string such as 

"I have %. %. %.."   [where the user has to work out what the substrings are]

any harder to deal with than

"I have " ++ action ++ " " ++ number ++ " " ++ whatas

other from the fact that the former is what C does.

A translator doesn't need to know Haskell. They just need to know that, when, 
in the messages module they see


englishword = "some string"

they put the translation of the word into the string.

And if they see a message like

msgname part otherpart = "string " ++ part ++ " string" ++ otherpart

They change the strings, and reorder the parts to make it a sensible sentence 
in the target language.


AFAICS the only reason to use printf strings is because that is what some 
people are used to, not because it is sensible system to be using.

i18n is a useful hack to retrofit onto the C printf system, but I think it 
would be a backward step for Haskell.


-Rob


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: What does FP do well? (was How to get functional software engineering experience?)

[D. Tweed]

On Wed, 15 May 2002, Hal Daume III wrote:

> I tend to agree.  I keep meaning for experimental purposes to define a
> list type called AList or something which is syntactically identical to
> lists (i.e., you can use the familiar (:) and [] operators/sugar), but
> gets preprocessed out as actually being implemented with an array with a
> pointer to the "current" element.  Especially if we use unboxed types for
> such a thing, I imagine that on many applications this would give a boost
> in performance.

As a pointer, I vagueley recall Phil Wadler's (his homepage
currently seems to be
http://www.research.avayalabs.com/user/wadler/), way back in something
like 1984, was looking at something like this. The title was something
like "Listlessness is better than laziness". I never actually read a copy,
and don't know where you'd get one from, but if you are thinking about
this sort of thing semi-seriously it sounds like somehting worth
consulting.

HTH 

___cheers,_dave_
www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
email:[EMAIL PROTECTED]  |   a Special Outdoor Song which Has To Be
work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell