[Haskell-cafe] Fwd: Can I use String without "" in ghci?

Rustom Mody rustompmody at gmail.com
Tue Sep 3 12:44:22 CEST 2013


On Mon, Sep 2, 2013 at 10:43 AM, Richard A. O'Keefe <ok at cs.otago.ac.nz>wrote:

>
> On 2/09/2013, at 3:55 PM, Rustom Mody wrote:
>
> > On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe  wrote:
> >
>
> > A slogan I have programmed by since I first met C and recognised
> > how vastly superior to PL/I it was for text manipulation _because_
> > it didn't have a proper string type is "Strings are Wrong!".
> >
>
> C rode to fame on the back of Unix. And Unix's innovation – one of many –
> is that at the OS level the string type was made common fare – a universal
> type.  So everything from file names to file contents to IPC is a string.
>
> The idea of file names being strings was no innovation.
> Yes, in crippled monstrosities like TOPS-10 file names were
> weird records -- I can still remember too much of the details --
> and every ruddy TOPS-10 program had to do its own file name
> parsing and it seemed as if they all did it differently.  But
> the B6700 MCP interfaces treated file names as strings before
> UNIX was dreamed of.
>
> File contents in UNIX are *not* strings and never have been --
> NUL termination is no part of files and binary files have been
> commonplace since the beginning (an a.out file is not a string!).
> They are *byte arrays*.
>
> As for IPC, since when have System V shared memory, semaphores,
> or message queues had anything to do with strings?
> (Hint: the 'name' of a System V shared memory segment is a
>  key_t, and that's an integral type, not a string.
>  Hint: the 'name' of a System V semaphore is also a key_t
>  integer, not a string.
>  Hint: the 'name' of a System V message queue is also a key_t
>  integer, not a string.
>  Hint: messages sent using msgsnd are not strings, they are
>  byte arrays with a separate count parameter.
> )
>
>
Whoops! my bad -- I was *thinking* 'pipes' but ended up *writing* 'IPC'
:-)

So let me restate more explicitly what I intended -- pipes, FIFOs, sockets,
etc.
IOW read/write/send/recv calls and the mathematical model represented by
the (non-firstclass) pair of C data structures in those functions: <buf,
len> (or count).

As an aside: modern usage types the buf as void * .  The version 7 unix
manuals on which I grew up (and first edition of K&R), there was no void;
buf would be just 'char *buf; '


> Classic UNIX uses strings for file names, and really, that's it.
> (The command line argv[] is not really an exception, because it
> was used for file names as well as options, and in fact mixing
> the two up caused endless problems.)
> Everything else in V7, S3, or SysV was identified by a *number*.
> Plan 9 has exit(string) but Unix has exit(byte).
>
> From the perspective of someone who used UNIX v6 in 1979,
> *POSIX* IPC -- with its IPC objects *might* be in the file
> system but then again might *not* be so their names are
> sorta-kinda-like file names but not really) -- and /proc are
> recent innovations.
>
> The idea that 'string' was even remotely like a "universal type"
> in UNIX is bizarre.
>
> Heck, UNIX never even used 'string' for *lines* in text files!
>
> > Of course when instructing a beginning programmer your basic premise
> 'Strings are Wrong!' is most likely right.
>
> No, I'm talking about experienced programmers writing high performance
> programs.
>
> >  However if programs are seen as entities interacting with an 'external'
> world, the currency at the portals is invariably string.
>
> - The currency at the portals is *not* invariably string.
>   Learn PowerShell.
> - "Text" is one thing and "string" is another.  This was the
>   B6700 lesson (well, really the B5500 lesson): for many purposes
>   you want a text *stream* not a text *string* at the interface.
>   It's also the what-Smalltalk-got-right-and-Java-got-wrong
>   lesson: the right way to convert objects to text is via a
>   *stream* interface, not a *string* interface.
>

I realize this is a terminology issue:

My usage of terminology like string/file are evidently more aligned to
http://en.wikipedia.org/wiki/Vienna_Development_Method#Collections:_Sets.2C_Mappings_and_Sequences
file(chap 4):
http://red.cs.nott.ac.uk/~rxq/files/SpecificationCaseStudies.pdf

Contrariwise 'file' can mean
http://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29

So coming back from terminology to principles...

 >  And more than just noob programmers have got this wrong – think of the
> precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic.
>
> Hang on, they are there in order to *support* the "numbers are text" model.
> You can't have it both ways.
>

So let me restate (actually I didn't state it earlier!) my point in this
example:

When Intel introduced these instructions in 8008 (or whatever) decades ago,
it seemed like a good idea to help programmers and reduce their burden by
allowing them to do some minimal arithmetic on data without burdensome
conversion-to-binary functions.

4 decades on and (Intel's very own Gordon) Moore's law ensuring our
machines and networks some 7 orders of magnitude larger, the cost-equations
look different.  printf and scanf are a basic given in any C library so
optimizing them out does not optimize anything.

On the other hand having instructions --that too 1-byte instructions --
that are almost never used is terribly inefficient:
- the extra transistors in the millions of CPUs that are never used
- the instructions that are used become fatter.  Multiply by the GBs per
installation multipled by millions of installations.

And so Intel made (makes) the same mistake that the typical programmer-noob
makes, which you capture pithily in your 'Strings are wrong!' Put slightly
more verbosely:

Strings (or byte-arrays if you prefer) are invariably what come into and go
out of your program.
Keep them that way and you reduce your work in the immediate term but
increase it in the long term since it is almost always a bad fit for both
problem-domain and machine-model. Building appropriate models is the
central business of programmers

Brings me to the OPs question:

I want to know if it is possible that I use strings without "".
>
> If I type
> *Prelude>foo bar*
> which actually I mean
> *Prelude>foo "bar"*
> However I don't want to type ""s.
>
> I have noticed if *bar* is predefined or it is a number, it can be used
> as arguments. But can other strings be used this way? Like in bash, we can
> use *ping 127.0.0.1* where *127.0.0.1* is an argument.
>
> If not, can *foo* be defined as a function so that it recognize arguments
> like *bar* as *"bar"*?
>

Its not clear what your use-case is.

1. In the simplest and most common case, a few data declarations will give
you what you want.  eg if in place of bar you have (a few) colors like red,
green etc you can do
data Color = Red | Green...
and your strings like "red" "green" will disappear and become Red Green etc
IOW if your "bar" and like strings is a small enumerate-able set then make
a corresponding enumerated type. Thereafter haskell will do the quoting for
you.

For the IP example you dont even need a data; just type
type IP = (Int,Int,Int,Int)
or if you prefer
type IP = (Word8,Word8,Word8,Word8)
and then the shell 127.0.0.1 would be the haskell (127,0,0,1)

Sometimes though one may prefer to be a little pedantic and write
newtype IP = IP (Word8,Word8,Word8,Word8)

Note the exact fit of the Word8 to the IP spec.
And the corresponding non-exact fit with the string form: What happens when
you
see the string, "500.1000.1.2" ? You need to decide...

Beyond that, as others have shown you may want to consider building your
own DSL perhaps using template haskell

Beyond that... are you sure shell is not what you want?

ie if you need full haskell power, and typical shell quoting behavior and
you have thought through a design that is sound and consistent (note
Albert's refs above to $ usage in shell) then I (and I guess many others
here) will want to hear of it!!

However for starters you probably dont want to go beyond just defining
well-fitting datas and types and many of the ".." will vanish from your code



Rusi

-- 
http://www.the-magus.in
http://blog.languager.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130903/e913aa0a/attachment.htm>


More information about the Haskell-Cafe mailing list