[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

questions about cl:fad

Jim Newton

10/7/2015 8:05:00 AM

I discovered that the CL pathname accessors are not setf-able.
For example, I cannot use
(setf (filename-type) "png")
to change the file extension of the pathname object from whatever it is to "dot".

I looked in cl:fad to see if it offers a solution for this, but didn't find one.

In my case I have a pathname object such as #p"/tmp/somedir/file.dot"

And I want to create #p"/tmp/somedir/file.png" from that.

Can someone suggest the correct thing to do?
7 Answers

Didier Verna

10/7/2015 8:23:00 AM

0

Jim Newton wrote:

> In my case I have a pathname object such as #p"/tmp/somedir/file.dot"
> And I want to create #p"/tmp/somedir/file.png" from that.
>
> Can someone suggest the correct thing to do?

(merge-pathnames (make-pathname :type "png") #p"/tmp/somedir/file.dot")

--
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out: http://didierverna.com/records/roots-and-...

Lisp, Jazz, Aïkido: http://www.didier...

William James

10/7/2015 11:51:00 AM

0

Jim Newton wrote:

> I discovered that the CL pathname accessors are not setf-able.
> For example, I cannot use
> (setf (filename-type) "png")
> to change the file extension of the pathname object from whatever it is to "dot".
>
> I looked in cl:fad to see if it offers a solution for this, but didn't find one.
>
> In my case I have a pathname object such as #p"/tmp/somedir/file.dot"
>
> And I want to create #p"/tmp/somedir/file.png" from that.
>
> Can someone suggest the correct thing to do?

Gauche Scheme:

gosh> (regexp-replace #/dot$/ "/tmp/somedir/file.dot" "png")
"/tmp/somedir/file.png"

Pascal J. Bourguignon

10/7/2015 12:31:00 PM

0

Jim Newton <jimka.issy@gmail.com> writes:

> I discovered that the CL pathname accessors are not setf-able.
> For example, I cannot use
> (setf (filename-type) "png")
> to change the file extension of the pathname object from whatever it is to "dot".
>
> I looked in cl:fad to see if it offers a solution for this, but didn't find one.
>
> In my case I have a pathname object such as #p"/tmp/somedir/file.dot"
>
> And I want to create #p"/tmp/somedir/file.png" from that.
>
> Can someone suggest the correct thing to do?


(make-pathname :type "png" :defaults #p"/tmp/somedir/file.dot"
:case :local)

--
__Pascal Bourguignon__ http://www.informat...
â??The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.� -- Carl Bass CEO Autodesk

Jim Newton

10/8/2015 11:08:00 AM

0

Thanks for the suggestion. I'll give you're or Didier's suggestion a try.

Am I alone in thinking that filename-type would be setf-able?

smh

10/9/2015 12:33:00 PM

0

The reason pathname components are not portably setfable is so an implementation can choose a strategy of interning pathnames. Not sure any current implementations exploit this, but it has been played with. Can't remember specifics.

Kaz Kylheku

10/9/2015 5:36:00 PM

0

On 2015-10-09, smh <shaflich@gmail.com> wrote:
> The reason pathname components are not portably setfable is so an
> implementation can choose a strategy of interning pathnames.

Integers have an implementation-defined representation, yet bitfields
are portably setfable.

The most probable reason why anything doesn't exist is that nobody thought
of proposing it as a feature and making a requirement.

Hey look, REALPART isn't an accessor. I have a complex number stored in
a variable C, and I can't do (setf (realpart c) 42.0).

Pascal J. Bourguignon

10/9/2015 9:00:00 PM

0

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2015-10-09, smh <shaflich@gmail.com> wrote:
>> The reason pathname components are not portably setfable is so an
>> implementation can choose a strategy of interning pathnames.
>
> Integers have an implementation-defined representation, yet bitfields
> are portably setfable.

But they don't mutate the integer, they produce a new different integer,
and bind it to the old place.

(setf ldb) = dpb


> The most probable reason why anything doesn't exist is that nobody thought
> of proposing it as a feature and making a requirement.
>
> Hey look, REALPART isn't an accessor. I have a complex number stored in
> a variable C, and I can't do (setf (realpart c) 42.0).

Notice that in processors having bit field instructions (or even mere
bit and/or/xor instructions), you may have the impression that you're
able to mutate a word. But what actually happens, is that the
register is copied to the ALU, combined the bit field operation masks, a
new word is produced by the ALU, which is then copied back to the
register. No word is ever mutated even in assembler! :-)

But then, for atoms implemented using data structures stored in memory,
such as complexes, or bignums, we could conceivably mutate them, and it
would be a bad thing, given the other assumptions given by lisp. (On
the order of (setf nil t) bad, when it was possible, or even worse).


--
__Pascal Bourguignon__ http://www.informat...
â??The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.� -- Carl Bass CEO Autodesk