Probably the main reason why my initial code continualy packed and
unpacked is the lack of syntax support for packed stings. Take  Erlang
as an example.

In erlang a string is just a list of bytes. (yes by default they only
support ASCII) the interpreter toplevel however is built to support
this. when ever it prints a list it checks to see if it might be a
string by inspecting the first n bytes (I don't know how many) if they
are all printable ascii cahracters then it prints the list as a

Likewise when I enter "foobar" in the source it knows that this is a
string.  At present pico does not have any such support. the "
delimiter is allready taken, and there is no alternative. so I can't
easily write an unpacked string in source.
And unless I remember to use princ the top level will print a string as
(f o o b a r).
Now I was dealing with strings that ran to thousands of characters so
this got annoying fast.

What I'm saying is that there may be a case to say that treating
strings as lists by default may be better then treating them as
transient strings by default, especially as the transietn symbol names
are stored as lists under the hood anyway.

Granted it would be a backwards incompatable change but as I recall
the documentation states somewhere that decision to treat strings as
transient symbols may have been missguided.

Once Strings are just lists all of the normal list processing
functions can be appleid to them, and special characters can then be
given standard representations. The need to find out what the control
sequences for things like tab and new line was also a stumbling block
as they are not as intuitive as the '/' escapes used by most other
programming languages.

In the end things are harder than they need to be.

On the specific things I was doing

1) read a texmacs file. every so often there is a <section|Name of
secint> tag. note this is not XML, it happens to use angle brakets  to
mark tags but that is it. in the above there is a significant |, as
far as I can see both / and \ are also significant and mean different

2) submit the body of each section (after removing quotes) to the style command

3) parse the output of style to extract interesting numbers. Note this
is paritcularly problametic as style produces hard to parse output and
the precision of numbers varies between lines.  This last part of
actually parsing the numbers and getting them treated as numbers is
where I got up to before giving up.

2008/7/7 Alexander Burger <[EMAIL PROTECTED]>:
> On Mon, Jul 07, 2008 at 10:22:03AM +1000, konrad Zielinski wrote:
>> I found this very frustrating to do in picolisp due to conflicing
>> requirements, basically boiling down to how the language implements
>> strings.
> It would be interesting to discuss the details here.
>> packing and unpacking my strings. depending on weather I wanted to
>> print them or do somthing else to them.
>> I really thing that the strings should have simply been implemented as
>> lists of chars.
> Yes, this is the way to go. What stops you to do it this way?
> Reading (with 'line' and 'till') will return lists of characters, and
> the 'prin' functions will print them. Packing and unpacking might be
> unnecessary.
> Cheers,
> - Alex
> --

Reply via email to